Previously, we looked at the basics of key management in OpenSSH, which in my opinion, really need to be understood before you start to play with all the other fine trickery OpenSSH offers. Key management is important, and easy, and now that we all understand how to manage keys, we can get on with the fun stuff.
Because I take OpenSSH for granted, I don't really think about what I do with it. So here are some pointers and tips to various SSH-related commands that can make life easier, more secure, and hopefully better. This really is just the tip of the iceberg; there is so much more that OpenSSH can do, but I hope this at least gives you some new tricks and inspires some further investigation.
Running remote X applications
If you want to run a remote X11 program locally, you can do that via OpenSSH, taking advantage of its encryption benefits. With X running, open a terminal and type:
$ ssh -fX user@host firefox
This will fire up FireFox on the remote computer, and display the output over an encrypted SSH connection on the local display. You will need X11Forwarding yes enabled on the remote server (usually it is; if not, check /etc/ssh/sshd_config or /etc/sshd_config).
Easy connections to remote using screen
When you first log into a system and run screen, you have multiple terminals open that can be switched around. If you need to disconnect from the system, have a network outage, or switch from one wireless network to another, running the remote session under screen will prevent whatever processes are currently running from terminating prematurely. However, when you do run screen like this, typically you would log in directly and then start, or resume, screen.
Instead, you can do this with one command, which has the advantage of logging you out immediately when disconnecting from the screen:
$ ssh -t user@host screen -r
This also has the benefit of not starting an extra shell process just to launch screen. This will not work, however, if screen is not already running on the remote host.
Also note that you can run almost any command remotely, like this. The -t command forces pseudo-tty allocation, so you can use this to run simple commands, or interactive commands like a MySQL client login, or alternatives to screen like tmux.
Encrypted tunnels to remote hosts
This is one of the best uses of OpenSSH. With tunneling, you can tell OpenSSH to create a tunnel to a port on the remote server, and connect to it locally. For instance, if you run a private web server, where port 80 is not available to the internet (via a firewalled port), you can use the following to connect to it:
$ ssh -N -L8080:127.0.0.1:80 user@remotehost
Then point your browser to http://127.0.0.1:8080 and it will connect to port 80 on remotehost, through the SSH tunnel. Keep in mind that, for web connections at least, it will only connect to an IP, so name-based virtual hosting is out, or at least reaching a name-based virtual host would be.
On the other hand, if you have a MySQL service or some other firewalled service, you can use the same technique to get to that service as well. If you wanted to connect to MySQL on remotehost you might use:
$ ssh -N -L3306:127.0.0.1:3306 remotehost
Then point your MySQL client application to the localhost (127.0.0.1) and port 3306. The general syntax of the -L command is "local_port:local_ip:remote_port".
Creating a SOCKS5 proxy
One really neat thing OpenSSH can do is create a SOCKS5 proxy, which is a direct connection proxy. This allows you to tunnel all HTTP requests, or any other kind of traffic that can be sent through a SOCKS5 proxy, via SSH through a server you can access. This might be useful at a coffee shop, for instance, where you want to direct all HTTP traffic through your SSH proxy to your system at home or the office, in order to avoid potential snooping or data theft (looking directly at you, FireSheep).
The command I use to create the SOCKS5 proxy using OpenSSH is:
$ ssh -C2qTnNM -D 8080 user@remotehost
This creates a compressed connection that forces pseudo-tty allocation, as well as places the ssh client into master mode for connection sharing (see man ssh for more details on the other options). The proxy will live on port 8080 of the local host. A quick test is to use something like curl with whatismyip.com:
$ curl —socks5 127.0.0.1:8080 www.whatismyip.com/automation/n09230945.asp
Call curl with that command, then compare it to using curl on that URL directly and you should see two different IP addresses — the first being the remote server's IP, and the second being your own.
Since curl is really only useful for testing, check out FoxyProxy for Firefox in order to make Firefox use the proxy.
These are just a few things that OpenSSH can do, but I think they're very useful. OpenSSH truly is a ubiquitous Swiss-Army knife utility; it is pre-installed and available on pretty much every major operating system with the exception of Windows. It may be intimidating if you're just figuring it out for the first time, but spend some time playing with it and that investment will definitely pay off.
Vincent Danen works on the Red Hat Security Response Team and lives in Canada. He has been writing about and developing on Linux for over 10 years and is a veteran Mac user.