Ssh login with key dosent work after update

Yesterday I’ve updated my system. Since the update I’m not able to login to a ssh server with key. The server always asks for a password.
e.g. ssh root@abc.de
root@abc.de password:

When I start the same session with ssh -i ./.ssh/id_dsa there is no problem.

Any ideas?

2024-07-01 - Robin Candau

After upgrading to openssh-9.8p1, the existing SSH daemon will be unable to accept new connections (see Can’t login after openssh 9.8p1-1 upgrade, MUST restart sshd (#5) · Issues · Arch Linux / Packaging / Packages / openssh · GitLab ).
When upgrading remote hosts, please make sure to restart the sshd service using systemctl try-restart sshd right after upgrading.

We are evaluating the possibility to automatically apply a restart of the sshd service on upgrade in a future release of the openssh-9.8p1 package.

Hi @qbit,

I also use keys and have had absolutely no problems with mine. I’ve been able to log into my PI multiple times, with different users since the update. Add to that the fact

And I’m thinking there’s some kind of configuration problem…or that the specified key file can’t be found .

Please provide the output of:

cat ~/.ssh/config

:bangbang: Tip :bangbang:

When posting terminal output, copy the output and paste it here, wrapped in three (3) backticks, before AND after the pasted text. Like this:

```
pasted text
```

Or three (3) tilde signs, like this:

~~~
pasted text
~~~

This will just cause it to be rendered like this:

Sed
sollicitudin dolor
eget nisl elit id
condimentum
arcu erat varius
cursus sem quis eros.

Instead of like this:

Sed sollicitudin dolor eget nisl elit id condimentum arcu erat varius cursus sem quis eros.

Alternatively, paste the text you wish to format as terminal output, select all pasted text, and click the </> button on the taskbar. This will indent the whole pasted section with one TAB, causing it to render the same way as described above.

Thereby increasing legibility thus making it easier for those trying to provide assistance.

For more information, please see:


:bangbang::bangbang: Additionally

If your language isn’t English, please prepend any and all terminal commands with LC_ALL=C. For example:

LC_ALL=C bluetoothctl

This will just cause the terminal output to be in English, making it easier to understand and debug.

There is no cat ~/.ssh/config. I’ve the problem on two machine. Both runs under kde.
yesterday I had no problem.

ssh -v shows:

ssh root@abc.de -v                                                           INT ✘ 
OpenSSH_9.8p1, OpenSSL 3.3.1 4 Jun 2024
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Reading configuration data /etc/ssh/ssh_config.d/20-systemd-ssh-proxy.conf
debug1: Connecting to abc.de [1.2.3.4] port 22.
debug1: Connection established.
debug1: identity file /home/MyUser/.ssh/id_rsa type -1
debug1: identity file /home/MyUser/.ssh/id_rsa-cert type -1
debug1: identity file /home/MyUser/.ssh/id_ecdsa type -1
debug1: identity file /home/MyUser/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/MyUser/.ssh/id_ecdsa_sk type -1
debug1: identity file /home/MyUser/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file /home/MyUser/.ssh/id_ed25519 type -1
debug1: identity file /home/MyUser/.ssh/id_ed25519-cert type -1
debug1: identity file /home/MyUser/.ssh/id_ed25519_sk type -1
debug1: identity file /home/MyUser/.ssh/id_ed25519_sk-cert type -1
debug1: identity file /home/MyUser/.ssh/id_xmss type -1
debug1: identity file /home/MyUser/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_9.8
debug1: Remote protocol version 2.0, remote software version OpenSSH_9.2p1 Debian-2+deb12u2
debug1: compat_banner: match: OpenSSH_9.2p1 Debian-2+deb12u2 pat OpenSSH* compat 0x04000000
debug1: Authenticating to abc.de:22 as 'root'
debug1: load_hostkeys: fopen /home/MyUser/.ssh/known_hosts2: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or directory
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: sntrup761x25519-sha512@openssh.com
debug1: kex: host key algorithm: ssh-ed25519
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: SSH2_MSG_KEX_ECDH_REPLY received
debug1: Server host key: ssh-ed25519 SHA256:uVwc35L389nvDgOg6fLtjna/6UNMwlDGuPCemr7tcps
debug1: load_hostkeys: fopen /home/MyUser/.ssh/known_hosts2: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or directory
debug1: Host 'abc.de' is known and matches the ED25519 host key.
debug1: Found key in /home/MyUser/.ssh/known_hosts:12
debug1: ssh_packet_send2_wrapped: resetting send seqnr 3
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: ssh_packet_read_poll2: resetting read seqnr 3
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey in after 134217728 blocks
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_ext_info_client_parse: server-sig-algs=<ssh-ed25519,sk-ssh-ed25519@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,sk-ecdsa-sha2-nistp256@openssh.com,webauthn-sk-ecdsa-sha2-nistp256@openssh.com,ssh-dss,ssh-rsa,rsa-sha2-256,rsa-sha2-512>
debug1: kex_ext_info_check_ver: publickey-hostbound@openssh.com=<0>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Will attempt key: /home/MyUser/.ssh/id_rsa 
debug1: Will attempt key: /home/MyUser/.ssh/id_ecdsa 
debug1: Will attempt key: /home/MyUser/.ssh/id_ecdsa_sk 
debug1: Will attempt key: /home/MyUser/.ssh/id_ed25519 
debug1: Will attempt key: /home/MyUser/.ssh/id_ed25519_sk 
debug1: Will attempt key: /home/MyUser/.ssh/id_xmss 
debug1: Trying private key: /home/MyUser/.ssh/id_rsa
debug1: Trying private key: /home/MyUser/.ssh/id_ecdsa
debug1: Trying private key: /home/MyUser/.ssh/id_ecdsa_sk
debug1: Trying private key: /home/MyUser/.ssh/id_ed25519
debug1: Trying private key: /home/MyUser/.ssh/id_ed25519_sk
debug1: Trying private key: /home/MyUser/.ssh/id_xmss
debug1: Next authentication method: password
root@abc.de's password: 

Do you use DSA algorithm? That’s deprecated now.

OpenSSH plans to remove support for the DSA signature algorithm in
early 2025. This release disables DSA by default at compile time.

Source: OpenSSH: Release Notes

2 Likes

but perhaps:
ls -al ~/.ssh
shows something?
… yes it will - sorry, I failed to register that …

this means that you never connected using your users account, but (as is evident from the rest) you used the root account.
You should better not do that - disallow root logins.

Instead, connect as your user and then, once connected, use sudo or su to get to root when needed

3 Likes

Well, that might be your problem. Or a bit related to it. I recommend you generate keys, according to:

https://wiki.archlinux.org/title/SSH_keys

Also, see

And this is, according to me, a good guide:

Hope this helps!

That was a good tip.
The key is actually an RSA key, but I had it stored in the id_dsa file. After renaming the file to id_rsa, the login works without any issues again

Thank you :slight_smile:

I’d move over to ed25519, if possible.

You should disallow password and root logins…especially don’t allow root to login using a password.

2 Likes

This topic was automatically closed 36 hours after the last reply. New replies are no longer allowed.