Tuesday, January 23, 2007


My home firewall runs an ssh server. Every few days, I go through my logs and find that someone has been attempting to guess account names and passwords on that server. For a while, I just allowed it to continue because I found it interesting to see what usernames were being guessed. After a few months of getting guess attempts every couple of seconds with almost no interruptions from dozens of ip addresses, I decided I didn't want to take the risk of somebody actually getting in and set up iptables rules to blackhole any ip address that sent more than ten SYN packets to ssh in less than two minutes. A friend pointed me to denyhosts, a tool to watch your logs for failed ssh attempts and put the offending host into your /etc/hosts.deny for a certain period of time. This is effectively the same as the iptables rules. Both of these methods are very effective but not as interesting as seeing all the usernames tried. So I downloaded the source for openssh-4.4p1 and made a few modifications. My new sshd:
  • Logs all connections
  • Logs usernames and passwords
  • Never opens a shell no matter what

If you'd like to set this up yourself, you can download the complete source, or if you already have the source for openssh-4.4p1, and don't want to download the whole thing just for a few modifications you can get just the diff. Then run the following commands:

tar xzvf openssh-logger.tar.gz
cd openssh-logger
./configure --prefix /usr/honey/ \
--with-privsep-path=/usr/honey/chroot \

The purpose of putting it in a strange directory is that we don't want to hose your real ssh server. If that went well, run:

make install
touch /usr/honey/chroot/sshattacks.log
chown sshd:sshd /usr/honey/chroot/sshattacks.log

Remember: if you run a real ssh server, you'll want to change the port it listens on in your /etc/ssh/sshd_config. You can add section to your ~/.ssh/config like this:

Host <hostname>
Port <real server's port>
so your client will connect to the correct server. Now everything should be set up and you should start seeing brute force attacks in /usr/honey/chroot/sshattacks.log in no more than a couple of days.

Output will look something like this:

host: port: 45677
user: root pass: root
user: root pass: t00r
user: root pass: r00t

Happy hunting!

Monday, January 15, 2007

Nastier tricks with ssh

In my daily blog reading a week or so ago, I stumbled on Jon Hart's blog. In it, he notes the facts that root can read any file whatsoever on a *nix system and that ssh agent forwarding is accomplished using unix sockets. The corollary to this is that root (or someone with access to your account) can steal your password-protected ssh keys after you decrypt them.

Having used key-based authentication on a regular basis myself, this got me to thinking about other possibilities for an unrestricted user. As it turns out, if a user can read someone else's private key file, one can authenticate with it. Long story short, I've modified Jon's code to also search out non-password-protected keyfiles and attempt to abuse them.

Friday, January 12, 2007

On ssh and timeouts

It turns out that ssh by default doesn't like to stay connected forever. If you setup a port forward as described below and don't connect to it right away one end or the other will timeout (not sure which, but it doesn't really matter). To circumvent this issue, I've taken to setting up the forward, connecting to the remote box, then connecting through the port forward in a screen session, and detaching screen (or not, depending on my mood). Now ssh won't be able to tell that there's no interaction and will stay connected indefinitely.

Incidentally, if you love the power of the command line and haven't heard of screen, you should install it at the earliest opportunity. Thank me later.