So your work place is extremely security conscious: they use alternate ports for ssh, only allow ssh keys, and have their firewall locked down to your specific ip address ONLY. You, on the other hand, want to live the dream of developer ubiquity: work anytime, from anywhere. One way might be to ssh to wherever your static ip address is located, and then ssh from there to your work server, but that is just a pain. Here is how to ssh in one simple step.
First some terms:
- let my_den be your home, home office, hosted server, or anywhere from which you can ssh directly in to your works secured server.
- Let my_work be your super secure sensitive special server that you can only reach from behind your ip address.
In order to keep things real simple, the method I used was to append a suffix to any domain that I wanted to “pipe” via my_den on its way onward. So:
- let .vmd be a shortcut for Via My Den.
Anytime we want to ssh to my_work (or anywhere really) and we want to to be coming from my_den, all we need to do is to append .vmd to the host name, so like:
In order to set this up, we need to edit our ssh config file (generally located at ~/.ssh/config), and add the following:
Host *.vmd ProxyCommand ssh -W$(basename %h .vmd):%p my_den User root PreferredAuthentications publickey IdentityFile ~/.ssh/my.ssh.key
Where is what were doing, line by line:
- Establishing a new host configuration, for any host ending with .vmd
- Telling ssh to proxy this connection via my_den. Notice how we strip off the .vmd suffix ($(basename %h .vmd) - %h is a placeholder for the hostname we called, in our case my_work.vmd) and pass that hostname to ssh’s -W command (you ned ssh 5.2+ for -W to work)
- We tell ssh to use the user root. This is equivalent to specifying ssh some_user@myhost, adjust as necessary - this line is optional
- Tell ssh we don’t want it to try to use a password when connecting to my_work. This speeds up the connection ever so slightly and is optional
- Tell ssh what key file to use. Optional. You may prefer to specify this from the command line (using the -i option) if you need to use a different key for different servers.
In this specific example, I already have an entry for the my_den server that specifies the ssh key and other settings for the first “hop”, making this a really simple hit-enter-and-your-in affair. If you don’t have ssh keys, ssh will prompt you for two passwords: for for hop 1 (i.e. my_den) and then for hop 2 (i.e. my_work). I strongly suggest setting up ssh keys for both connivence and security.