Here, my aim is to be able to connect to this remotely located Pi - I've pretty much followed the post here to do this using 'autossh'. http://linuxaria.com/howto/permanent-ssh-tunnels-with-autossh?lang=en
My 'local' server is a also a RPi, and I've allowed access through my firewall to this pi on port 22 - let's call it 'localpi', and the remote pi 'remotepi'
I have tested that access can work in the following way.
1. - On 'remotepi', bring up the 3G link and then, ssh -R 2222:localhost:22 localpi.mydomain.com
This allows me to login to 'localpi' from my remote location.
2. - Now, the crux - can I login to 'remotepi' from 'localpi'? - ssh -p 2222 localhost - Yes, that works fine.
3. - Now, we know comms now work and can start automating the setup / link. On remotepi - sudo apt-get install autossh
4. - On localpi - sudo useradd -m -s /bin/false autossh
5. - On remotepi - sudo useradd -m -s /bin/false autossh
6. - On remotepi, run sudo su -s /bin/bash autossh
7. - On remotepi, run ssh-keygen. Leave with empty passphrase and default location for the id.
8. - Transfer the id_pub key from 'remotepi' and enter into 'localpi' into ~autossh/.ssh/authorized_keys
9. - Do the same thing on localpi, and transfer the id_pub to ~autossh/.ssh/authorized_keys on remotepi - this way the connection for autossh will work both ways if necessary (and I'm not sure it is, but you never know...) - [ Note - It might be obvious, but you put the generated public key into the authorized_keys file on the host TO which you need to connect. - That way, you don't need a password when logging into that host. - Therefore, I actually did this backwards in the above.]
10. - On remotepi. - sudo su -s /bin/bash autossh
11. - On remotepi, bring up the link manually initially so you can accept the connection. - Future connections don't need to be interactive, though if 'localpi' changes it's IP address (for example if the broadband restart), then it might be necessary to do this step again.... - as user autossh on remotepi, run autossh -R 2222:localhost:22 localpi.mydomain.com
12. - Drop the ssh connection from step 11.
13. - Now try the 'whole' command on remotepi. - i.e. autossh -M 0 -q -f -N -o "ServerAliveInterval 60" -o "ServerAliveCountMax 3" -R 2222:localhost:22
14. - On localpi, I should now be able to run ssh -p 2222 pi@localhost and get connected to 'remotepi', provided the link is up. - Great. All that remains is to script it so it starts on boot, and test it.
1. - Put into /etc/rc.local:-
sudo su -s /bin/sh autossh -c 'autossh -M 0 -q -f -N -o "ServerAliveInterval 60" -o "ServerAliveCountMax 3" -R 2222:localhost:22 email@example.com'
- Reboot the remotepi. Does this start? - Yes, it does. - Great.
- Now bring up the 3G link on the remotepi. - Does autossh connect to 'localpi' without intervention? - Yes, it does! - Excellent. - So, now if I bring up the link periodically, then I should be able to make remote connection. - Cool.
- What I have found which isn't perfect is that the 'autossh' session which is established on 'localpi' doesn't ever seem to die when the link is dropped. - The solution here is to kill all 'autossh' sessions on 'localpi', then await the reconnection from 'remotepi' before trying to ssh to remotepi. - This seems to work reliably.
- I've setup the script to bring the connection up for 15 minutes every hour, so this should give me time to connect if necessary.