So passwordless SSH broke

Status
Not open for further replies.

Binary Buddha

Contributor
Joined
Mar 6, 2016
Messages
126
Been trying to figure out what broke my once running passwordless SSH key setup. Don't know where the SSH log on Freenas is to give more detail. But here's the info I got. /Users/Binary/.ssh/id_rsa is the key used. It's like Freenas base OS isn't accepting my key anymore.

On Freenas
[binary@freenas ~/.ssh]$ ls -la
total 80
drwx------ 2 binary binary 6 Apr 10 22:56 .
drwxrwxrwx 16 binary binary 34 Apr 10 22:54 ..
-rwxr-xr-x 2 binary binary 396 Apr 10 22:55 authorized_keys
-rwxr-xr-x 2 binary binary 396 Apr 10 22:55 authorized_keys2
-rw------- 1 binary binary 1679 Apr 10 22:54 id_rsa
-rw-r--r-- 1 binary binary 402 Apr 10 22:54 id_rsa.pub
-rw-r--r-- 1 binary binary 402 Apr 10 22:54 id_rsa.pub
[binary@freenas ~/.ssh]$ cat authorized_keys*
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAuSO75OvD2udB65iaLFQ9jFamp9RxwDSjxo/Or5mdFWPkWThTsTM6fizxobl2ZzJVBOYFA9YwjP4iVhWzS8Iz5CdGr4XsHiu24RZcIkd/W7UMpNR750R7cJVkbxZjkPPXiOFM68V0Rs2k+gFxWq3bfxIAxqV+dpv7UJQSkIN27wZvqfuv5Ps7Fr6pwXyMSGypf9HO/HEOIe88PRhhgBizbhydvohHexm7tu+Tmm8m9IjD9AId3HmMlz1kO4FpG43EJyJQVFTSXwwc8jq3daRLgArbYMtS0KDi0h5XyQbLGUBUIVmJwDUQcK5VnEsi9Q9yP9JuMlrpul50yEr6/motaQ== psyber@Bitslip
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAuSO75OvD2udB65iaLFQ9jFamp9RxwDSjxo/Or5mdFWPkWThTsTM6fizxobl2ZzJVBOYFA9YwjP4iVhWzS8Iz5CdGr4XsHiu24RZcIkd/W7UMpNR750R7cJVkbxZjkPPXiOFM68V0Rs2k+gFxWq3bfxIAxqV+dpv7UJQSkIN27wZvqfuv5Ps7Fr6pwXyMSGypf9HO/HEOIe88PRhhgBizbhydvohHexm7tu+Tmm8m9IjD9AId3HmMlz1kO4FpG43EJyJQVFTSXwwc8jq3daRLgArbYMtS0KDi0h5XyQbLGUBUIVmJwDUQcK5VnEsi9Q9yP9JuMlrpul50yEr6/motaQ== psyber@Bitslip


On Client
Molly-2:.ssh Binary$ cat id_rsa.pub
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAuSO75OvD2udB65iaLFQ9jFamp9RxwDSjxo/Or5mdFWPkWThTsTM6fizxobl2ZzJVBOYFA9YwjP4iVhWzS8Iz5CdGr4XsHiu24RZcIkd/W7UMpNR750R7cJVkbxZjkPPXiOFM68V0Rs2k+gFxWq3bfxIAxqV+dpv7UJQSkIN27wZvqfuv5Ps7Fr6pwXyMSGypf9HO/HEOIe88PRhhgBizbhydvohHexm7tu+Tmm8m9IjD9AId3HmMlz1kO4FpG43EJyJQVFTSXwwc8jq3daRLgArbYMtS0KDi0h5XyQbLGUBUIVmJwDUQcK5VnEsi9Q9yP9JuMlrpul50yEr6/motaQ== psyber@Bitslip

Molly-2:.ssh Binary$ ssh -v nas
OpenSSH_6.9p1, LibreSSL 2.1.8
debug1: Reading configuration data /Users/Binary/.ssh/config
debug1: /Users/Binary/.ssh/config line 63: Applying options for nas
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 20: Applying options for *
debug1: /etc/ssh/ssh_config line 53: Applying options for *
debug1: Connecting to 10.0.0.4 [10.0.0.4] port 22.
debug1: Connection established.
debug1: identity file /Users/Binary/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/Binary/.ssh/id_rsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.9
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1_hpn13v11 FreeBSD-20140420
debug1: match: OpenSSH_6.6.1_hpn13v11 FreeBSD-20140420 pat OpenSSH_6.6.1* compat 0x04000000
debug1: Authenticating to 10.0.0.4:22 as 'binary'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client chacha20-poly1305@openssh.com <implicit> none
debug1: kex: client->server chacha20-poly1305@openssh.com <implicit> none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:JKQAiGKbefmlfdMwl5FsaWbgAQai4YCPaJNPpV2Kb0g
debug1: Host '10.0.0.4' is known and matches the ECDSA host key.
debug1: Found key in /Users/Binary/.ssh/known_hosts:13
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/Binary/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password
debug1: Offering RSA public key: BHA-id_rsa
debug1: Authentications that can continue: publickey,password
debug1: Offering RSA public key: nas_key_id_rsa
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: password
binary@10.0.0.4's password:


SSH Config on client for "nas":

host nas
hostname 10.0.0.4
user binary
IdentityFile /Users/Binary/.ssh/id_rsa
 

Binary Buddha

Contributor
Joined
Mar 6, 2016
Messages
126
@cyberjock ... I know you know your stuff... Any ideas?
 

m0nkey_

MVP
Joined
Oct 27, 2015
Messages
2,739
Your authorized_keys file has the execution bit. Why? The authorized_keys file should be rw by only the owner.
 

DrKK

FreeNAS Generalissimo
Joined
Oct 15, 2013
Messages
3,630
Your authorized_keys file has the execution bit. Why? The authorized_keys file should be rw by only the owner.
Right, so, I know it seems like a nitpick by @m0nkey_, but I seem to recall that it is the case that if the permissions on the authorized_keys file(s) and/or directories they are in are not right (even if they are such that they could be accessed!), then it will refuse to work.
 

cyberjock

Inactive Account
Joined
Mar 25, 2012
Messages
19,526
Right, so, I know it seems like a nitpick by @m0nkey_, but I seem to recall that it is the case that if the permissions on the authorized_keys file(s) and/or directories they are in are not right (even if they are such that they could be accessed!), then it will refuse to work.

I seem to remember this too.

There's only 3 possibilities to what is wrong.

1. Permissions (if memory is serving DrKK and I correctly).
2. Your public key is not being properly added to the FreeNAS system.
3. Your private key is not being properly used by your client system.

Ok, I guess there's a 4th.. what you think is a keypair isn't a keypair. :P
 

depasseg

FreeNAS Replicant
Joined
Sep 16, 2014
Messages
2,874
Which version are you running?

I just updated to 9.3.1-2016-0404 and SSH broke (new host key and the loss of the "none" cipher).
 

jgreco

Resident Grinch
Joined
May 29, 2011
Messages
18,681
Right, so, I know it seems like a nitpick by @m0nkey_, but I seem to recall that it is the case that if the permissions on the authorized_keys file(s) and/or directories they are in are not right (even if they are such that they could be accessed!), then it will refuse to work.

ssh has always been like that. You should always be testing the ssh connectivity from the command line to help debug this sort of thing. The system log and the messages you'd get from ssh in debug mode would be helpful in figuring out these sorts of issues.
 

Binary Buddha

Contributor
Joined
Mar 6, 2016
Messages
126
Last edited:

Binary Buddha

Contributor
Joined
Mar 6, 2016
Messages
126
ssh has always been like that. You should always be testing the ssh connectivity from the command line to help debug this sort of thing. The system log and the messages you'd get from ssh in debug mode would be helpful in figuring out these sorts of issues.

Your authorized_keys file has the execution bit. Why? The authorized_keys file should be rw by only the owner.

I seem to remember this too.

There's only 3 possibilities to what is wrong.

1. Permissions (if memory is serving DrKK and I correctly).
2. Your public key is not being properly added to the FreeNAS system.
3. Your private key is not being properly used by your client system.

Ok, I guess there's a 4th.. what you think is a keypair isn't a keypair. :p

I know where you're going with this. I've already changed the .ssh and authorized_keys files to the various modes; normally should be 0644. What you see was the last ditch effort to open all the things. Changing the permissions has the same result. And the key pair is a pair. I have other systems that use the same pair and they work. I also added the PUB key via the web UI for the user to no resolve.
 
Last edited:

Binary Buddha

Contributor
Joined
Mar 6, 2016
Messages
126
Which version are you running?

I just updated to 9.3.1-2016-0404 and SSH broke (new host key and the loss of the "none" cipher).
ssh has always been like that. You should always be testing the ssh connectivity from the command line to help debug this sort of thing. The system log and the messages you'd get from ssh in debug mode would be helpful in figuring out these sorts of issues.

You mean the system log on the server... Which I have no eye deer where it is. Linux world would through it in /var/log/secure.... Which doesn't seem to be the case in FreeBSD/FreeNAS world.
 

jgreco

Resident Grinch
Joined
May 29, 2011
Messages
18,681
The Linux folks do all kinds of weird/different/stupid things, I suspect many of which are so they can do things Differently Than UNIX.

System logging is controlled by syslogd, so checking /etc/syslog.conf for log file locations is always a good idea. The stuff for sshd is likely to end up in /var/log/auth.log.
 

Binary Buddha

Contributor
Joined
Mar 6, 2016
Messages
126

genBTC

Dabbler
Joined
Aug 11, 2017
Messages
33
I also had this issue, which boiled down to permissions. Unlike him, I never had a working set up, so it was very hard to diagnose, especially when you don't know all the locations of the config, log and debug files.
Heres what worked for me (with instructions):
get yourself Ssh'ed into the freenas box with a password, (or type su YOURUSER at the webgui root shell) - for the user you want to log in as.
cd ~/
Remember whats set as what so you dont mess anything up further.
ls -al
Change the home directory permissions to 755
chmod 755 ~/
Change the .ssh directory permissions to 700 (note that 600 or 644 would NOT work for me)
chmod 700 ~/.ssh/
Enter the .ssh directory
cd ~/.ssh
Double check the contents of the authorized_keys file (which should hold your SSH RSA pub key as per the guide) to make sure
cat authorized_keys
modify the permissions to 600
chmod 600 authorized_keys

After:
9c16744c57.png


If anyone sees this and knows why this happened, or what I did wrong to need all this weirdness, it would be good to know, I'm a rookie.
 
Status
Not open for further replies.
Top