Securing SSH

This post is about what I have learned for protecting SSH (Secure Shell) from being hacked. Please advise me if I miss or get something wrong.

Username and Password

Do not use common words as your username or password, neither use your username exactly as your password. This applies everything needs your username and password. Read Password strength, if you need a good password. In my opinion, if you need to write down something in somewhere for your password including using softwares, then that’s not a good password. Currently, our brain is the best safety, but not quite liable.

When I saw someone trying to get into my laptop, they usually try names like bob, bill or services’ names; and definitely root. If your name is bob, please don’t feel happy when this username bob is available on a social networking website. You would be a highly possible target.

Using Public Key

Using public key has two benefits: a) you don’t need to type your password, but passphrase may(must, read next) need, b) it has a guarantee of high security strength.

b doesn’t mean you can use lazy password or you won’t be hacked. That only says that it’s *almost* impossible if someone trying to hack your account by guessing or calculating correct keys. But if someone can hack into your account on your computer, then they can get your keys. Maybe they don’t need to, just can get by wrong permissions on directories and files. This is more possible to be ignored by Windows users. Even you protect your files flawlessly, there always is a target for bad people, root. root can do anything. Therefore, you must set a passphrase for your keys. If you haven’t, please run

ssh-keygen -p

to set one. This can ensure your key isn’t in clear text but encrypted.

Generating a Key

Simply follow ssh-keygen. After generating, if you have ssh-copy-id, you can run (Tip from Charles Harris, Thanks!)

ssh-copy-id .ssh/id_rsa.pub username@remote

If you don’t have it, do the following:

Transfer ~/.ssh/id_rsa.pub to remote server (scp would be a good way to transfer), run on remote server

cat id_rsa.pub >> ~/.ssh/authorized_keys
rm id_rsa.pub

On both remote server and local, make sure

chmod 700 ~/.ssh
chmod 600 ~/.ssh/*

Enhancing /etc/ssh/sshd_config

SSH Proxy

One day ago, I read a post about using SSH for a proxy usage. Some websites in US don’t allow connections outside US. If you have shell access on US server, then the restriction can be broken through.

It is incredible simple to set up a proxy. Only one step: ssh -D port# user@host.

How to connect this proxy? In Fireforx, open Preferences / Advanced / Network / Connection / Settings. Use SOCKSv5 at localhost with port number you set above.

The additional benefit from this: since you use ssh, therefore the transmission(localhost to host) is encrypted.

PS. One of best uses is Pandora.

ssh takes exactly 1 minute 20 seconds or 80 seconds

When I tried to use ssh to log in on another computer using ssh user@192.168.0.1.

I have to wait exactly 1 minute 20 seconds, 80 seconds, for being prompted input of password. I have accepted this long delay for months(quite patient?). I don’t have same problem when I log in to bluehost server. Also no problem from OS X.

Now, I finally know the cause. I didn’t add the remote host into /etc/hosts. In other words, client-side can’t resolve 192.168.0.1. Normally, I have such name servers in /etc/resolve.conf:

; generated by /sbin/dhclient-script
nameserver 168.95.192.1
nameserver 168.95.1.1

Which are from dhcp server, and these two name servers belong to my ISP. When I commented them out, the delay didn’t exist anymore.

When I run ssh -v user@192.168.0.1 results