@Ashen:

What I want is, anyone entering the username 'root' to sshd should simply be dropped, without being given the chance to enter a password.

I don't believe thats possible under SSH - you can have SSH not accepting the password and not "logging in" (even if the password is correct) - but not that.

> because all

the annoying dictionary crack scripts keep trying a ton of passwords

on my sshd, and it fills my logs.

Make SSH listen to a different port, so you won't get as many dictionary-attacks.

If you use only RSA keys, and disallow password authentication, sshd should simply drop the connection if a key isn't presented.

@rjp:

If you use only RSA keys, and disallow password authentication, sshd should simply drop the connection if a key isn't presented.

@ashen:

I've tried setting PasswordAuthentication to no in sshd_config,

but that prevents all my users logging in that way too, which

is not what I want.

@saman007uk:

I don't believe thats possible under SSH - you can have SSH not accepting the password and not "logging in" (even if the password is correct) - but not that.
:-( - oh well, at least I know now why I couldn't find a way to get it to do that.
@saman007uk:

Make SSH listen to a different port, so you won't get as many dictionary-attacks.
Good idea…… I might try that if the dictionary attacks keep annoying me.

Thanks :)

This isn't quite what you wanted to do, but when I also noticed all the bad ssh login attempts in my logs I modified my iptables setup to drop excessive ssh connection requests. The relevant section from my firewall script is:

ssh server

iptables -N ssh-drop

iptables -A ssh-drop $LogLimit -j LOG $LogLevel –log-prefix "FIREWALL:SSH-DROPPED "

iptables -A ssh-drop -j DROP

iptables -A INPUT -p TCP --dport 22 --syn -m recent --name ssh --update --seconds 60 --hitcount 5 -j ssh-drop

iptables -A INPUT -p TCP --dport 22 --syn -m recent --name ssh --set

log incoming ssh connection requests

iptables -A INPUT -p TCP --dport 22 --syn $LogLimit -j LOG $LogLevel --log-prefix "FIREWALL:SSH-CONNECT "

iptables -A INPUT -p TCP --dport 22 --syn -j ACCEPT

enable incoming ssh after connected

iptables -A INPUT -p TCP --dport 22 -m state --state ESTABLISHED -j ACCEPT

While I wouldn't call myself an iptables or firewall expert by any means, I've tested it and it seems to do what I expect it should, which is drop all ssh connection requests from any IP that does more than five such requests within 60 seconds until that IP does no such requests for at least 60 seconds. The logging stuff is, of course, optional, and you probably don't want it if your main complaint is the requests filling up your logs. My mail goal was to try to ensure that, however unlikely even without this, no kiddie's script got lucky and hit on a valid password.

HTH

Thank you :)

I have a firewall right now, which has rules I've built up for a while (default DROP on inbound ports, ALLOW a few server ports, ALLOW a few portsentry ports, else return to default DROP rule)…… but did not think of using iptables to combat this problem.

I will try this method, and see if it works :)

Here's my updated ruleset, that's slightly improved (aka the limited logging works on my system and it's commented):

# A (uncomment this section INSTEAD of section B below to enable logging of connections to sshd dropped due to rate limit)

$IPT -N ssh-drop

$IPT -A ssh-drop -m limit –limit 2/minute -j LOG --log-prefix "FIREWALL:SSH-DROPPED "

$IPT -A ssh-drop -j REJECT

uncomment the first line below if you have a multihomed host, the second one if you don't, or you want to protect all ips.

$IPT -A tcpinbound -p TCP -d yourip_here! --dport 22 --syn -m recent --name ssh --update --seconds 10 --hitcount 3 -j ssh-drop

$IPT -A tcp_inbound -p TCP --dport 22 --syn -m recent --name ssh --update --seconds 60 --hitcount 5 -j ssh-drop

B (uncomment this section INSTEAD OF section A above to just drop them without logging anything)

$IPT -A tcp_inbound -p TCP --dport 22 --syn -m recent --name ssh --update --seconds 60 --hitcount 5 -j DROP

Leave this one line uncommented no matter which you use above

$IPT -A tcp_inbound -p TCP --dport 22 --syn -m recent --name ssh --set

Good thread on the Gentoo boards:

~~[http://forums.gentoo.org/viewtopic-t-210585-postdays-0-postorder-asc-highlight-ssh+logins-start-0.html" target="_blank">](http://forums.gentoo.org/viewtopic-t-21 … art-0.html">http://forums.gentoo.org/viewtopic-t-210585-postdays-0-postorder-asc-highlight-ssh+logins-start-0.html](

It's focused on the same topic.

-austin

http://blog.andrew.net.au/2005/02/17

As far as blocking just root password logins, have you looked at the SSH PAM settings?

It should be possible to block only root there, it's worth a look. Should be in /etc/pam.d/ssh.

I know it's possible there. You can set up PAM to for example use LDAP for SSH authentication, and if you don't list root in the LDAP dir, then SSH using root would be impossible. LDAP is just an example I know, something simpler should work for you. Check out the /etc/pam.d/login, mine says something about blocking root in the comments.

@Ashen:

Hi, I was wondering if anyone could suggest ways for me to remove root's ability to attempt to login via sshd on a linode running debian stable.
You could try removing vc/1 to vc/11 in /etc/securetty

On my home box I had to add ttyp0 to this file to log in over the network as root using ssh. I'm assuming that vc/1 - vc/11 are the same thing in the virtual world of Linode. (Caker / Anyone ?)

> From my home /etc/securetty

/etc/securetty: list of terminals on which root is allowed to login.

See securetty(5) and login(1).

#

Include ttyp0, ttyp1, etc to allow telnet access. NOT RECOMMENDED

Edit:

I ran up a quick Debian test system and gave this a go. I removed everything from /etc/securetty and I could still login as root. So I guess it doesn't work the same under UML.

Just modify the sshd config file to disable root logins. There is a setting precisely for this purpose:

PermitRootLogin

For more info, type:

man sshd_config

@kangaby:

You could try removing vc/1 to vc/11 in /etc/securetty

On my home box I had to add ttyp0 to this file to log in over the network as root using ssh. I'm assuming that vc/1 - vc/11 are the same thing in the virtual world of Linode. (Caker / Anyone ?)

Edit:

I ran up a quick Debian test system and gave this a go. I removed everything from /etc/securetty and I could still login as root. So I guess it doesn't work the same under UML.

/etc/securetty lists which terminals root can login to. Terminals == consoles, not sshd. So, removing tty0 from securetty will prevent you from logging in as root through Lish.

The correct course of action is to disable PermitRootLogin in your sshd_config file.

-Chris