Dec  8 03:19:33 localhost sshd[4718]: User root from 10.1.2.3 not allowed [...]
Dec  8 03:19:35 localhost sshd[4721]: Invalid user db2inst1 from 10.1.2.3
Dec  8 03:19:38 localhost sshd[4723]: User root from 10.1.2.3 not allowed [...]

fail2ban is configured to (temporarily) block these after a certain number of attempts, but they keep coming back. One particular IP address was hitting ssh constantly (except for the ban periods) for several days, so I added a rule to drop everything from that address — but this strategy isn’t scalable.

The simple, obvious solution is to only allow access from known hosts. It would be very rare that I need to access this server from anywhere except a small number of addresses. I started with a ufw (Ubuntu’s “uncomplicated firewall”) ruleset like this:

% sudo ufw status
Status: active

To                         Action      From
--                         ------      ----
Anywhere                   DENY        10.1.2.3
Anywhere                   DENY        172.16.99.88
22                         ALLOW       Anywhere

To avoid getting locked out, I added (temporarily) a crontab entry for root:

*/15 * * * * /usr/sbin/ufw allow ssh

This will allow access to ssh from any un-banned IP address (the current policy) every 15 minutes. Then I inserted a rule that allows access to ssh from my home ISPs netblock. (You can figure out the netblock by doing a whois lookup on your external IP address; you may need to add multiple netblocks if your ISP has several allocated. Be careful: it’s no fun to get locked out!) This action is safe because I have not yet removed global ssh access. Note that I’m using “insert 3″ to add this rule at a specific position in the list.

sudo ufw insert 3 allow proto tcp from 10.9.8.0/18 to any port 22

And I added a rule to permit access from another server with a fixed IP I have access to (for the rare case where I need to access this server when I’m not at home):

sudo ufw insert 3 allow proto tcp from 172.17.101.102 to any port 22

Now my ruleset looks like:

Status: active

To                         Action      From
--                         ------      ----
Anywhere                   DENY        10.1.2.3
Anywhere                   DENY        172.16.99.88
22/tcp                     ALLOW       172.17.101.102
22/tcp                     ALLOW       10.9.8.0/18
22                         ALLOW       Anywhere

So far, so good, but ssh access is still permitted from anywhere — because of that last rule. This is the dangerous part… you could get locked out if you haven’t set the rules correctly. (You set up that crontab entry, right?)

sudo ufw delete allow ssh

Wait for the prompt… hooray, I’m still connected! After checking that I can access ssh from home and the other server, I know it’s safe to remove the crontab job. (If the cron job has already fired, you’ll need to rerun the ufw delete allow ssh command.)

At this point I can delete the first two rules that ban specific IPs, since they’re outside my netblock and won’t be allowed anyway.

Now I can enjoy quieter logs without all those access attempts from China and Croatia!

SSH makes it trivial to use that VPS as a SOCKS5 proxy. Just do:

ssh -D 8080 myvps.example.com

Then set your browser’s SOCKS proxy to localhost:8080. In Firefox on Linux, this is Edit > Preferences > Advanced > Network tab > (Connection) Settings > Manual Proxy Configuration. Leave all fields blank except for SOCKS Host and Port — localhost and 8080, respectively. Choose SOCKS5. Then browse to about:config and change change network.proxy.socks_remote_dns to true. This tells Firefox to ask the proxy to resolve names instead of trying to resolve them using your ISP. Chrome worked for me without hassle.

Go to test-ipv6.com to test that it works. If your results from test-ipv6.com indicate that IPv6 name lookups are failing, make sure you’ve got that about:config setting mentioned above changed.

Let’s say you have a half-dozen machines at work you want to log into. Instead of setting up a remote forwarding connection from each of those machines, you can have the connection from your main machine perform multiple forwardings instead of just one. This even works if some of the machines don’t support ssh.

It shouldn’t surprise you at this point that you can do this with your config file. On your work machine, you might have something like:

Host tunnel
  HostName cloud.example.com
  User mycloudusername
  IdentityFile ~/.ssh/id_dsa
  Port 22
  RSAAuthentication yes
  PubkeyAuthentication yes
  ExitOnForwardFailure yes
  # tunnel ssh to myworkmachine
  RemoteForward 4022 localhost:22
  # tunnel remote desktop to mywindowsbox via myworkmachine
  RemoteForward 5389 192.168.4.10:3389
  # tunnel http to mywindowsbox via myworkmachine
  RemoteForward 5080 192.168.4.10:80
  # tunnel remote desktop to otherwindowsbox via myworkmachine
  RemoteForward 6389 192.168.4.11:3389
  # tunnel ssh to workserver via myworkmachine
  RemoteForward 7022 192.168.4.2:22

You can add a bunch of forwardings as shown above. Each entry will open the given port on cloud and forward it to the specified port on the specified machine. Now when you run “ssh tunnel” on your work machine, it will connect to cloud and set up the five port forwardings specified in your config file.

Then when logged in to cloud.example.com, you can do, for example, “ssh -p 7022 myserverlogin@localhost” to log into the machine called workserver.

If you mirror the remote forwardings in your home config file as local forwardings, then when you “ssh work” from home you can remote desktop to a windows machine from your home pc by doing “rdesktop -u myworkwinuser localhost:5389″ and it will use the tunnel. (The connection will go from your home pc to cloud, to myworkmachine, to mywindowsbox.) The windows machine does not need to know anything about ssh.

As I mentioned in a previous post on ssh configuration, your config file can specify a variety settings for each server.

In fact, the Hosts you use don’t even have to exist! (The HostName is the important part.) Consider the following snippet in your ~/.ssh/config.

#
Host work
  HostName localhost
  User myworklogin
  IdentityFile ~/.ssh/id_dsa
  Port 4022
  RSAAuthentication yes
  PubkeyAuthentication yes
  LocalForward 4022 localhost:4022

I’m going to assume remote forwarding is set up and the connection is open from work to cloud as described in this post on remote forwarding; and you’ve got local forwarding set up from home to cloud as described in this post on local port forwarding.

Now you can do “ssh work” from your home pc, and it will automatically log you into your work pc with the right credentials using the tunnel on cloud.example.com. And the scp example above simplifies to “scp work:/tmp/foo.txt ~/foo.txt” — you don’t have to remember the forwarded port numbers.

Typing “ssh work” is nine keystrokes (eight letters plus enter). If you can type 40 wpm, that’s 200 keystrokes per minute, or 3.33 keystrokes per second, which means you can open the tunnel in four seconds!

If you add “alias ssw=’ssh work’” to your ~/.bashrc, you’re down to four keystrokes.

Local port forwarding is the same as remote port forwarding but works in the opposite direction. An example is the clearest way to explain.

Assuming you’ve done the steps in the previous posts, then at home you can run “ssh -L 4022:localhost:4022 me@cloud.example.com”. This listens on TCP port 4022 on your home machine. Any connections there will be forwarded through the ssh connection to port 4022 on cloud… which, as we recall, gets forwarded to port 22 (ssh) at work. If you leave this connection open, you can run “ssh -p 4022 localhost” on your home machine and it will connect to work in just one hop. This means that you can use scp to copy files from home to work or vice versa. For example, “scp -P 4022 localhost:/tmp/foo.txt ~/foo.txt” will copy a file from work to home. (Note: scp needs capital “-P” to give the port. I got it wrong the first time.)

Ssh tunneling can be a bit mind bending at first, but it’s simple when you get used to it. Assume that you’re trying to ssh between two sites that do not allow incoming ssh. Maybe your IT at work is unenlightened and doesn’t have an ssh gateway. And your ISP has braindead configuration rules that don’t allow incoming ssh or they make it difficult.

What you need to get around this is a server “in the cloud” that permits ssh logins. This could be a hosting server that you pay for, or even a friend with an enlightened ISP who will give you a login account.

On your work PC, use ssh to login to the “cloud” server. Using the “-R” argument, you tell ssh to listen on a TCP port on the cloud server. Any connection coming in to this server will be forwarded back through the ssh connection to the TCP port you specify. For example, on mymachine.work.com, “ssh -R 4022:localhost:22 me@cloud.example.com” tells ssh to listen on cloud’s port 4022. Incoming connections to that port on cloud will be forwarded to port 22 (ssh) on mymachine.

By default, ssh will only listen to port 4022 on cloud’s localhost interface. So to log in to work, you will first need to log into cloud, and then use “ssh -p 4022 myworklogin@localhost” to log into work.

We’ll work around this limitation in the next post in this series.

The capability that you probably aren’t using, and the easiest to use, is customizing your config file (in ~/.ssh/config) for the various servers you log into.

For example, I frequently log into about ten different servers using at least four different usernames. By default, if I type “ssh server” the client will use my login name on the client machine to try to log into the server — which is usually wrong. Instead you can tell your ssh client which username to use on each server. (Thanks to Rich Adams for the tip.)

You can customize a variety of settings — not just the username. For example, I specify a different identity file for a couple of servers.

This saves a bunch of typing and occasional confusion. (By avoiding login errrors as I try to log into a server using the wrong username and can’t figure out why my password isn’t working…)

(This is the first post in series of posts about how to get the most out of ssh. Make sure you don’t miss the rest of the series: subscribe to my feed or follow me on twitter.)