I have since long time ago my server (B) configured to log from my desktop PC (A) with ssh with no key:
In B: ~/.ssh/authorized_keys2 i have my id_rsa.pub from A copied.
But today, when i try ssh B i’m asked for the key. With the key I can log in, i have edited authorized_keys2 and copied again the pub key from A just in case, but the same.
Any ideas why?
best regards
Try:
ssh -v B
or even
ssh -vvv B
The verbose output may help explain what is going wrong.
Hi
Is your sshd config set to authorized_keys2 or authorized_keys?
it was, unless something changed it.
I have seen this" The release announcement for version 3 states that authorized_keys2 is deprecated and all keys should be put in the authorized_keys file."
So I have renamed authorized_keys2 to authorized_keys… still the same
And this was commented in /etc/ssh/sshd_config. I have uncommented it and restart sshd, but still the same
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
There it is but I don’t know what is wrong I would say that “debug1: SSH2_MSG_SERVICE_ACCEPT received” mean the autentication is accepted … but it isn’t
fernando@andromeda:~> ssh aldebaran
Password:
Last login: Wed Mar 25 16:40:38 2020 from 192.168.2.3
Have a lot of fun...
fernando@aldebaran:~> logout
Connection to aldebaran closed.
fernando@andromeda:~> ssh -v aldebaran
OpenSSH_7.9p1, OpenSSL 1.1.0i-fips 14 Aug 2018
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 25: Applying options for *
debug1: Connecting to aldebaran [192.168.2.5] port 22.
debug1: Connection established.
debug1: identity file /home/fernando/.ssh/id_rsa type 0
debug1: identity file /home/fernando/.ssh/id_rsa-cert type -1
debug1: identity file /home/fernando/.ssh/id_dsa type -1
debug1: identity file /home/fernando/.ssh/id_dsa-cert type -1
debug1: identity file /home/fernando/.ssh/id_ecdsa type -1
debug1: identity file /home/fernando/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/fernando/.ssh/id_ed25519 type -1
debug1: identity file /home/fernando/.ssh/id_ed25519-cert type -1
debug1: identity file /home/fernando/.ssh/id_xmss type -1
debug1: identity file /home/fernando/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_7.9
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.9
debug1: match: OpenSSH_7.9 pat OpenSSH* compat 0x04000000
debug1: Authenticating to aldebaran:22 as 'fernando'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: rsa-sha2-512
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: kex: curve25519-sha256 need=64 dh_need=64
debug1: kex: curve25519-sha256 need=64 dh_need=64
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ssh-rsa SHA256:0prPkrsha3yCPXyT4UTwKYv1xxxxx
debug1: Host 'aldebaran' is known and matches the RSA host key.
debug1: Found key in /home/fernando/.ssh/known_hosts:3
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 134217728 blocks
debug1: Will attempt key: /home/fernando/.ssh/id_rsa RSA SHA256:VdaF8D8Boqfj3Di6qxxxxxx
debug1: Will attempt key: /home/fernando/.ssh/id_dsa
debug1: Will attempt key: /home/fernando/.ssh/id_ecdsa
debug1: Will attempt key: /home/fernando/.ssh/id_ed25519
debug1: Will attempt key: /home/fernando/.ssh/id_xmss
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,null>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering public key: /home/fernando/.ssh/id_rsa RSA SHA256:VdaF8D8Boqfj3Di6q5syZqR0loiGnxxxx
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Trying private key: /home/fernando/.ssh/id_dsa
debug1: Trying private key: /home/fernando/.ssh/id_ecdsa
debug1: Trying private key: /home/fernando/.ssh/id_ed25519
debug1: Trying private key: /home/fernando/.ssh/id_xmss
debug1: Next authentication method: keyboard-interactive
Password:
Has something changed on the server?
Assuming that you are using “/home/someuser/.ssh/authorized_keys”
then check the permissions of “/”, “/home”, “/home/someuser”, “/home/someuser/.ssh” and “/home/someuser/.ssh/authorized_keys”. They must not be writable by anyone other than “someuser” (and, of course, root). Any group write bit or any wrong ownership will block publickey authentication.
Are you also using host-based authentication in any form what-so-ever?
I didn’t think so but…
Assuming that you are using “/home/someuser/.ssh/authorized_keys”
then check the permissions of “/”, “/home”, “/home/someuser”, “/home/someuser/.ssh” and “/home/someuser/.ssh/authorized_keys”. They must not be writable by anyone other than “someuser” (and, of course, root). Any group write bit or any wrong ownership will block publickey authentication.
That was it. The directory had their permissions changed … in fact I did it by error some days ago when giving permissions to other user in other directory with setfacl.
I have changed it as you said and everything normal again.
best regards
I’m glad to hear that things are now working. Thanks for reporting back.