Articolo di Truelite.it pubblicato sul loro utilissimo wiki
Ci sono molte occasioni in cui occorre creare delle connessioni verso macchine e servizi che sono protetti da firewall in quanto è opportuno proteggerli adeguatamente, ma per i quali la creazione di una VPN diventa un onere eccessivo.
Per questo la capacità di port forwarding di SSH è molto utile per creare un tunnel cifrato da una macchina ad un’altra, consentendo anche di condividere accessi locali (come ad esempio ad un MySQL che ascolta solo localmente) in maniera sicura, con il solo problema che in caso di problemi la connessione SSH (ed il relativo tunnel) potrebbero cadere.
Per ovviare a questa eventualità e consentire di creare tunnel permanenti ci viene in aiuto autossh un semplice programma che consente di eseguire una istanza di ssh mantenendola sotto controllo, e riavviando la stessa qualora la connessione dovesse cadere fino ad un numero massimo di volte controllato dalla variabile di ambiente AUTOSSH_MAXSTART o indefinitamente se il valore di questa è negativo (comportamento di default).
Il programma infatti rileva se l’istanza di ssh che ha lanciato termina per un segnale o un errore di connessione e nel caso la riesegue, se invece si termina ssh con un segnale di SIGKILL autossh interpreta la cosa come una terminazione esplicita, e si ferma. Allo stesso modo viene interpretato un segnale di terminazione a autossh stesso, che nel caso esce terminando anche l’istanza di ssh.
Il comando prende una opzione principale, -M che consente di indicare una porta di monitoraggio della connessione (per verificare cioè che l’istanza di ssh sia attiva e funzionante utilizza la porta indicata e la successiva per mandare dei messaggi che gli devono tornare indietro). Con la versione 2 del protocollo ssh supporta un controllo interno della connessione, che è più affidabile, pertanto si suggerisce di usare le opportune opzioni di controllo (che vedremo più avanti) ed indicare sempre un valore nullo (cioè -M 0) che disabilita questo monitoraggio.
Il resto del comportamento del programma è controllato da una serie di ulteriori variabili di ambiente per il significato delle quali si rimanda alla lettura della pagina di manuale (i valori di default sono adatti all’uso ordinario, possono essere modificati in caso di problemi o per attivare diagnostiche).
L’uso di autossh consente di creare un numero arbitrario di tunnel in maniera molto sicura, se infatti non è necessario mettersi in ascolto su porte riservate, si può far eseguire il programma per conto di un utente non privilegiato, che nel nostro caso sarà appunto autossh. Si provvederà allora a creare detto utente su entrambi i capi del tunnel con:
useradd -m -s /bin/false autossh |
e si noti come per l’utente si sia disabilitata la shell e non si sia impostata la password, cosa che renderà impossibile usare l’utente per un accesso al sistema (che non ci serve essendo esso utilizzato solo allo scopo di creare il tunnel).
La scelta di non impostare la password richiede l’uso della autenticazione a chiavi, cosa che è comunque il caso di usare sempre e se possibile in maniera esclusiva. Per questo sul capo della connessione che deve creare il tunnel si dovrà creare una chiave per l’utente, che, se si vuole che il tunnel possa partire automaticamente all’avvio, dovrà essere senza password; pertanto si dovranno eseguire i seguenti comandi:
root@hain:~# su -s /bin/bash autossh autossh@mail:/root$ ssh-kegen Generating public/private rsa key pair. Enter file in which to save the key (/home/autossh/.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/autossh/.ssh/id_rsa. Your public key has been saved in /home/autossh/.ssh/id_rsa.pub. The key fingerprint is: b6:b7:d5:1e:fd:b0:62:57:b5:77:4c:33:82:78:f7:06 autossh@dodds The key's randomart image is: +--[ RSA 2048]----+ | | | | | . . | | . o E oo| | S . . +o=| | . . . ==| | . . . =.+| | . oo..+.| | .. oo .| +-----------------+
(è necessario usare su con il primo comando per impersonare l’utente autossh dato che questo non ha una shell né una password valida).
Una volta fatto questo si dovrà aver cura di copiare la chiave pubblica sulla/e macchina/e di destinazione ed installarla nelle home degli utenti autossh ivi creati sotto .ssh/authorized_keys; si verifichi che detto file appartenga ad autossh.
Una volta fatto questo si potrà creare un tunnel semplicamente lanciando il relativo comando di ssh tramite autossh. Dato che si vuole solo creare il tunnel occorrerà usare l’opzione -N per dire a ssh di non lanciare nessun comando, l’opzione -f per mettersi in background, inoltre sono importanti le opzioni:
-o "ServerAliveInterval 60" -o "ServerAliveCountMax 3"
che consentono di attivare il contollo interno della sussistenza della connessione di ssh; il tunnel potrà poi essere attivato con le solite opzioni -L o -R a seconda della direzione.
Se allora ad esempio si vuole creare un tunnel per la connessione ad un database MySQL remoto di una macchina che è raggiungibile in SSH, una volta creati gli utenti, come descritto, sarà sufficiente eseguire il comando:
su -s /bin/sh autossh -c 'autossh -M 0 -q -f -N -o "ServerAliveInterval 60" -o "ServerAliveCountMax 3" -L 3306:localhost:3306 autossh@remotemachine' |
ed almeno la prima volta accettare la validità della fingerprint della chiave.
Per abilitare il tunnel in maniera permanente all’avvio la cosa più semplice è inserire il comando in /etc/rc.local o file analogo per il proprio sistema di avvio.
Popular Posts:
- None Found
You may want to have a look at this startup script for autossh: http://surniaulula.com/2012/12/10/autossh-startup-script-for-multiple-tunnels/. You can create multiple tunnel connections, and start/stop each one independently. 😉
js.
Hello jean,
Thanks a lot for your info and your init script.
I’m not sure why but the “-q” switch you include does not appear to work on CentOS 6.4. And even though it “fails to work as expected”, unfortunately the command still appears in ps afwwwx | grep 8888 and doesn’t output any errors I could see explaining the failure reason.
The following command definitely does work:
su -s /bin/sh autossh -c ‘autossh -M 0 -f -gNC -o “ServerAliveInterval 60” -o “ServerAliveCountMax 3” -oPort=8888 -L1522:localhost:1521 -L11000:localhost:10082 -L11001:localhost:80 -L11002:localhost:443 -L5903:localhost:5901 autossh@remoteservername’
I hope this is of use to someone
Ricki
To enable the tunnel permanently at boot the easiest thing to do is to put the command in /etc/rc.local or similar files that are run at your system startup.
Need to specify the full path of autossh command
su -s /bin/sh autossh -c ‘/usr/local/bin/autossh -M 0 -q -f -N -o “ServerAliveInterval 60” -o “ServerAliveCountMax 3” -L 3306:localhost:3306 autossh@remotemachine’
If you don’t include
-o ExitOnForwardFailure=yesas an option when autossh reconnects after an interruption you’ll getWarning: remote port forwarding failed for listen port #####.This is because the host you’re connecting too may not realize the previous connection has died, and is still occupying the port. While the new autossh connection will succeed, it wont open a tunnel and autossh wont restart since it thinks the connection is okay.
Hi,
Thank you so much for this great tutorial, I was trying to figure out a way to do it since yesterday.
I did as written above and I can’t connect to autossh@localmachine but only to root@localmachine.
I created a user as described :”useradd -m -s /bin/false autossh”
I created the RSA key.
And when I tried to copy the key to the local machine with: “ssh-copy-id autossh@localmachine” I had to enter a password even though I didn’t set one.
The only way for me to get it working was by transferring the key to root@localmachine. Then I was able to enter the password and now it worked.
I’m wondering if it is safe to make the remote device connect to the root ?
Best regards,
Johann
Would have been nice to tell us what autossh is, and where to get it? I’m guessing it’s a shell script from some random place?
http://www.harding.motd.ca/autossh/
If you use ubuntu/debian or mint you already have it on your standard repositories
I ran into issues using this method.. after a lot of hunting, testing, and research (I’m no expert on Linux) it turned out that my autossh user on the “local” server was locked out. If you check /var/log/auth.log you should see a series of errors for that account if this affects you. Since I am using unsigned keys to establish the tunnel, I didn’t want to authenticate to my account in case the key gets compromised.
the user was set to /bin/false in /etc/shadow, so it couldn’t log in and apparently couldn’t establish the tunnel. I unlocked the user
passwd -u autossh(if I remember right), and set a 24 random character password to the account since I never need to log into it using the password (and can’t according the shadow file.I hope this helps someone else from the headaches that I just went through.
Typo: ssh-kegen should be ssh-keygen
[…] Permanent SSH Tunnels with autossh […]
the command was running but no connection was being made, I had to
replace things like these -o “ServerAliveCountMax 3 with –o “ServerAliveCountMax=3”
the “=” sign was critical, everything works fine now.
my final command
autossh -M 0 -q -f -gNC -o “ServerAliveCountMax=3” -o “ServerAliveInterval=10” -o “ExitOnForwardFailure=yes” -R xxxx:localhost:22 auto ssh@remotehost
just in case it helps anyone who might be struggling
Ravi’s last comment above (#10) was huge…. huge….. help, and absolutely spot on. I had been struggling with frustrating timeouts on large multi-hundred-MB git pulls for weeks…. and his point about “=” sign being critical in the -o options is 100% correct.
I put those in my autossh command, and presto — no timeouts, the git pull runs, and everything works.
Ravi — thank you!!
Ravi’s last comment above (#10) was a really huge…. huge….. help, and absolutely spot on. I had been struggling with frustrating timeouts on large multi-hundred-MB git pulls for weeks…. and his point about “=” sign being critical in the -o options is 100% correct.
I put those in my autossh command, and presto — no timeouts, the git pull runs, and everything works.
Ravi — thank you!!
-Ian