7 Cool things you can do with SSH 

It’s been a while since I’ve written an article, so I thought I’d make it a big one before I get bogged down with College work again. Here we go…

SSH (Secure Shell) is often thought of as a secure replacement to Telnet, that is only really capable of remote login, which, while cool in itself is far from SSH’s true potential.

The truth is, SSH is one of the most powerful and extensible programs I have ever used, it can be used for any number of wildly different things, most of which I will demonstrate in this article.

• Remote Login
• Tunneling
• Dynamic Tunneling (SOCKS)
• Remote File Transfer (SCP)
• Xorg Forwarding
• SSHFS
• AutoSSH

As you can see from the list above, I will be talking about some of the most interesting things that SSH is capable of, dig in!

Remote Login

Remote Login is of course the purpose for which SSH is most often used, and for a good reason. SSH is basically the only option when it comes to a secure remote login, with the only other alternative being Telnet, which is so far from secure it’s practically on Venus.

So, let’s discuss how a basic login will work, using the SSH command (which is preinstalled on any respectable Linux distribution and Mac OS X) type:

ssh user@example.com

If SSH is operating on a port other than its default port 22, the –p parameter is used to specify the port manually. Here’s an example:

ssh user@example.com -p 8000

In the above, a connection will be opened on port 8000 for “user” on example.com, using this very basic command on a computer with openssh-server running you will be able to log in remotely after typing a password.

It is also possible to enable passwordless SSH using public-private key cryptography, but really this should only be used on a closed network because if the private key gets out then your network will be compromised.

Tunneling

Tunneling is a system whereby a port – which could be used by a service like a Web Server, SSH server, or basically any daemon — is “tunneled” to another computer, where that computer will be able to access whichever service is listening on that port on the localhost.

So, what possible reason could anyone have for using this you may ask? Well, let’s say there is a computer that is behind a firewall. The firewall only permits access to SSH, and you want to login to the VNC server that is running on a computer in the network.

So, to get around this little hurdle, we’ll “tunnel” port 5900 (the port on which VNC operates) to the localhost, and then use our VNC client to connect to 127.0.0.1:5900. Let’s say that firewalled.com is the domain, and bob is the user:

ssh –L 5900:localhost:5900 bob@firewalled.com

The above will connect to the host, and tunnel port 5900 on that host to the localhost, allowing you to connect.

Of course, you could expand this to allow multiple ports to be forwarded, for example, if you also wanted to forward the Web Server on firewalled.com, you could do:

ssh –L 5900:localhost:5900 –L 80:localhost:80 bob@firewalled.com

As you may have noticed, there are two options for ports in the above commands; this is for the local port and the destination port. That is, the port that it is, and the port that you want it to be. Say you already have a Web Server on your localhost and you want to tunnel a Web Server from firewalled.com, you can simply forward it to port 8080 on the localhost:

ssh –L 8080:localhost:80 bob@firewalled.com

Dynamic Tunneling

We’ve already talked about tunneling, but what if you are locked into a network that blocks certain websites, or you have a series of remote Web Servers that are not exposed to the Internet and you need to access them, you know, for work-related purposes.

This is where Dynamic Tunneling comes in, every time you go to a website several ports are used up, these ports are all random and above port 1000, one new port is created for every TCP connection made, meaning that in order to successfully browse the Internet with port forwarding you would have to be able to open and close ports dynamically, hence Dynamic Tunneling.

Now that I have explained what you might use it for, I will explain how to use it, and it’s very simple:

ssh –D 1234 user@example.com

The above will open a port on your local host that can be used to tunnel traffic though dynamically. For this to work you will need to reconfigure your browser or your VNC Client or whatever to use a SOCKS proxy running on (in this example) 127.0.0.1 port 1234.

What will happen here is a port will be dynamically created every time you make a connection and passed through this port. This includes DNS, so if you have a DNS Server your LAN and the computer you’re using as a tunnel uses it then you can use your local domain names e.g. testwebsite.lan through the tunnel with no problems.

Remember, if whichever corporation is restricting you also blocks port 22 you can change the port that SSH operates on in the SSH Server configuration file, usually located in:

/etc/ssh/sshd_config

Just find the line that says:

Port 22

And replace it with:

Port 3245

Or whatever your network will allow. My college, for example, will only allow Web-related traffic to pass through the network, that means no FTP, SSH, VNC, etc. But using Dynamic Forwarding, and configuring my SSH Server to listen on port 443 I can do whatever I like over (technically) my own network.

Also, if your College, School or University is particularly totalitarian, they might even look at what type of data is being sent over their network. The beautiful thing about this is that if I tell SSH to listen on port 443 (a port used for SSL encrypted HTTP connections) then the traffic will look the same as it would if I really were browsing a website, as SSH uses SSL for encryption. Completely bulletproof.

Remote File Transfer (SCP)

We’ve covered two brilliant things that SSH can do already, but what if we want to transfer a file over SSH?

Well, just like Tunneling, SSH supports remote file transfer natively (that means without needing modification, btw). The most obvious option is a tool that comes in the openssh-client package: SCP.

SCP (Secure Copy), is a tool that allows you to copy a file (or a series of files) to a host that has an SSH Server running. The syntax is like this:

scp file user@example.com:/put/me/in/this/folder

The above will copy “file” in the local directory to “/put/me/in/this/folder” on the remote host. The inverse can be done like so:

scp user@example.com:~/file .

Which will copy “file” from the home directory of “user” on example.com to the current directory.

“So, copying one file is all well and good, but what if I want to copy a whole folder?” You ask yourself. Well, if you are even slightly inept at using standard Unix tools, you will be familiar with the “cp” command. If you are, think of “scp” as “cp”, but for sending files over the network. As such, the parameters are much the same, of course — just to be annoying – the developers of scp chose to use a lowercase –r for recursive copying, as opposed to cp’s –R (although, to be fair –r still works in cp…). As such, copying an entire directory is simply:

scp –r directory user@example.com:~

…Or…

scp –r user@example.com:~/directory .

The above are respectively for copying a folder to a server and from a server.

So, you have another question: “If SSH encrypts everything, doesn’t that make it slower at copying?” To which I say… No!

10.3MB is fast enough, don’t you think? I’ve seen it faster, but the speed is also limited by other variables such as bandwidth, Hard Drive Speed, etc. But my point stands and SCP is fast enough.

Okay, so one last example of how brilliant SCP is may be required before I finish this section… how about chaining hosts?
“What is this ‘Chaining Hosts’ of which you speak” you ask, well, I will show you by example: If I have a server which I can only access through another server, and I want to copy “uporn.avi” from it, what do I do? Obviously I cannot go without my uporn.avi, so I…

scp user@firsthost.com user@unaccessible:~/uporn.avi .

And voila! I have my uporn. (Yes, I am relentless in my uporn downloading.)

SSHFS

So, SCP is all well and good, but what if you want to actually mount a remote directory, just like you mount a partition on your Hard Drive? Well, you use SSHFS.

SSHFS (Secure Shell File System, as you may have determined) is used for mounting remote SSH file systems, and, the only drawback to using it is that it is not a default part of openSSH. As such, it’s another thing that you’ll have to set up, but still, it’s basically a matter of:

sudo apt-get install sshfs

But you know some people might not want to do that, or something. Anyway, this is how it goes:

sshfs user@example.com:/remotefolder /media/remotefolder

You may notice the syntax is somewhat similar to that of SCP; well it is, so that’s better for you, yes?

That’s basically all SSHFS does, everything in /remotefolder is the same as it is on the remote host, change files, add them, delete them, etc. It’s just like using a remote share like those fancy SMB doohickeys.

AutoSSH

We’re nearly done with our list of cool things, but there are two more things, among them AutoSSH. So, here’s a pretext: Let’s say I am on a computer with an SSH Server that is sitting behind a firewall with no connections being accepted over the network. Despite this inconvenience, I want to connect to this server from my other computer, one that I can connect to over the Internet.

So, to get around our little debacle, we’ll forward port 22 (SSH) on our localhost to port 3000 on the accessible host. The problem with this plan twofold: 1. The connection will time out after a certain amount of time, breaking the tunnel and 2. The Terminal will have to remain open (and accessible) for anyone, creating a bit of a security risk.

This is where AutoSSH comes in, AutoSSH solves both problems, keeping the connection alive no matter what, AutoSSH monitors the connection, making that it is still active and if the connection becomes unresponsive it terminates and reconnects allowing a tunnel to remain open indefinitely.

AutoSSH can also be run in the background, eliminating the second risk.

So here’s how it works:

sudo autossh –M 1001 –f –R 1337:localhost:22 user@example.com

What this will do is forward port 22 on the localhost to port 1337 on example.com, AutoSSH will go to the background so that nobody can interfere with the connection and will also keep the connection active so long as AutoSSH is not terminated and the computer remains powered on.

Once again, AutoSSH is a utility that is not default to openSSH, so you will have to install it, but it’s not hard to install so I don’t suspect you will have any problems with that.

X11 Forwarding

The final “cool thing” which SSH can do is X11 Forwarding. Let me explain what this is. X11 is the Graphical Server on Linux and other Unix-Like (or *nix, if you prefer) Operating Systems. Basically X11 is used to render anything Graphical.

What X11 Forwarding allows you to do is forward an application over the network from the computer that you are connecting to, allowing you to use applications as if they were installed on your local computer. But there is a reason this “cool thing” is mentioned last, because in order to get X11 Forwarding to work well you need a lot of bandwidth, and even then it isn’t that fast, but still, it’s built into SSH and it’s pretty cool.

Of course, for security reasons this should be disabled by default, as because X11 is forwarded, so is everything you type, which makes it possible for things like passwords and usernames to be captured. (So don’t enable it by default, only when you need to use it!)

So, as you can see in the above screenshot, SSH forwarding works, and is pretty cool. In fact, in a fast network (Let’s say 100Mb/s) it is far better than VNC (although VNC is still better for spying purposes.)

So here’s how you do it:

ssh –X user@example.com

Yes, that’s pretty much it. Once you’re logged type the graphical application of your choice’s command and that application will be forwarded to your local X11 Server. Of course this works best on Linux, because X11 is everything, so on OS X or Windows (with Xming) it doesn’t work as well (but it still works).

Here’s a tip before I finally go, if you’re running a forwarded program any you still want to use the terminal (be it to run more programs or to use good ol’ BASH) put a little ampersand after the command e.g.

firefox &

This will redirect output and keep the shell free for more inputty goodness.

I hope you’ve enjoyed the article and I also hope you have begun to understand just how many uses there are for one of the most fully featured daemons on Linux, it is by far that Emacs of the deamon world. Thank you for reading.