[internet] <----> [Host A]
                                |----------> [Host B]

ovvero l’Host A può navigare su internet e raggiungere l’Host B, mentre l’Host B non è direttamente connesso ad internet e può solo ricevere connessioni ssh in ingresso dall’Host A.

Per poter navigare anche dall’Host B, l’unica soluzione è installare un micro-proxy sull’Host A e poi creare una reverse-ssh dall’Host A verso l’Host B.

Come micro-proxy sull’Host A possiamo installare TinyProxy:

apt install tinyproxy

Su cui modifichiamo le impostazioni per lasciarlo in ascolto sulla porta 8888 e da 127.0.0.1:

apt update && apt install -y tinyproxy
sed -i 's/^Port .*/Port 8888/'           /etc/tinyproxy/tinyproxy.conf
sed -i 's/^#Listen /Listen /'            /etc/tinyproxy/tinyproxy.conf
sed -i 's/^Listen.*/Listen 127.0.0.1/'  /etc/tinyproxy/tinyproxy.conf
systemctl restart tinyproxy

Verifica:

curl -x http://127.0.0.1:8888 https://ipinfo.io/ip
# deve restituire l’IP pubblico di Host A

Ora creiamo un reverse SSH “stabile” HostA → Host B in modo che la porta 8888 di Host A diventi accessibile su Host B come 127.0.0.1:8888.

Si può ottenere eseguendo su Host A:

ssh -NT -R 8888:127.0.0.1:8888  user@HostB

In questo modo viene attivata una socket in ascolto su HostB che fa rispondere direttamente Tinyproxy sull’HostA

Per evitare che la connessione si interrompa al riavvio, la soluzione è autorizzare la connessione caricando la chiave ssh dell’HostA sull’HostB e poi usare autossh sull’HostA come segue:

apt install autossh
autossh -M 0 -NT -R 8888:127.0.0.1:8888 -o "ExitOnForwardFailure=yes" -o "ServerAliveInterval 30" -o "ServerAliveCountMax 3"  user@HostB

E’ possibile gestire autossh con un servizio systemD. Su HostA creiamo il file del servizio /etc/systemd/system/autossh-tunnel.service in cui inseriamo:

[Unit]
Description=Autossh reverse tunnel B → A per apt-cache
After=network.target

[Service]
Type=simple
User=root
Environment=AUTOSSH_GATETIME=0
ExecStart=/usr/bin/autossh -M 0 \
  -o "ServerAliveInterval 30" \
  -o "ServerAliveCountMax 3" \
  -o "ExitOnForwardFailure=yes" \
  -o "StrictHostKeyChecking=accept-new" \
  -N \
  -R 8888:127.0.0.1:8888 \
  user@HostB
Restart=always
RestartSec=10

[Install]
WantedBy=multi-user.target

e poi abilitiamo, avviamo e controlliamo il servizio con:

systemctl enable autossh-tunnel.service
systemctl start autossh-tunnel.service
systemctl status autossh-tunnel.service

Ora verifichiamo su HostB se riusciamo a collegarci con:

curl -x http://127.0.0.1:8888  https://example.com

chiaramente verrà mostrato un messaggio di errore. Esportiamo quindi le variabili per rendere globale il proxy:

export http_proxy=http://127.0.0.1:8888
export https_proxy=http://127.0.0.1:8888

e facciamo un anuova verifica da HostB:

$ curl -x http://127.0.0.1:8888 https://ifconfig.me
# deve restituire sempre l’IP pubblico di Host A

enjoy!

The authenticity of host 'xxxx (xxxxxxx)' can't be established.
ED25519 key fingerprint is SHA256:aaaaaaaaaaaaaaaaaaaaaa.
This host key is known by the following other names/addresses:
~/.ssh/known_hosts:611: xx.xx.xx.xx
...
...
(11 additional names omitted)
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes

Questo capita se avete l’opzione StrictHostKeyChecking attiva nel client SSH.

Per ovviare, si può rigenerare la chiave server come segue:

rm /etc/ssh/ssh_host_*
dpkg-reconfigure openssh-server

enjoy!

In questo caso dovremo aggiungere l’opzione PubkeyAuthentication come segue:

ssh -o PubkeyAuthentication=no IP_DEL_SERVER

In questo modo viene ignorato l’accesso con chiave e viene richiesta la password.

enjoy!

Ci sono due soluzioni che consentono di velocizzare questa procedura, una l’abbiamo vista tempo fa ed è il port forwarding, dove il server dietro la NAT effettua una connessione SSH al gateway e gli chiede di mettersi in ascolto su una certa porta ed inoltrare tutto quello che riceve su questa porta al server che ha avviato il port forwarding.

Un’altra soluzione, qualora non sia possibile aprire porte sul gateway o non si possa raggiungere prima il server dietro la NAT, è fare una doppia connessione SSH (prima al gateway e poi dal gateway verso il server interno) e questa cosa… può essere automatizzata.

In base alla versione di OpenSSH installata, la configurazione è leggermente diversa. Ricordo che la configurazione ssh va fatta nel file ~/.ssh/config in cui andremo a creare una sezione per la connessione che ci interessa. Ipotizziamo che il gateway abbia IP 10.10.10.10 (il nostro proxyserver) ed il server dietro NAT abbia IP 192.168.1.20 (il nostro server finale), la configurazione nel nostro client sarà:

OpenSSH 7.3 o superiore:

Configurazione in ~/.ssh/config del client:

Host dietro_nat
  Hostname 192.168.1.20
  ProxyJump 10.10.10.10

e ci colleghiamo con:

ssh dietro_nat

Oppure, senza la configurazione, ci possiamo collegare direttamente con:

ssh 192.168.1.20 -o 'ProxyJump 10.10.10.10' 

o, in alternativa:

ssh -J user@10.10.10.10 user@192.168.1.20

OpenSSH superiore alla 5.4:

Configurazione in ~/.ssh/config del client:

Host dietro_nat
  Hostname 192.168.1.20
  ProxyCommand ssh 10.10.10.10 -W %h:%p

e ci colleghiamo sempre con:

ssh dietro_nat

Oppure, senza la configurazione, ci possiamo collegare direttamente con:

ssh 192.168.1.20 -o 'ProxyCommand ssh 10.10.10.10 -W %h:%p'

OpenSSH inferiore alla 5.4:

Configurazione in ~/.ssh/config del client:

Host dietro_nat
  Hostname 192.168.1.29
  ProxyCommand ssh 10.10.10.10 nc %h %p 2> /dev/null

e ci colleghiamo con:

ssh dietro_nat

Oppure, senza la configurazione, ci possiamo collegare direttamente con:

ssh 192.168.1.20 -o 'ProxyCommand ssh 10.10.10.10 nc %h %p 2> /dev/null'

enjoy!

vi scp://10.10.10.10//etc/apache2/apache2.conf

Colgo l’occasione per ricordarvi che per eseguire un comando remoto, es riavviare apache, si può usare:

ssh 10.10.10.10 'service apache2 restart'

Nei due esempi precedenti, non ho passato l’user/password di connessione, perché abitualmente uso un certificato per farlo.

enjoy!

Per far questo, possiamo usare la direttiva Match Address. Il file da modificare per le configurazioni è /etc/ssh/sshd_config; Innanzitutto disabilitiamo l’accesso con le direttive:

PasswordAuthentication no
PubkeyAuthentication no

Successivamente abilitiamo l’accesso solo per un IP (es xxx.xxx.xxx.xxx):

Match address xxx.xxx.xxx.xxx/32
    PasswordAuthentication yes

Prima di riavviare, verifichiamo di non aver commesso errori nel file di configurazione con:

sshd -t

Bene, riavviamo il servizio ssh:

service ssh restart

Se abbiamo più interfacce e vogliamo lasciare il servizio ssh in ascolto solo su una di esse, possiamo utilizzare la direttiva ListenAddress a cui va indicato l’IP dell’interfaccia.

enjoy!

Il nuovo formato Ed25519 è supportato da OpenSSH 6.5 (Ubuntu 14.04+, Debian 8+, CentOS/RedHat 7+)

Il problema che sorge è nel fatto che sicuramente la chiave pubblica sarà ormai su diversi server e pertanto non si può semplicemente cancellare la vecchia, ma bisogna programmare un periodo di transizione durante il quale si farà l’autenticazione con la precedente chiave e si aggiungerà anche la nuova. Questo però può rendere problematica la connessione, perché bisognerebbe specificare a mano la chiave da usare volta per volta in base al server remoto, oppure impostare la configurazione nel file .ssh/config. Ci viene in aiuto il comando ssh-add per gestire l’autenticazione in automatico con diverse chiavi.

Ma vediamo la procedura da fare per:
1 – fare una copia della precedente chiave RSA
2 – generare una nuova chiave RSA a 4096
3 – generare una nuova chiave Ed25519
4 – configurare il sistema per provare in automatico le tre per l’autenticazione

mv ~/.ssh/id_rsa ~/.ssh/id_rsa_legacy
mv ~/.ssh/id_rsa.pub ~/.ssh/id_rsa_legacy.pub

ssh-keygen -t rsa -b 4096 -o -a 100 -C "indirizzo@email"

ssh-keygen -o -a 100 -t ed25519 -C "indirizzo@email"

ssh-add ~/.ssh/id_rsa ~/.ssh/id_rsa_legacy ~/.ssh/id_ed25519

Bene, ora effettuando la connessione SSH ad un server remoto, verrà fatta in automatico l’autenticazione in base ad una delle chiavi trovate nell’elenco passato ad ssh-add.

Per aggiornare la chiave ssh sul server, potremo effettuare dal client, per ogni server:

ssh-copy-id -i ~/.ssh/id_ed25519 user@server

ed infine dovremo procedere col cancellare la vecchia entry, dopo aver verificato che la nuova funzioni correttamente, nel file ~/.ssh/authorized_keys di ogni server.

enjoy!

Rsync è un tool molto semplice che consente la copia di files tra due cartelle in modo che il contenuto sia sincronizzato. Le due cartelle devono però essere locali (magari anche NFS) ma comunque collegate allo stesso PC.

E’ possibile con un’opzione effettuare l’rsync tra due PC, a patto che si possa accedere al PC remoto tramite ssh e che rsync sia installato su entrambi.

Vediamo la procedura.
– creiamo la chiave ssh sul server nel caso ancora non sia stata creata:

ssh-keygen -o -a 100 -t ed25519 -C "indirizzo@email"

oppure, per sistemi più vecchi:
ssh-keygen -q -P ""

– si copia sul server remoto:

ssh-copy-id -i ~/.ssh/id_ed25519.pub utente@server_remoto

oppure, per sistemi più vecchi:
ssh-copy-id -i ~/.ssh/id_rsa.pub utente@server_remoto

– fatto questo, si possono sincronizzare i files (prende i files da /var/www e copia in utente@server_remoto:/var/www):
rsync -avz -e ssh /var/www utente@server_remoto:/var/

Nota: bisogna prestare attenzione al nome della cartella di origine e destinazione, perché quella di origine viene aggiunta a quella di destinazione, ovvero nel caso precedente come destinazione va indicato solo /var.

Per fare solo un check dei file coinvolti da rsync, senza copiare effettivamente, aggiungere l’opzione -n (ovvero –dry-run).

Per copiare solo i file non esistenti nel server remoto (senza sovrascrivere quelli esistenti anche se diversi), usare l’opzione –ignore-existing.

enjoy!

In questo caso, l’uso di un tunnel SSH è l’ideale, sempre che si disponga di un server linux con IP pubblico da usare.

In pratica la situazione è questa:

raspberry 192.168.1.10
router/AP (doppio IP) 192.168.1.1/192.168.10.20
router/gateway pubblico 192.168.10.1/61.24.35.76

Pertanto, il raspberry per “navigare” passa attraverso il router/AP che a sua volta passa attraverso il router/gateway pubblico.

Raggiungere il raspberry da internet con questa configurazione non è possibile, a meno che non si possa configurare il router/gateway e poi il router/AP per inoltrare i pacchetti diretti verso una determinata porta del router/gateway verso il raspberry.

Abbiamo a disposizione un server linux con IP pubblico, ad esempio il 60.60.60.60.

Cosa possiamo fare?
Dal raspberry possiamo avviare un tunnel ssh verso il server linux e “dirgli” che se dovessero arrivargli pacchetti su una determinata porta, li deve girare verso il raspberry, tramite il tunnel ssh.

Questa cosa può essere fatta nativamente da SSH attivando un remote port forwarding.

Innanzitutto bisogna creare una chiave pubblica SSH sul raspberry e caricarla sul server linux. Non mi dilungo su questa parte.

Sul server linux bisogna inserire nel file /etc/ssh/sshd_config la seguente direttiva:
GatewayPorts yes

Successivamente, sul raspberry, dovremo lanciare il seguente comando:

ssh -R 2203:localhost:22 utente@60.60.60.60

dove 2203 e la porta da aprire sul server linux, 22 è la porta del raspberry che vogliamo risponda, utente@60.60.60.60 è l’utente e l’IP/FQDN del server linux

Cosi’ facendo, sarà possible collegarsi alla porta 2203 del server linux 60.60.60.60 tramite il client ssh e vedremo rispondere il servizio ssh del raspberry.

Ovviamente possiamo girare non solo la porta 22, ma anche altre porte, ad esempio la 80 se vogliamo rendere pubblico un servizio web su internet.

Riavviando il raspberry, purtroppo, il tunnel verrà interrotto. Per mantenerlo sempre attivo ed avviarlo in automatico in caso di reboot del raspberry, consiglio l’installazione del pacchetto autossh:
apt-get install autossh

e poi l’inserimento della seguente riga come penultima (prima di exit 0) del file /etc/rc.local:
autossh -2 -fN -M 20000 -R 2203:localhost:22 utente@60.60.60.60

In alternativa è possibile creare un file Systemd service per autossh. Creare il file /etc/systemd/system/autossh-tunnel.service con dentro:

[Unit]
Description=AutoSSH tunnel service
After=network.target

[Service]
Environment="AUTOSSH_GATETIME=0"
#-p [PORT]
#-l [user]
#-M 0 --> no monitoring
#-N Just open the connection and do nothing (not interactive)
# LOCALPORT:IP_ON_EXAMPLE_COM:PORT_ON_EXAMPLE_COM
ExecStart=/usr/bin/autossh -2 -fN -M 20000 -R 2203:localhost:22 utente@60.60.60.60
ExecStop=/bin/kill -9 autossh

[Install]
WantedBy=multi-user.target

Poi abitiliamo:

systemctl daemon-reload
systemctl enable autossh-tunnel.service
systemctl start autossh-tunnel.service

Per verificare:

journalctl | grep autossh

enjoy!

La chiave può essere generata su sistemi Linux con:

ssh-keygen -t dsa -b 4096 -C "email@example.com"

Avendo generato già la chiave in formato DSA, basterà copiarla via FTP sul mikrotik; i dati di connessione FTP sono quelli di un utente mikrotik attivo.

Dopo aver copiato la chiave id_dsa.pub via FTP, si può accedere alla scheda “System”->”Users” e poi dal tab “Import SSH Key” basterà digitare il nome utente e poi scegliere, da menù a discesa, la chiave precedentemente copiata via FTP.

enjoy!