I clean up the OpenSSH mess on my Debian Etch box
(Click above for a larger image)
Cleaning up the mess left by the OpenSSH vulnerability in Debian and Debian-based distros (including Ubuntu) is easier than I thought.
For those who haven't heard about the problem, I refer you to my recent entry, or invite you to Google it.
I've had my Etch box -- which has both OpenSSH-client and OpenSSH-server installed -- turned off for the past few days. I'm using it as a Web server on the local network, and yes, I've been SSHing into the box for weeks now.
Here's what I did:
1) I run the Update Manager, and I have three packages to update:
openssh-blacklist
openssh-client
openssh-server
2) I click Install Updates to download and install the new packages.
3) After the updates are installed, a window from Debconf opens.
It says, "Configuring openssh-server" on the first line, and "Vulnerable host keys will be regenerated" on the next line. The rest of the text can be read in the picture above.
4) I click the Forward button. I assume that this regenerated my host keys.
5) I don't think this next part is mandatory, but per the suggestion in the window, I open a terminal and run ssh-vulnkey.
The output that comes back in the terminal window tells me that both of my keys -- one a 2048-bit key and the other a 1024-bit key -- are "Not blacklisted."
6) I SSH into the Debian box via PuTTY, which warns me that the SSH key on the server has changed and to proceed if I expected this (which I did). I do, and I'm back to SSHing into my Debian Etch box.
---------------------------------------
So while nobody's happy with the fact that a) Debian had this vulnerability in the first place and b) it took 2 years for somebody to notice, at least the fix was relatively painless in my case.
Final question (which I will be looking into): I have new keys on the server. Do I need to do anything on my non-Debian clients? On my Mac I'm using MacSSH, and that application generated its own keys. I imagine the same is true for PuTTY, but I'm not 100 percent sure.
1 Comments
Leave a comment
About this blog
New ways to sign in to comment: I just added the ability for prospective commenters on this blog to sign in using their AOL, Yahoo! and Wordpress.com accounts (for the past 200 posts anyway ... more than that will take an extensive, middle-of-the-night rebuild). That's in addition to the other sign-in choices, which include starting a Movable Type account on this blog, Typekey, OpenID, Live Journal and Vox. If you have trouble getting your Movable Type account verified, or any of the other sign-in options are not working properly, please e-mail me. With these added ways of signing in, there's more reason than ever for you to make a comment (or several!).
Steven Rosenberg aims to learn what he does not know. He writes about it here.
Steven Rosenberg aims to learn what he does not know. He writes about it here.
Now that you've updated, any weak keys are now blacklisted. If any of your user accounts have weak keys, the server will deny publickey authentication and prompt for keyboard-interactive authentication if your sshd is configured to allow that sort of thing.
If you feel obsessed with purging all the accounts in /home/*/.ssh/ of weak keys anyway, see this page to download a perl script that will scan all the keys your account has access to scan.
If you aren't running fail2ban or denyhosts, you should. Both will detect brute force attempts and deny connections from the attacker for a time. If you feel uncomfortable automatically banning hosts for failed logins, you can weakly configure whichever you choose to allow 20 or more failed attempts before banning. There's no reason any authenticated service should tolerate brute force attempts, in my humble opinion.
Finally, there are services, such as the DroneBL dnsbl, which have honeypot servers set up to detect brute force attempts and add them to a blacklist. You can use the "aclexec" directive in hosts.deny to query this blacklists before allowing clients to connect, to prevent connections from known brute force attackers. See http://headcandy.org/rojo/ for a suitable script to call via aclexec (view the source for the checkdnsbl script for usage instructions), and see the man page for hosts_options for more info.