Ssh – debian slow login after username entry

debianssh

I have searched for an answer, and found resources about changing the delay after an incorrect password entry for an SSH login, but not to my specific problem.

My problem is that the delay is after I enter my username, not password, and the delay is about 20 seconds. I don't mind a delay on incorrect password, but if I enter my username, I want to enter the password immediately after.

If it helps anyone, the same delay happens on FTP connect. However, once I'm connected (either SSH or FTP) then all interaction is lightning-fast. It's only the login that is slow.

I looked in /etc/ssh/sshd_config and do see this entry:

UsePam yes

But I don't know anything about PAM or where it's config is located.

[edit: here are the log files (last ones) from /var/log/auth.log]

Mar 17 14:27:29 rel2015 sshd[26206]: Failed password for root from 218.65.30.107 port 57695 ssh2
Mar 17 14:27:30 rel2015 sshd[26206]: Received disconnect from 218.65.30.107: 11:  [preauth]
Mar 17 14:27:30 rel2015 sshd[26206]: PAM 2 more authentication failures; logname= uid=0 euid=0 tty=ssh ruser= rhost=218.65.30.107  user=root
Mar 17 14:27:42 rel2015 sshd[26208]: Received disconnect from 218.65.30.107: 11:  [preauth]
Mar 17 14:28:08 rel2015 proftpd: pam_unix(proftpd:session): session closed for user rbase
Mar 17 14:28:23 rel2015 proftpd: pam_unix(proftpd:session): session opened for user rbase by (uid=0)
Mar 17 14:29:25 rel2015 proftpd: pam_unix(proftpd:session): session closed for user cpm303
Mar 17 14:29:41 rel2015 proftpd: pam_unix(proftpd:session): session opened for user cpm303 by (uid=0)
Mar 17 14:35:01 rel2015 CRON[26318]: pam_unix(cron:session): session opened for user root by (uid=0)
Mar 17 14:35:01 rel2015 CRON[26318]: pam_unix(cron:session): session closed for user root

obv. using PAM, but again I don't know where PAM is located..

Best Answer

In your logfile there are entries saying Failed password for root. These are not followed by a successful login as you would have expected in case they were due to a legitimate administrator mistyping the password.

This could very well be a password brute force attempt. And those send a lot more than just two requests. So it seems likely to me that if you look at more context in the logfile, there will be a lot of failed passwords from 218.65.30.107.

I have seen such password guessing attempts myself. And sometimes they effectively DoS sshd such that it is difficult for legitimate users to log in. Any connection already logged in was unaffected and experienced responses just as quickly as usual.

What I have done in such cases is:

  • Keep trying to log in until I succeed.
  • Insert iptables rule to block off the offending IP while I am working iptables -I -s 218.65.30.107 -p tcp -j REJECT --reject-with tcp-reset
  • Edit sshd_config to disable password authentication PasswordAuthentication no.
  • Reload sshd.
  • Open another ssh connection to the server to verify that I can still log in.

After having performed above steps I have never seen password brute force attempts DoS the service again.

If PasswordAuthentication no isn't an option for you because you absolutely need some users to log in using passwords, there is a couple of other options. Use Match to limit password authentication to the specific username/IP combinations which need it. Or use fail2ban to block IP addresses after a few failed password attempts.

Related Topic