Hi Richard!
Richard Kettlewell schrieb am Donnerstag, 25. März 2021 um 14:53:03 UTC+1:
> Bernhard Fröhlich writes:
> > Mar 25 10:04:10 coturn sshd[5486]: debug1: trying public key file
> > /home/ted/.ssh/authorized_keys
> The public key needs to be in this file, and apparently isn’t. Either
> it’s completely missing, or you have the wrong syntax, or a typo, or
> something like that. Without visibility of the file’s contents it’s
> impossible to say more.
The authorized_keys file was not changed between the two log excerpts!
Is there any way to find out why during the first try the key was not found while during the second try it was?
> > Now, can anyone explain this to me? I always thought that the key hash
> > (SHA256:Awr0ikVD79MmKnd1vxIsbvjg0c4/NivKlZ9Rh84CAZw) decides whether
> > the line in authorized_keys is found or not. Am I wrong somewhere?
> authorized_keys contains public key material, not key hashes.
Sorry, I obviously used the wrong term.
Nevertheless this hash can be calculated from the public key material contained in the authorized_keys file (at least using "base64 -d | openssl dgst -sha256 -binary | base64" produces an extremely similar string). So I naively assumed that sshd does it that way, and that this was the reason why this value is written to the debug log...
So it would be most interesting how sshd decides that a line from authorized_keys matches a key offered by the client during the handshake...
In the meantime I once more got the PuTTY configuration working by creating a new configuration (compared to just changing the target host name in an existing configuration). The auth.log on the server is exactly the same (verified by diff) as in the failed connection attempt till it comes to the "matching key found" line...
So it looks like the cause of the problem lies on the client side and the auth.log on the server is not helpful to locate this problem, at least not in this DebugLevel setting...
Sorry for having bothered you, and thanks for your answer!
Nevertheless I'd really be curious about the real cause. I indeed could not make out suspicious differences in the PuTTY configuration after dumping the registry keys and diffing them. And I could not provoke the same error by doing the same things I did when this error occured... Maybe this only works once per client workstation or client user account?
But probably this would be something for PuTTY insiders...
Kind regards
Ted
;)