When using public key authentication and the user chooses the wrong type of key, the client will display "You are not authorized to connect to this server". This error message is not very helpful to the user. Examples of wrong types of keys: * putty .ppk key * Choosing the public key instead of the private one Also see bug 5317 and bug 7207.
Tested solution on Fedora 33 server and client with an RSA key pair. ✓ Normal login (Password) ✓ Login with public key authentication ✓ We still get "You are not authorized to connect to this server" when trying to connect to a server without agent in authorized_keys. ✓ Providing a .ppk file will now say "The specified key has an incorrect format. Please check that the provided path is correct." ✓ Providing a file with too open permissions will also give an error message now. "The specified key has too open permissions. Please check that the provided path is correct.". This most likely happens when you provide key.pub file or other bad files. We should check if we should handle more error messages from OpenSSH.
Tested my changes on Fedora 33 server/client: ✓ We now get an message specific for too short keys. I had to bypass checks in ssh-keygen to make the short key for testing purposes, so I'll attach them here so that tester can use them.
Created attachment 996 [details] Private rsa key that is too short
Created attachment 997 [details] Public rsa key that is too short
Tested with server build 2265 and client build 2185, both on Ubuntu 20.04. Everything works as expected, and the error messages look good. ✓ Normal login (Password) ✓ Login with public key authentication ✓ We still get "You are not authorized to connect to this server" when trying to connect to a server without agent in authorized_keys. ✓ Providing a .ppk file will now say "The specified key has an incorrect format. Please check that the provided path is correct." ✓ Providing a file with too open permissions will also give an error message now. "The specified key has too open permissions. Please check that the provided path is correct.". ✓ We now get a message specific for too short keys.
This does not seem to work fully, and I don't see any discussion about it here. I'm still getting "You're not authorized..." if I give it bad files, e.g. the public file instead of the private one. In the log I can find: > 2022-01-10T11:56:09: ssh[E]: Load key "/home/cendio/.ssh/id_rsa.pub": error in libcrypto
Even tried a .ppk file, which seems to have worked at some point, but I'm getting the same issue: 2022-01-10T12:03:12: ssh[E]: Load key "/home/cendio/.ssh/foo.ppk": error in libcrypto
I can not reproduce "error in libcrypto" using a .pub key, and I don't always get the "You are not authorized..." message: * If I use a .pub key with permissions 0644 I get the proper "Bad permissions" error * If I use a .pub key with permissions 0600 I get "You are not authorized", but not any libcrypto error in tlclient.log With regards to .ppk files I can reproduce the behavior described in comment 14. I also see the libcrypto error in tlclient.log. Used nightly client build 2311 on RHEL 8. The next step is to find out what has broken since build 2185.
Created attachment 1018 [details] Screenshot comparing the error messages for the same .ppk file between a pre-ssl-upgrade client and a nightly client After downgrading my build system to how it looked before the OpenSSL upgrade, I built a client similar to the one that was tested in comment 12 (build 2185). Using this client I get the correct error messages. I'll continue investigating what the cause of this regression is.
Using a nightly client but with an old version of OpenSSL, cmake and libarchive in the build system, things still work. Everything points to the OpenSSL upgrade being the culprit.
Using gdb I was able to follow the path SSH takes where we get the "You are not authorized.." error. It seems we get a error with 'lib' ERR_LIB_OSSL_DECODER and 'reason' ERR_R_UNSUPPORTED from OpenSSL. Not sure what that means at the moment, there are is one mention OpenSSL 3.0.0 changelog that might be related: > Introduced a new method type and API, OSSL_DECODER, to > represent generic decoders. These do the same sort of job > that PEM readers and i2d functions do, but with support > for methods supplied by providers, and the possibility for > providers to support other formats as well.
Might be related: https://github.com/openssl/openssl/issues/14566
We have decided to not investigate this OpenSSL problem further right now. Hopefully it gets fixed with a future update of either OpenSSH or OpenSSL. I have added a FIXME in the code for this. I have also added a user-visible fallback error message. Until the above-mentioned issue is resolved, this error message will be shown for example when the user: * tries to use the public part of the key instead of the private one * tries to use a .ppk key * tries to use a file of a completely wrong type Note that if the user tries to use a public key that is not present in authorized_keys, the user will still get "You are not authorized..". Tested on Fedora 35.
Retested on Ubuntu 20.04: * Too short private key * Too open permissions * Public key (instead of the proper private) * Path that doesn't exist * Putty key (.ppk) * File with junk contents * File that cannot be read * Unauthorized key And of course: * Valid, authorized key Everything gives the correct messages.
*** Bug 4115 has been marked as a duplicate of this bug. ***
