The `PubkeyAcceptedKeyTypes' sshd_config(5) option allows a system administrator to restrict the kinds of keys that can be used by users to log in to the system; and they can disable e.g. `ecdsa-sha2-nistp256' and `ecdsa-sha2-nistp384' while still allowing `ecdsa-sha2-nistp521', but they cannot restrict the RSA key size if they allow `ssh-rsa'. This bug is a feature request for a `PubkeyAcceptedRSAMinKeySize' option (or similar naming). If a user attempts to login with a e.g. 2048-bit RSA key, and this is set to something higher than 2048, the user should be denied access.
+1
need this option also to allow again previous RSA minimum size default 768. I know 768 is too small for security, _but_ old puttygen version creates in ~50% RSA keys with 1023 bits, when using with the default of requested size 1024. SSH_RSA_MINIMUM_MODULUS_SIZE was increased to 1024, so public key login no longer works with old public keys. so enforced to stay on old openssh server version (7.4). Cannot distribute new keys for this accounts.
(In reply to stefan.ss from comment #2) > need this option also to allow again previous RSA minimum size > default 768. > > I know 768 is too small for security, > _but_ old puttygen version creates in ~50% RSA keys with 1023 bits, > when using with the default of requested size 1024. > > SSH_RSA_MINIMUM_MODULUS_SIZE was increased to 1024, so public key > login no longer works with old public keys. > > so enforced to stay on old openssh server version (7.4). > Cannot distribute new keys for this accounts. 100% agreed and voting for this issue resolution. It is also questionable and maybe for a separate bug (?) why the hard-coded limit was not set to 1023 when it is known that PuTTYgen randomly generates(-ed) shorter keys when 1024 is (was) requested. See this quote regarding 1023 key size from its old, but most probably still valid [documentation](https://the.earth.li/~sgtatham/putty/0.61/htmldoc/Chapter8.html): > This is perfectly normal, and you do not need to worry. The lengths should only ever differ by one, and there is no perceptible drop in security as a result.