On 23.02.2023 02:07, Freek de Kruijf wrote:

Hi,

I have a Tumbleweed system which makes a backup each night to a Leap 15.4 system, both use aarch64 architecture. I use publickey for authentication, which worked until recently. Both are up-to-date with the latest updates.

On the Tumbleweed system I have: # ls -l .ssh/id_* -rw------- 1 root root 1381 21 feb 12:34 .ssh/id_dsa -rw-r--r-- 1 root root 608 21 feb 12:34 .ssh/id_dsa.pub

On the Leap 15.4 system I have: rpi4-154:~ # ls -l .ssh/authorized_keys -rw------- 1 root root 2962 feb 21 12:39 .ssh/authorized_keys with the content of id_dsa.pub. The start of the content is: ssh-dss AAAAB3NzaC1kc3MAAACBAIxtorhRWGDeP6L01o83+LgSL9DYcYAXozXtl1cknkfbO

To test the way the connection is made I give the command: ssh -v -p xx root@ Which gives me debug output. After negotiation for the ssh connection the output shows the start of the publickey negotiation, which immediately starts with: debug1: Skipping ssh-dss key /root/.ssh/id_dsa - corresponding algo not in PubkeyAcceptedAlgorithms

And what is your question then? It quite clearly tells you why this public key is ignored.

A few lines further on I have: debug1: kex_input_ext_info: server-sig-algs= in which ssh-dss is present.

It does not matter if client will not offer this algorithm. Add ssh-dss to PubkeyAcceptedAlgorithms on client or use different key which is accepted by both.

It goes on with: debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,password,keyboard- interactive debug1: Next authentication method: publickey But then a number of "debug1: Trying private key: /root/.ssh/id_*" where id_dsa is not present. It continues with: debug1: Next authentication method: keyboard-interactive So it asks for a password and authorization with publickey no longer works.

Previously I tried "ssh-keygen -t ecdsa" which did not work either and the one that I used, which worked, was of the type rsa.

Any ideas? Bug?