Bug 7313 - Bad error message for wrong type of SSH key
Summary: Bad error message for wrong type of SSH key
Status: CLOSED FIXED
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: Client (show other bugs)
Version: trunk
Hardware: PC All
: P2 Normal
Target Milestone: 4.14.0
Assignee: Niko Lehto
URL:
Keywords: linma_tester, ossman_tester, relnotes
: 4115 (view as bug list)
Depends on:
Blocks:
 
Reported: 2019-03-05 16:24 CET by Samuel Mannehed
Modified: 2023-12-07 16:40 CET (History)
3 users (show)

See Also:
Acceptance Criteria:
The user will get an clear error message in the case of the given SSH key file being of a wrong type. Examples of bad key files we should be able to show better messages for: - Public key given instead of private key file - putty .ppk key - Too short key - Wrong/unknown type of key


Attachments
Private rsa key that is too short (1016 bytes, application/octet-stream)
2021-09-06 15:35 CEST, Niko Lehto
Details
Public rsa key that is too short (223 bytes, application/vnd.ms-publisher)
2021-09-06 15:35 CEST, Niko Lehto
Details
Screenshot comparing the error messages for the same .ppk file between a pre-ssl-upgrade client and a nightly client (155.58 KB, image/png)
2022-01-12 16:03 CET, Samuel Mannehed
Details

Description Samuel Mannehed cendio 2019-03-05 16:24:58 CET
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.
Comment 5 Niko Lehto cendio 2021-09-02 15:52:16 CEST
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.
Comment 9 Niko Lehto cendio 2021-09-06 15:34:14 CEST
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.
Comment 10 Niko Lehto cendio 2021-09-06 15:35:27 CEST
Created attachment 996 [details]
Private rsa key that is too short
Comment 11 Niko Lehto cendio 2021-09-06 15:35:57 CEST
Created attachment 997 [details]
Public rsa key that is too short
Comment 12 Linn cendio 2021-09-09 10:36:12 CEST
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.
Comment 13 Pierre Ossman cendio 2022-01-10 13:01:23 CET
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
Comment 14 Pierre Ossman cendio 2022-01-10 13:04:14 CET
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
Comment 15 Samuel Mannehed cendio 2022-01-11 17:27:20 CET
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.
Comment 16 Samuel Mannehed cendio 2022-01-12 16:03:46 CET
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.
Comment 17 Samuel Mannehed cendio 2022-01-12 16:48:41 CET
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.
Comment 18 Samuel Mannehed cendio 2022-01-13 16:57:54 CET
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.
Comment 19 Samuel Mannehed cendio 2022-01-13 17:17:27 CET
Might be related:

https://github.com/openssl/openssl/issues/14566
Comment 22 Samuel Mannehed cendio 2022-01-14 17:20:37 CET
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.
Comment 23 Pierre Ossman cendio 2022-01-20 09:34:29 CET
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.
Comment 25 Pierre Ossman cendio 2022-09-28 15:24:31 CEST
*** Bug 4115 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.