I'am using Putty on windows with key-based authentication to access some of mine servers.

It works totally fine with ~3700-bit key, but with ~17000-bit key it thinks for like 20 seconds on client-side and then just says "Access denied" and asks for a password.

Is there any key length limit or timeout in OpenSSH for key-based authentication?

I understand that using such large keys have not much practical sence, especially when looking at these 20 seconds of calculation, just trying to solve any problems I face :-)...

  • I have seen similar problems happen on some OpenSSH versions, which I worked around by using a key length which was a power of two.
    – kasperd
    Mar 24 '15 at 19:02

At one point I looked into the source of OpenSSL for Diffie-Hellman keys, and found there was an "arbitrary" 10K limit on the size of DH keys. I changed the source for a test, and found that worked. I wrote a bug to the authors, and they replied back that it was design intent to prevent DoS by using massive keys.

Wouldn't surprise me to see something similar in OpenSSH.


There is no maximum key size or timeout defined in the protocol (or at least none that you'd be hitting), but an implementation might not support such long keys. A 20-second processing time with the private key doesn't sound high for a 17kbit RSA key. Then the server might not want to spend too much computing power on an unauthenticated user: refusing very large keys is a protection against DoS attacks.

Currently 2048 bits is considered reasonable for an RSA key; 4096 bits is higher than necessary but usually supported; beyond this you shouldn't be surprised if some programs to reject the key.

  • This protection looks reasonable. Is it tunable or hardcoded in the sourcecode? Jul 14 '10 at 11:40
  • There's no option for this in the manual, so any limit must be in the source code. That said, I don't know if there actually is a protection, I just meant that it would be reasonable to have one. I suspect that AndreasM's answer is closer to the mark. Jul 14 '10 at 16:17

Were you able to generate that size of key on the intended target system? You may be running into a limit to what is supported. Rather current Centos system of mine supports a 16k maximum which seems sufficient for massive keys. You should see the maximum if you try to go above it with ssh-keygen as shown below.

[nathan@omni ~]# ssh-keygen -t rsa -b 32768
key bits exceeds maximum 16384
  • Same on Debian 8.2. My netbook might spend quite a while generating this 16384-bit key... the things I do for laughs. Sep 23 '15 at 20:10
  • Same on "Git Bash" for Windows 7, which is based on MinGW. Jul 22 '16 at 10:16
  • Also same on OpenSuse Leap 42.1. Jul 23 '16 at 7:47

The openssh Server has a LoginGraceTime setting. From the man page:

The server disconnects after this time if the user has not suc-
cessfully logged in.  If the value is 0, there is no time limit.
The default is 120 seconds.

This could be a limit that you are hitting if it is set to 20 seconds.

Wild guess: It could also be that putty itself has this limit, thinking that if the client side processing of the public key authentication takes that long, something is wrong.

  • I've thought the same, and set LoginGraceTime 1200 Well, error message is in the console, so I doubt it's something in Putty... Jul 14 '10 at 12:41
  • 1
    Check the server logs. With a key size like this I get: RSA_public_decrypt failed: error:04067069:lib(4):func(103):reason(105). (because of the key size apparently.) I'll try a 2^n key.
    – AndreasM
    Jul 14 '10 at 14:12
  • 1
    16384 bits seems to work. For results with 32kbits see hermann-uwe.de/blog/… :)
    – AndreasM
    Jul 14 '10 at 14:22
  • 1
    You deadly right: Found thid: sshd[1014]: error: RSA_public_decrypt failed: error:04067069:lib(4):func(103):reason(105) So this must be a bug in sshd/OpenSSL :-) Jul 15 '10 at 12:55

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.