Re: Postponed publickey before Accepted publickey - what's happening there then?
Hi, On Sat, Jan 27, 2024 at 09:55:16AM +, Michael Kjörling wrote: > On 27 Jan 2024 08:12 +, from a...@strugglers.net (Andy Smith): > > This only happens when I log in as root using a public key, i.e. > > > > ssh -i /path/to/pubkey r...@t.example.com > > According to https://access.redhat.com/solutions/20057 this can happen > in cases where multiple authentication methods are tried. You should > be able to confirm this by adding -v to your ssh command line and > looking for authentication methods that are not your presumably > intended publickey. The only authentication methods that are tried are publickey, it's just that it seems it tries several public keys that won't work first: debug1: Authentications that can continue: publickey,keyboard-interactive debug1: Next authentication method: publickey debug1: Offering RSA public key: /home/andy/.ssh/id_rsa debug1: Authentications that can continue: publickey,keyboard-interactive debug1: Offering ED25519 public key: andy@jameson debug1: Authentications that can continue: publickey,keyboard-interactive debug1: Offering RSA public key: /home/andy/.ssh/id_rsa debug1: Authentications that can continue: publickey,keyboard-interactive debug1: Offering RSA public key: /home/andy/.ssh/foo_rsa debug1: Server accepts key: pkalg rsa-sha2-512 blen 535 debug1: Authentication succeeded (publickey). Authenticated to t.example.com ([2001:db8:0:1f1::13]:922). (/home/andy/.ssh/foo_rsa being what was specified on the ssh command line with -i) Presumably if there WERE no working public keys then it would get around to trying another method, but publickey is offered first. If I do: $ ssh -o IdentitiesOnly=yes -i ~/.ssh/foo_rsa r...@t.example.com then only that single public key is offered and there is no message about publickey being postponed, so that must be it. Though I still wonder why it bopthers to log anything about publickey being postponed in the first place. Thanks, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting
Re: Postponed publickey before Accepted publickey - what's happening there then?
On 27 Jan 2024 08:12 +, from a...@strugglers.net (Andy Smith): > 2024-01-27T07:59:42.003881+00:00 t.example.com sshd[12319]: Postponed > publickey for root from 2001:db8:1f1:f0c2::2 port 37032 ssh2 [preauth] > 2024-01-27T07:59:42.01+00:00 t.example.com sshd[12319]: Accepted > publickey for root from 2001:db8:1f1:f0c2::2 port 37032 ssh2: RSA > SHA256:iC8C78UYVJdr+bsqV1hbtBFuft6KHi0b8i308Zn0C9o > 2024-01-27T07:59:42.020718+00:00 t.example.com sshd[12319]: > pam_unix(sshd:session): session opened for user root by (uid=0) > 2024-01-27T07:59:42.033599+00:00 t.example.com systemd-logind[1729]: New > session 18604 of user root. Thank you for using 2001:db8::/32 and example.com instead of some random made-up prefix and domain name. :-) > This only happens when I log in as root using a public key, i.e. > > ssh -i /path/to/pubkey r...@t.example.com According to https://access.redhat.com/solutions/20057 this can happen in cases where multiple authentication methods are tried. You should be able to confirm this by adding -v to your ssh command line and looking for authentication methods that are not your presumably intended publickey. According to https://forums.centos.org/viewtopic.php?t=52896 and https://stackoverflow.com/questions/46525629/ssh-failing-after-postponed-publickey-and-single-attempt it can also happen if there is a problem with accessing the secret key, but it looks like in those cases authentication ultimately fails, which is not the case for you, so that cause seems less likely. So I would first try adding to your ssh command: -o PreferredAuthentications=publickey If that causes the message to go away on the server side, then update your SSH client configuration accordingly. You can also try disabling all unwanted authentication methods as suggested on the Red Hat page, and maybe enabling them on a host-by-host and as-needed basis. -- Michael Kjörling https://michael.kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?”
Postponed publickey before Accepted publickey - what's happening there then?
Hi, I typically have logcheck send me anomalous logs. In the last week, all Debian 10 machines (I know, I know, upgrade needed) started logging this whenever I logged in from a particular other host by SSH: 2024-01-27T07:59:42.003881+00:00 t.example.com sshd[12319]: Postponed publickey for root from 2001:db8:1f1:f0c2::2 port 37032 ssh2 [preauth] 2024-01-27T07:59:42.01+00:00 t.example.com sshd[12319]: Accepted publickey for root from 2001:db8:1f1:f0c2::2 port 37032 ssh2: RSA SHA256:iC8C78UYVJdr+bsqV1hbtBFuft6KHi0b8i308Zn0C9o 2024-01-27T07:59:42.020718+00:00 t.example.com sshd[12319]: pam_unix(sshd:session): session opened for user root by (uid=0) 2024-01-27T07:59:42.033599+00:00 t.example.com systemd-logind[1729]: New session 18604 of user root. (host names and IPv6 addresses are made up as not relevant here) As you can see, this login was successful. What I had not seen before was the line: 2024-01-27T07:59:42.003881+00:00 t.example.com sshd[12319]: Postponed publickey for root from 2001:db8:1f1:f0c2::2 port 37032 ssh2 [preauth] This only happens when I log in as root using a public key, i.e. ssh -i /path/to/pubkey r...@t.example.com (though in reality a script doing this, but I can replicate the same when doing it manually). The "postponed" line doesn't happen when I log in by key as my own user. What is actually happening there to cause that line to be logged then? Is it possibly something to do with my ssh-agent having another key that would allow that to work, but it waits to use the key specified on the ssh command line? I am not aware of any change made in the last week or two that would cause this to start happening, although I did reboot the client host (2001:db8:1f1:f0c2::2 here) in that time frame so possibly my ssh-agent environment has changed in some way. Thanks, ]Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting
