SSH pubkey broken in 9.3-STABLE

Status
Not open for further replies.

mib

Dabbler
Joined
Sep 7, 2012
Messages
20
Looks like ssh pubkey auth is still broken in 9.3-RELEASE (I'm aware of https://bugs.freenas.org/issues/4788). It's particularly pernicious that a GUI-originated security configuration (which I'd assume would be tested) is broken; burnt a bunch of time debugging this as a result.

Things seem worse now because of NFSv4 ACLs. A simple `chmod 644` doesn't fix the problem. I've thrashed around with getfacl and setfacl and haven't yet managed to properly permission authorized_keys to allow it to work.

Does anyone have a suggestion for a workaround? I hate sshing without pubkey auth.

Thanks.
 

mib

Dabbler
Joined
Sep 7, 2012
Messages
20
When FreeNAS creates ~/.ssh/authorized_keys the permissions/ACL is too permissive, resulting in sshd emitting "Authentication refused: bad ownership or modes for file /mnt/tank/vol/mib/.ssh/authorized_keys" on a login attempt with a valid key. authorized_keys must be unwritable by users other than the owner (see man sshd(8) for details).

The permissions for authorized_keys after the GUI creates it is identical to those it has if I create it fresh via touch:

$ touch authorized_keys
$ ls -al authorized_keys
-rwxrwxr-x+ 1 mib mib 0 Dec 31 07:27 authorized_keys
$ chmod 644 authorized_keys
chmod: authorized_keys: Operation not permitted
$ getfacl authorized_keys
# file: authorized_keys
# owner: mib
# group: mib
owner@:rwxpDdaARWcCos:------:allow
group@:rwxpDdaARWcCos:------:allow
everyone@:r-x---a-R-c---:------:allow

So, the outright bug is that the GUI doesn't create an authorized_keys file that sshd will accept.

My request for a workaround, since this is the first time in >20yrs of *nix use that I'm confronted with NSFv4 ACLs, is how to properly set the ACL on this file (since I can't use chmod) so that sshd likes it. I've experimented a bit so far, but none of the (to me) obvious approaches is yielding usable results.

Thanks.
 

cyberjock

Inactive Account
Joined
Mar 25, 2012
Messages
19,526
I'm going to try to reproduce this bug (and then bring this up with devs as required). How are you getting this error to occur? Touching a file is not what FreeNAS does normally, so I'm not sure what your paste has to do with 'real world' usage. Can you explain?
 

mib

Dabbler
Joined
Sep 7, 2012
Messages
20
The touch example was illustrative only.

Steps to repro:
  1. Delete ~/.ssh/ for cleanliness of repro
  2. In GUI, select user's acct; paste valid ssh pubkey into SSH Public Key field; save
  3. Try to connect to the FreeNAS box via `ssh <hostname>` using valid ssh private key
  4. Note that pubkey auth does not succeed, and falls back to password; retry with `ssh -v <hostname>` if curious
  5. `tail /var/log/auth.log` on host and note "<timestamp> <host> sshd[pid]: Authentication refused: bad ownership or modes for file /mnt/tank/vol/mib/.ssh/authorized_keys"
  6. Then apply my observations above re permissions and ACLs, chmod and {get|set}facl
One question that also presents itself is why FreeNAS 9.3 defaults to NFSv4 ACLs and whether this is useful/necessary. From everything I've learnt over the last day, they are a significant additional complication for anyone who doesn't use NFSv4.

Thanks.
 
D

dlavigne

Guest
Please create a bug report at bugs.freenas.org and post the issue number here.
 

mib

Dabbler
Joined
Sep 7, 2012
Messages
20
Per jpaetzel's comment on the bug, is the only reason that NFSv4 is enabled on that dataset is because there's a CIFS sharepoint on it? If so, that's totally fixable at my end, would never have occurred to me to connect the two, and also a suggestion for clarification in the docs that setting up a CIFS-shared dataset has some drawbacks.
 
Status
Not open for further replies.
Top