Things look quiet here. But I've been doing a lot of blogging at
dan.langille.org because I prefer WordPress now.
Not all my posts there are FreeBSD related.
I am in the midst of migrating The FreeBSD Diary over to WordPress
(and you can read about that here).
Once the migration is completed, I'll move the FreeBSD posts into the
new FreeBSD Diary website.
Over IRC, I've learned about an SSH exploit. And I've also learned how to avoid the exploit. I'm not
claiming to be an expert in this area. I do claim to be relaying information which might help you. Those
amongst you that know more about this area than I will hopefully add their comments to this article.
There is a remote integer overflow vulnerability in several implementations of the SSH1 protocol that allows an attacker to
execute arbitrary code with the privileges of the SSH daemon, typically root.
My understanding is that FreeBSD 4.3 onwards is not vulnerable to the SSH1 exploit. Even if you have an older FreeBSD,
you can avoid the exploit by using SSH2 instead of SSH1. How do you do that? Read on...
Given that SSH1 is vulnerable, how can you reduce your exposure? First, you need to realise that it
is still very difficult to exploit the SSH1 bug. Second, some clients are not SSH2 capable. That
said, I think there are a few simple steps you can undertake in order to reduce your exposure.
The easiest step is to ensure that both your clients and your servers use SSH2 instead of SSH1,
if it's available. How to do that is outlined below. A more dramatic step would be to require
SSH2. But that's not for everyone.
Change your servers
You can specify the protocols used by your sshd via /etc/ssh/sshd_config.
Look for the entry which looks like this:
That specifies that both protocols 1 and 2 should be accepted. It does not determine which
protocol will be tried first. That decision resides with the client.
The following is from man sshd:
Specifies the protocol versions sshd should support. The possible
values are `1'' and `2''. Multiple versions must be comma-separated.
The default is `1''.
If you wish to use only SSH2, that is an option. But consider it carefully. The SSH1 exploit is difficult to
achieve. Some clients are not SSH2 compatible. If you can ensure that all your clients will be SSH2-compatible,
then, and only then, is SSH2 only an option for you. If so, adjust your configuration file to be this:
WARNING: Use the above with caution considering who your clients will be.
Change your clients
The change to your clients are quite similar to your sever changes. The file
to modify is ~/.ssh/config (which might not exist
on your system; you may need to create it). I added the following line:
The following is from man ssh:
Specifies the protocol versions ssh should support in order of
preference. The possible values are ''1'' and ''2''. Multiple
versions must be comma-separated. The default is ''1,2''. This
means that ssh tries version 1 and falls back to version 2 if
version 1 is not available.
Note that order is significant. In the example above, Protocol 2 will be tried and then protocol 1.
You can also specify protocol 2 using the command line:
ssh -2 example.org
ssh -o "Protocol 2,1" example.org
Create and use SSH2/DSA keys
The following two resources are compulsory reading if you are using SSH. It describes how to properly
manage OpenSSH keys. It will also show you how to use the more advanced features of OpenSSH.
You can create SSH/DSA keys using ssh-keygen -d. Definitely specify
a passphrase. Reading the above URLs will show you how to use ssh-agent to reduce the number of
times you need to enter the passphrase. It's very useful.
Your public DSA key (~/.ssh/id_dsa.pub) needs to be added to
~/.ssh/authorized_keys2 on the remote box (i.e. the sshd server).
Read the above URLs for complete information.