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 port 57695 ssh2
Mar 17 14:27:30 rel2015 sshd[26206]: Received disconnect from 11:  [preauth]
Mar 17 14:27:30 rel2015 sshd[26206]: PAM 2 more authentication failures; logname= uid=0 euid=0 tty=ssh ruser= rhost=  user=root
Mar 17 14:27:42 rel2015 sshd[26208]: Received disconnect from 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..

  • 1
    Sounds like the server is trying to look up the username through some network service and then after a timeout find it locally. Logfiles from the server side would help. – kasperd Mar 17 '15 at 14:30
  • @kasperd, this is a Linode server. It seems unlikely that there's any type of network service. I have edited and posted the log files entries from /var/log/auth.log above – Oliver Williams Mar 17 '15 at 14:38
  • 2
    I expect it's trying to resolve your IP address (not username) to a name and that's what's timing out. – wurtel Mar 18 '15 at 11:52

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

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 -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.

  • Giiven that the server isn't overloaded by these brute-force attempts ("once I'm connected then all interaction is lightning-fast. It's only the login that is slow"), how do you suggest that these SSH attempts are causing 20s delays between username and password prompting in ftp? – MadHatter May 31 '15 at 7:57
  • @MadHatter I have seen password brute force attempts which caused SSH logins to be slow without overloading the server. Whenever it happened to me, as soon as I was logged in, there was not slowness either. I don't know if that problem affects FTP, because I never use FTP. – kasperd May 31 '15 at 8:03
  • That is genuinely interesting to know. Did you ever find out why this was happening? Can you shed any light on the mechanism whereby ssh brute-forcing introduces a delay between username and password prompts, without loading the server, or is this merely a cargo-cult diagnosis? – MadHatter May 31 '15 at 8:08
  • @MadHatter In my case legitimate logins were always using keys, so I would of course never see a password prompt. I did not look anymore into the details after finding that disabling password authentication solved the problem for me. – kasperd May 31 '15 at 8:27
  • @MadHatter Attempting to reproduce the scenario on my LAN, I didn't see any slowness but just instant disconnects with the error message ssh_exchange_identification: Connection closed by remote host. On further investigation, that is definitely related to MaxStartups (and it turns out the man page is incorrect about what is the default value for that setting). The error message looks familiar enough, that I believe I may have seen that when the server was experiencing a password brute force attempt. – kasperd May 31 '15 at 8:42
-3 is trying to hack you. They are from China.

  • abuseipdb.com/whois/ – chicks May 31 '15 at 4:12
  • This answer needs a lot more detail before it could be useful. – kasperd May 31 '15 at 7:00
  • 1
    How does this relate to the question as asked? – MadHatter May 31 '15 at 7:00
  • @MadHatter It does relate to the question that was asked. But the only reason I see the connection is because I have seen the same problem myself. – kasperd May 31 '15 at 7:02
  • Really? The question asked is "why do I get a 20s delay between username and ftp password entry on ftp and ssh connections", and I strongly suspect that it's a DNS reverse-resolution issue, as you note in your comment above. I don't see that this answer relates to that at all; instead, it explains some log entries that the OP didn't ask about. If there is a connection, it's extremely subtle, and probably justifies your writing an answer to explain it! – MadHatter May 31 '15 at 7:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.