Why is it so hard to get ssh working?

[cheekymonkey]

I've never spent this amount of time to get ssh up and running before. What is going on?

I have a windows machine trying to ssh into my Truenas box in the basement.

I've tried both Putty and openssh.

On putty, I generated the keys using puttygen and pasted the public key into a user using the webgui. I verified that right formatting (single line, no spaces, etc.) was saved to ~/.ssh/authorized_keys. I made sure permissions on the target was 700. I set the perms on the client side as well for only the owner to have full control.

Putty returns Server refused our key

Here's the Putty event log:
2021-10-03 03:43:07 Looking up host "192.168.0.21" for SSH connection 2021-10-03 03:43:07 Connecting to 192.168.0.21 port 22 2021-10-03 03:43:07 We claim version: SSH-2.0-PuTTY_Release_0.76 2021-10-03 03:43:07 Connected to 192.168.0.21 2021-10-03 03:43:07 Remote version: SSH-2.0-OpenSSH_8.4-hpn14v15 2021-10-03 03:43:07 Using SSH protocol version 2 2021-10-03 03:43:07 No GSSAPI security context available 2021-10-03 03:43:07 Doing ECDH key exchange with curve Curve25519 and hash SHA-256 (unaccelerated) 2021-10-03 03:43:07 Server also has ecdsa-sha2-nistp256/rsa-sha2-512/rsa-sha2-256/ssh-rsa host keys, but we don't know any of them 2021-10-03 03:43:07 Host key fingerprint is: 2021-10-03 03:43:07 ssh-ed25519 255 SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 2021-10-03 03:43:07 Initialised AES-256 SDCTR (AES-NI accelerated) outbound encryption 2021-10-03 03:43:07 Initialised HMAC-SHA-256 (unaccelerated) outbound MAC algorithm 2021-10-03 03:43:07 Initialised AES-256 SDCTR (AES-NI accelerated) inbound encryption 2021-10-03 03:43:07 Initialised HMAC-SHA-256 (unaccelerated) inbound MAC algorithm 2021-10-03 03:43:07 Reading key file "C:\Users\xxx\truenas.ppk" 2021-10-03 03:43:10 Disabled writing session log (raw mode) to file: E:\Download\putty.log 2021-10-03 03:43:10 Offered public key 2021-10-03 03:43:10 Server refused our key

Then I generated a different set of keys using ssh-keygen, updated the pub key for the same Truenas user as above, and then attempt to connect with this command:
ssh xxx@192.168.0.21 -i id_rsa -v

I get Permission denied (publickey) when I turn off password authentication allowed in SERVICES>SSH. Verbose flag returns the debug log below:
OpenSSH_for_Windows_8.1p1, LibreSSL 3.0.2 debug1: Connecting to 192.168.0.21 [192.168.0.21] port 22. debug1: Connection established. debug1: identity file id_rsa type 0 debug1: identity file id_rsa-cert type -1 debug1: Local version string SSH-2.0-OpenSSH_for_Windows_8.1 debug1: Remote protocol version 2.0, remote software version OpenSSH_8.4-hpn14v15 debug1: match: OpenSSH_8.4-hpn14v15 pat OpenSSH* compat 0x04000000 debug1: Authenticating to 192.168.0.21:22 as 'xxx' debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: algorithm: curve25519-sha256 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: Server host key: ecdsa-sha2-nistp256 SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx debug1: Host '192.168.0.21' is known and matches the ECDSA host key. debug1: Found key in C:\\Users\\xxx/.ssh/known_hosts:1 debug1: rekey out after 134217728 blocks debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: rekey in after 134217728 blocks debug1: pubkey_prepare: ssh_get_authentication_socket: No such file or directory debug1: Will attempt key: id_rsa RSA SHA256:bbbbbbbbbbbbbbbbbbbbbbbbbbb explicit debug1: SSH2_MSG_EXT_INFO received debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,sk-ssh-ed25519@openssh.com,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,sk-ecdsa-sha2-nistp256@openssh.com,webauthn-sk-ecdsa-sha2-nistp256@openssh.com> debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,password debug1: Next authentication method: publickey debug1: Offering public key: id_rsa RSA SHA256:bbbbbbbbbbbbbbbbbbbbbbbbbbb explicit debug1: Authentications that can continue: publickey,password debug1: Next authentication method: password debug1: read_passphrase: can't open /dev/tty: No such file or directory xxx@192.168.0.21's password:

Password works just fine for both methods above.

What am I missing?

 

[jgreco]

Well, OpenSSH is saying it cannot find /dev/tty, which makes sense for a Windows box. I don't know what it should be doing instead at that point, but I would suggest reading up on OpenSSH for Windows and using passphrase authentication, and see if you've missed a step, a GUI, or something like that.

 

[cheekymonkey]

Thanks. I'm pretty sure that error only has to do with the passphrase when it's expecting a password, and even then it's not a real error as password works just fine. I'll try adding a passphrase and see what happens.

What are your thoughts on the debug1: pubkey_prepare: ssh_get_authentication_socket: No such file or directory message?

 

[cheekymonkey]

SOLVED: I created a new Truenas user and everything works fine with that user. No clue what is different between the two accounts that would cause the issues above.

 

[Patrick M. Hausen]

Does the user which is not working have a valid shell? Does it have a valid home directory? Can you login as root and execute su - <username> successfully? That should give you some clues. Home directory or shell invalid will prevent SSH logon.

 

[cheekymonkey]

Does the user which is not working have a valid shell? Does it have a valid home directory? Can you login as root and execute su - <username> successfully? That should give you some clues. Home directory or shell invalid will prevent SSH logon.

Maybe, maybe, and yes. I usually login to this user and then sudo to my nzbget jail when I need to. I confirmed that I can su to another account. I'm running zsh and the home directory has the usual requisite files. My current guess is perhaps there is a permissions problem, but at this point I've already wasted too much time troubleshooting the problem and I have a working solution.

Thanks all.