Weblog entry #290 for simonw
See all weblog entries made by simonw.
#290
SSH grief
Posted by simonw on Tue 25 Nov 2008 at 10:56
Connections to an Internet facing server failing with:
ssh_exchange_identification: Connection closed by remote host
Problem is intermittent.
Problem will resolve itself in a few minutes.
Problem affects only SSH (as far as I can establish).
Restarting sshd, and thus switching to debug mode fixes it temporarily.
Best suggestion I've found so far is that it might be the max unauthenticated connection check.
http://www.derkeiler.com/Mailing-Lists/securityfocus/Secure_Shell/2008-05/msg00015.html
This looks plausible as the logs show ssh bots often making 10 (refused) connections in 1 second.
I've approached this by using hosts.allow to restrict access to the server in question (of itself not enough - do sessions count towards this limit whilst we check their reverse DNS?).
Reducing the "LoginGraceTime" setting in sshd.config
Enabling the commented out "MaxStartUps" (which I understand should allow genuine attempts to succeed more often, which might help).
Null-routing a few of the worse sources of SSH cracking attempts (fail2ban is running anyway).
There was also some attempted abuse over IPv6, resolved in the time honored fashion of disabling IPv6 completely.
Anyone else seeing any similar change in behavior with SSH server in the last few days?
ssh_exchange_identification: Connection closed by remote host
Problem is intermittent.
Problem will resolve itself in a few minutes.
Problem affects only SSH (as far as I can establish).
Restarting sshd, and thus switching to debug mode fixes it temporarily.
Best suggestion I've found so far is that it might be the max unauthenticated connection check.
http://www.derkeiler.com/Mailing-Lists/securityfocus/Secure_Shell/2008-05/msg00015.html
This looks plausible as the logs show ssh bots often making 10 (refused) connections in 1 second.
I've approached this by using hosts.allow to restrict access to the server in question (of itself not enough - do sessions count towards this limit whilst we check their reverse DNS?).
Reducing the "LoginGraceTime" setting in sshd.config
Enabling the commented out "MaxStartUps" (which I understand should allow genuine attempts to succeed more often, which might help).
Null-routing a few of the worse sources of SSH cracking attempts (fail2ban is running anyway).
There was also some attempted abuse over IPv6, resolved in the time honored fashion of disabling IPv6 completely.
Anyone else seeing any similar change in behavior with SSH server in the last few days?
Comments on this Entry
Posted by Anonymous (86.53.xx.xx) on Tue 25 Nov 2008 at 14:15
Not seen it myself yet. Would suggest iptables rate-limiting rather than hosts.deny too.
[ Parent | Reply to this comment ]
Nothing specific but I use to have a system that was slow enough to "time out" when it was under a brute force attack.
Obviously you have checked out the SSH suggestions on this site, there are a few tricks to limit the rate of requests and automatically deny brute force attacks.
--
"It's Not Magic, It's Work"
Adam
[ Parent | Reply to this comment ]
I had the same problems too for me the combination of MaxStartups (sshd_config), AllowedGroups (sshd_config) and ControlMaster (ssh_config) was the solution: http://ctrl.alt.delete.co.at/2008/11/ssh-grief.html
--
http://ctrl.alt.delete.co.at
You are not free to read this message,
by doing so, you have violated my licence
and are required to urinate publicly. Thank you.
--
http://ctrl.alt.delete.co.at
You are not free to read this message,
by doing so, you have violated my licence
and are required to urinate publicly. Thank you.
[ Parent | Reply to this comment ]