After updating, I can’t log into SSH anymore. My user is set up to log in via public key authentication. I get Permission denied (publickey). Did something change?
From the client, supply -v or -vv or -vvv for more verbose information.
It could be as simple as a change in dir_mode for the .ssh folder.
(Start with only one -v, since it’s usually verbose enough.)
I can’t decipher the problem
JimsMBPro:~ jim$ ssh -v -p ----- jim@192.168.0.102
OpenSSH_9.6p1, LibreSSL 3.3.6
debug1: Reading configuration data /Users/jim/.ssh/config
debug1: /Users/jim/.ssh/config line 12: Applying options for 192.168.0.102
debug1: /Users/jim/.ssh/config line 18: Applying options for *
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 21: include /etc/ssh/ssh_config.d/* matched no files
debug1: /etc/ssh/ssh_config line 54: Applying options for *
debug1: Authenticator provider $SSH_SK_PROVIDER did not resolve; disabling
debug1: Connecting to 192.168.0.102 [192.168.0.102] port -----.
debug1: Connection established.
debug1: identity file /Users/jim/.ssh/id_rsa type 0
debug1: identity file /Users/jim/.ssh/id_rsa-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_9.6
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 192.168.0.102:------as 'jim'
debug1: load_hostkeys: fopen /Users/jim/.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: ecdsa-sha2-nistp256
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: ecdsa-sha2-nistp256 SHA256:ZayvSvk0xxiVhPGmT1N9xrMtKLyE1NAIa4tbdOdFle0
debug1: load_hostkeys: fopen /Users/jim/.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 '[192.168.0.102]:-----' is known and matches the ECDSA host key.
debug1: Found key in /Users/jim/.ssh/known_hosts:5
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
debug1: Next authentication method: publickey
debug1: get_agent_identities: bound agent to hostkey
debug1: get_agent_identities: agent returned 1 keys
debug1: Will attempt key: /Users/jim/.ssh/id_rsa RSA SHA256:lgbrOPYUaJV4hCgODFv72ob1VXA1fslcDj+PNh4Jkn4 explicit agent
debug1: Offering public key: /Users/jim/.ssh/id_rsa RSA SHA256:lgbrOPYUaJV4hCgODFv72ob1VXA1fslcDj+PNh4Jkn4 explicit agent
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
jim@192.168.0.102: Permission denied (publickey).
You can add one or two more v’s to the command.
In the meanwhile, what is the ownership/permission of your client’s .ssh directory, and the same for the authorized_keys file?
ls -la $HOME/.ssh
Check the same for your user on the TrueNAS server.
ls -la $HOME/.ssh
They should be 700 and 600 respectively.
EDIT: It’s good practice not to paste output that might contain sensitive/key information. (Even if it is all “locally contained” on your own network. Just a good habit to get into.)
1 Like
Thanks @winnielinnie Somehow my user directory gained write access for group. So
chmod g-w Jim
allowed me to SSH in.
Yeah, I wasn’t sure, is a hash sensitive?
1 Like
It’s just the “habit”, to vet text dumps. Sometimes you might inadvertently leak an identifiable filename, or public IP address, etc.
So there’s no issue with your text itself, but it’s a healthy reminder.
Hmm. Post re-installing 24.04.1.1 and restoring my config, I couldn’t log in via SSH as well. It seems the authorised keys for my users weren’t included in the config?
This might be unrelated to the OP’s now resolved issue.
If the “user” is root, then it does not get preserved with an exported config.
I believe a non-root user’s authorized keys should be exported with your config, unless they changed that? (I doubt that changed in Dragonfish.)
As it was a new install this month it pushed me to create admin, which I did.