Hey guys, just recently started experimenting with ssh on my personal desktop, read the excellent sticky thread here, and based on that advice, I've locked down sshd_config to deny access to a bunch of accounts that I see as attack vectors (apache, root, users not in the users group, etc). Very helpful stuff!

I've got a couple questions though...
1) Where are the ssh connection logs, the ones that include user/password combinations kept? I've poked around in /var/logs and looked at the tails of secure and syslog and grepped for ssh, but don't see anything there, and there are no other files that look really promising.

2) syslog contains lots of messages like "error: Could not get shadow information for NOUSER." Google got me some results that indicate these are failed logins due to an invalid user. Where could I go to find out more information about these, like a source IP or domain?

This is Slack 12 if it makes any difference.

Thanks!

The file /var/log/messages should give you information about people trying to connect to your server. If your computer is publicly available (no firewall blocking port 22), you will most likely see lot's of failed brute force attempts to get in.

I believe this message could from an attempted ssh brute force attempt.
You have a couple of options in order to prevent these attacks. You could run ssh on a different port besides 22, but if you have other people besides yourself logging in, that might be kind of a hassle.

iptables could be used to limit the amount of connections per a given amount of time. So let's say you could limit 10 maximum connections per minute.

My favorite was to write a script that drops the packets of an offending ip address after 10 failed attempts. I believe some of the attacks come from either spoofed ip's or they are coming from under a larger network. I tried tracing the ip of one attack and I ended up at the website of a Chinese ISP. So you can block the ip's, but it may not truly stop the attacker. But it will stop the current attack. If you are interested in the script, let me know and I'll post it.

Another thing that you may want to consider if you haven't done so already is to prevent root login through ssh. You would then need to have a user account on the system before you can log in as root. You can make this change in the (I belive) sshd.conf file.

--Shaun

http://www.aczoom.com/cms/blockhosts/download

This script does a nice job of monitoring and blocking SSH attacks.

I had thought about moving the service off the default port, and I may wind up doing that. This box is firewalled and natted at the router with just the ssh port forwarded (currently), and I'm likely the only one who will use it from outside the LAN, so changing the external port might be the best idea.

That was the first thing I did. Thanks.

The log might be called auth.log. Otherwise you should be able to locate it by running:
grep sshd /var/log/*
or:
find /var/log -exec grep -H 'sshd' '{}' \;
(if it's located in a sub-directory)

Anyway, I usually protect myself against the "random" ssh attacks by setting up key-based login and turning off password authentication. Then the attacker won't even get a login prompt and it's pretty convenient if you're the only one accessing the computer

I did exactly that and since then I recorded only
one attempt of an outside computer to connect to this
port. I am pretty sure that this was simply a port
scan.

Doing this port change is only security by obscurity.
It is a good idea to do so. But it is a bad idea to
rely on it and to think that no other security
measures need to be taken (I am not implying that
you think that - this is only a general statement).

I found them, they are in /var/log/messages. Got several hundred a few seconds apart from somewhere in China trying usernames in alphabetical order.

Bah. I tried moving the service to port 44 (which was easy to remember, and also seemed to be not reserved by any other well-known services), but my stupid Linksys router refuses to forward that port for some reason. Buggy piece of crap.

I'm not crazy about a key-based login in this instance because I'm a contractor who changes jobs a lot, sometimes without much notice, and I'm paranoid about leaving a key behind somewhere. I know, I can revoke them, but still.

To mitigate that risk you could:

• Protect your key with a passphrase.
• Generate a new keypair each time you change jobs (it's not that time intensive). Remember to delete the old public key from ~/.ssh/authorized_keys.

Carry the new private key on a usb pen drive to your new job...