I created a group ssh, then add anyone who should be able to use ssh to the ssh group.

Note, that even if the user isn't in ssh, sshd still goes through the motions and asks for a password, it just can not succeed.

I don't figure that there's anything to keep the barbarians from pounding at the gate. Given that they use port scanners to check for open ports, changing the default port propably won't help. Set up sshd for the most restrictive policy that will allow you to do what you need.

For example, I don't need the ability to ssh in from the internet, only from local net boxes. So I set a listen address so that sshd doesn't have the public port open at all.

Doug.

> Drop password logins of any type in ssh completely, use only crypto keys.
> Also, explictly tell sshd the users which should be able to login, it will
> deny all others, no matter what.

If that's impractical (as it often is, on multiuser systems), at least deny root logins.

David Brodbeck @u.washington.edu

> . . .  Given that they use port scanners to check for
> open ports, changing the default port propably won't help. . .

It's all automated, and nobody yet is willing to throw a portscanning bot at 65000 ports at a time, so putting ssh on a high port will keep your logs clean. I look after three net-facing ssh installations, and none has seen a single attempt since moving them up high. I've only actually changed the port on one, the others have the router set to forward down to 22.

But yes, forget the password thing, use keys, and you won't care how many guesses they make.

Joe @jretrading.com

> What's your recommendation to such situation?

keyauthentication

and iptables

iptables -t filter -A INPUT -i <INTERNET IF> -p tcp --dport 22  -j SSH

# If there have not been 4 NEW connection attempts from this source IP address
# in the last 60 secons let's return to the INPUT chain.
iptables -t filter -A SSH -m recent --set --name SSH
iptables -t filter -A SSH -m recent --name SSH ! --rcheck --seconds 60 --hitcount 4 -j RETURN
# Well, the NEW connection has been seen so let's update the SSH recent list.
iptables -t filter -A SSH -m recent --name SSH --update
# I like to log on a line by it's self so I don't have to remember to do it on
# my last line prior to the end of my script.
iptables -t filter -A SSH -j ULOG --ulog-nlgroup 1 --ulog-prefix 'sydrt01 S ' --ulog-cprange 0 --ulog-qthreshold 1
iptables -t filter -A SSH -j DROP

I allow 4 attempts from an IP address in 60 seconds otherwhise the ip gets logged and dropped. But I also use openvpn for when I need lots of connections

Alex Samad @samad.com.au

>> fail2ban seems to be the preferred solution. However, I just
>> manually add the offending IP addresses to /etc/hosts.deny to
>> prevent any future attacks from the same IPs.
>
> This is a solution.  But, what about people who have dynamic IP
> addresses?  Everyone from AOL gets blocked from accessing anything
> on your server(s)?

Most likely he doesn't have any users on AOL, so it works for him. Most of these attacks seem to come from China, anyway. I've known people to just block all the Asian netblocks and be done with it. I hear it cuts out a lot of spam, too. Kind of a scorched-earth tactic, though!

I can't get away with that sort of thing because I *do* have users on various ISPs that use dynamic IPs. So I use fail2ban, which allows IPs to expire off the blocklist after a while. On my home system, which runs FreeBSD, I'm using sshguard. Sshguard takes a particularly clever approach, I think — instead of polling the logfiles, like fail2ban does, it gets added to syslog.conf as a log destination, so it gets the messages directly.

Given the lists of names some of these crackers are using, I wonder what their success rate is. I can understand trying the root account, but I've seen some pretty ludicrous sets of usernames being attempted. Some seem to be just throwing a dictionary at it, and one that I ran into the other day appeared to be using a list of Finnish first names. (Not many Markos or Toivos on my machine, I'm afraid.)

David Brodbeck @u.washington.edu

and then you're good.

and frankly fail2ban is extraneous with pubkey authentication, but I use it anyway as then sshd doesn't have to even listen to them once they've failed.

Andrew Sackville-West @farwestbilliards.com

Along with all the other excellent suggestions what I do on my machines is firewall off the port to the public interfaces via shorewall. Then I found a portknock daemon and got it to open up the ssh port on a specific knock sequence. After all that I reopened the port to any IP address I know I or authorized people will be coming from.

So I am not deterred by the knock daemon but if I ever need to access the machine from an IP other than those that are normally used I know the knock sequence, know my username, know my password and know the port will be close in a few seconds. :)

So if you absolutely need remote ip access via password from an unknown source that might be an option you'll want to look into.

Steve Lamb @dmiyu.org

> Note that shorewall itself (now?) supports portknocking natively - see
> shorewall-doc/html/PortKnocking.html

Hmm, I'll have to look into that. Thanks!

Now that I have access to my boxes with ssh and for completeness' sake for those who might not be using Shorewall to manage their firewall the package I used was knockd.

Steve Lamb @dmiyu.org