Can't get public-key authentication to work

[David Dyer-Bennet]

I've been using public-key authentication routinely for a LONG time, from Windows and Solaris and Linux boxes to Solaris, Linux, and some FreeBSD boxes. Usually it's a snap to set up; the one difficult thing is figuring out what that particular distribution and sysadmin has required for protection on the home directory, .ssh directory, and authorized_keys file.

It looks like it should be a snap on FreeNas 9.2.1; I should be able to just paste the public key into the field in the user dialog box and save it, right? And when I do so, it appears in the .ssh/authorized_keys file where I expect. But it doesn't work. (And the .ssh directory protection looks wonky; it's group write, and while the group is the user's private group, most sshd installs refuse to tolerate that.)

SSH is on and working; I can ssh into the box as this user, by providing the password.

But when I try to SSH in using the key, it just prompts me for the password. The Putty log doesn't seem to show anything interesting, just that it didn't seem to see the key it could provide the password for. The auth.log file shows:

Apr 10 23:08:51 gw66 sshd[10893]: error: Received disconnect from 192.168.0.4: 13: Unable to authenticate [preauth]

Is there any kind of known trick to this? Maybe a FreeBSD thing, I haven't admined that before, just Linux and Solaris? Does FreeBSD need the same format for the public key that Linux does, or something different?

I've found a bunch of online stuff on this, but it's all people who eventually say that simple things I've already tried resolved their problem.

 

[SmallGuy]

Edit the .ssh/authorized_keys file and confirm your key is in one and unique line.
http://forums.freenas.org/index.php...h-access-without-passwords-using-winscp.6641/

 

[David Dyer-Bennet]

My setup is in a format that works consistently (and has for a decade or so) on Solaris and Linux. If the requirements aren't different, it should work here. "One and unique line" isn't clear to me -- but I know, of course, that each key must be on one line.

(Incidentally, I just found the first major shortcoming of FreeNAS -- Emacs isn't installed.)

 

[SmallGuy]

When I set up ssh, I meet the GUI bug described in the linked thread.
As you use the GUI to paste your key, I warn you, as I don't know if the bug is already
there with the Freenas version you use.
Just edit the file and check...

 

[David Dyer-Bennet]

I've tried creating the authorized_keys file a number of ways, not just through the GUI, and I checked the format the GUI produced and it looked valid to me (one long line, no blank lines in the file, though that's harmless anyway).

Next test will be to scp the exact file from another box where it's working, I guess. Nobody has said yet that the format required is different from Solaris or Linux, so that should get me a known-good file.

 

[David Dyer-Bennet]

[about your avatar]

By the way, is that thumbnail somehow a reference to "GH Solutions" (since it's the "G" and "H" keys that are replaced by the big green "Solutions" key)? Or was it just a convenient bit of keyboard to put a special key into and the letters replaced didn't mean anything? Just curious!

 

[cyberjock]

Adding it outside the GUI is going to be a mess.. not likely to work and can cause problems.

The keying requires putty and the server to have the keys setup and enabled. If you had a key setup in putty and it wasn't correct for FreeNAS putty will login as the username, try the key, then return an error like "key rejected" and give you a password prompt. The fact that you aren't getting that tells me putty isn't properly setup on your desktop.

 

[David Dyer-Bennet]

[bad words here]

Huh; just now when I ssh'd over to the FreeNAS box to try SCPing the authorized_keys file from somewhere it works -- instead of being prompted for the password, as I expected, I was let in.

So, this probably means I was doing something stupidly wrong yesterday -- most likely not having re-installed my key passphrase into Pagaent after a reboot sometime, and losing track of that. I'm absolutely sure some of my tests had the key in right, since I remember putting it in several times, so there was something wrong about the simple initial config that I haven't figured out yet. I'll try to investigate more and report back anything interesting that happens.

 

[SmallGuy]

By the way, is that thumbnail somehow a reference to "GH Solutions" (since it's the "G" and "H" keys that are replaced by the big green "Solutions" key)? Or was it just a convenient bit of keyboard to put a special key into and the letters replaced didn't mean anything? Just curious!

No, unfortunatly.
This is the special key I got on my keyboard to solve SSH trouble. :p

 

[David Dyer-Bennet]

Bingo!

I created a new user, sshtest001, through the FreeNAS WebGUI. I put the public key into the WebGUI.

In the user dialog box, I specified a home directory (that field is badly labeled; it's actually the directory in which the home directory for the new user will be created) of /mnt/zp66/t1 (zfs filesystem t1 in pool zp66).

It created:

[root@gw66] /mnt/zp66/t1/ddb# ls -ld ~sshtest001
drwxrwxr-x+ 3 sshtest001 sshtest001 12 Apr 11 15:11 /mnt/zp66/t1/sshtest001/

The .ssh directory had the same protection, the authorized_keys file was also 775 (executable! probably because this is configured as a Windows share).

I manually changed .ssh to 755 and authorized_keys to 644 (taking away group write from both, and executable from authorized_keys).

SSH public-key authentication still fails, with this message in auth.log:

Apr 11 15:08:57 gw66 sshd[25682]: Authentication refused: bad ownership or modes for directory /mnt/zp66/t1/sshtest001

I changed the protection of ~sshtest001 to 755 also, and public-key authentication immediately began working.

On consideration, this isn't surprising -- sshd by default is very careful to not allow anything where somebody other than the user might have write access to the authorized_keys file or the .ssh directory. It doesn't make allowances for private groups (not sure it should, either).

So, it looks to me like creating a user with a public key does the same thing wrong three times: user home directory, .ssh file, and authorized_keys file are group writable, but sshd won't accept that.

So, I think I've tracked down an actual bug. What's my proper way to get it formally into the system now? (I'll go look, if it's obvious I'll probably find it.)

 

[David Dyer-Bennet]

Found issue tracker, found "register" link (was off the right edge of my screen originally, and about the only thing on the page off the right edge so it wasn't obvious to scroll horizontally and look).

So I'm entering a ticket for this, not having found anything that seems related.

 

[SmallGuy]

In the user dialogue box, how have you configure the home directory permissions when you have created the user?

 

[SmallGuy]

Can you try to create a dataset with the same name than the user name you use.
Define this dataset in the home directory field(mislabeled as you have mention).
Set up permissions 755 (default?).
Then paste your key.
What's append?

 

[David Dyer-Bennet]

Well this is interesting. If you go to advanced mode in the add user box, yeah, you get a permissions field for the home directory. The default is 755. *BUT* if you do not change those permissions it creates a directory with mode 775, just like if you stay on the basic page:

[root@gw66] /mnt/zp66/t1/ddb# ls -ld ~sshtest002
drwxrwxr-x+ 3 sshtest002 sshtest002 11 Apr 11 17:26 /mnt/zp66/t1/sshtest002/

Furthermore, if I create new user and click the group write button on directory permissions to make the permissions 775, and then, unclick it, to make them 755 again -- it still creates a directory with permissions 775.

[root@gw66] /mnt/zp66/t1/ddb# ls -ld ~sshtest003
drwxrwxr-x+ 3 sshtest003 sshtest003 11 Apr 11 17:42 /mnt/zp66/t1/sshtest003/


Something is deeply broken with those directory permission checkboxes on the advanced page, and the basic page creates by default something that doesn't work with ssh.

 

[SmallGuy]

Hum, I agree something going wrong, or I miss something...
Thanks for the bug reports:
https://bugs.freenas.org/issues/4789
https://bugs.freenas.org/issues/4788

 

[warri]

Yes, thanks for the bug reports. When I set up my public keys I just used the shell because I didn't have time to figure out the subtleties of using the GUI. Would be great if the process can be improved to be more user friendly :)

 

[David Dyer-Bennet]

I delved slightly deeper, and set home directory permissions in the Add User advanced dialog to something other than the default (I think 700, but don't hold me to that). It again created the home directory as 775. It appears based on a couple of tests now that it just completely ignores the home directory permission fields in the advanced dialog box.

 

[dlavigne]

In that case, create a bug report at bugs.freenas.org and post the issue number here.

 

[David Dyer-Bennet]

In that case, create a bug report at bugs.freenas.org and post the issue number here.

Created Friday, 4788 and 4789

 

[tmacka88]

Hi,

So I have created my rsa keys from terminal

Code:

ssh-keygen -t rsa -C "freenas"

then saved it

Code:

/Users/iMac-Home/.ssh/freenas_rsa

gone to my .ssh folder on my and found both keys private and public.

Logged into FreeNAS GUI > Services/SSH advanced and copy/pasted my private key into there.

However when I try ssh without password (selected). I get

Code:

Permission denied (publickey).

Any help would be great. I have seen a few other tutorials that do it differently, but can't seam to fully follow it.


Also I have tried inputting my public key into my user but I get

An error occurred!

message up the top. when i go back into it there is no public key in there.

I have tried finding the .ssh/authorized_keys file/folder but can't find it when i SFTP?