AD users + ssh key = impossible?

[jpawlicki]

The word from Support is that this can't be done. Reading thru many threads it seems it should be "this" close to possible, so I'm asking here. Core 13.0, domain joined. Domain users & groups work fine for SMB shares, but for large file transfers from Linux rsync is desirable. SSH service must NOT allow password auth or anyone in the domain could login; I've also added Auxiliary Parameter "AllowGroups my-ad-group" to limit access. Public key can only be explicitly entered for a local user, and rsync with such a user+key works fine; but there's no way to specify a key for AD account. It would seem that if AD users got a proper auto-created homedir, one might create /.ssh/authorized_keys and get it to work.

Any chance someone has found a solution for this particular use case?

 

[Patrick M. Hausen]

It would seem that if AD users got a proper auto-created homedir, one might create /.ssh/authorized_keys and get it to work.

Exactly. I have this running. AD integration for multiuser time machine, people can login via ssh with password, the home directory gets created automatically, then they upload their key, plain works.

We could compare configurations and use cases if you like. Here the NAS is the central time machine and also shell/jumphost server so everybody is allowed to log on.

 

[Ericloewe]

Sounds scriptable, for sure. Scheduled job to regularly create missing home directories and fill in the authorized_keys file from whatever database.

Alternatively, you might be able to simplify this on the TrueNAS side by using SSH certificates instead of a key, that way you only need to setup the CA - but you'll probably need to reconfigure it at every startup, since I don't think TrueNAS is setup to persist that.

 

[jpawlicki]

people can login via ssh with password

Not desired, ssh service has password auth disabled, but I can create the keys as needed if I find the correct location. Following docs for Home share doesn't work, as every AD user that logs in (when password enabled) gets a directory created under the main /home/DOMAINNAME instead of the SMB Home share I defined. But even creating the /.ssh/authorized_keys for the user here won't work, and the login is denied.

 

[Patrick M. Hausen]

This is the definition of my home share:


When a user logs in for the first time (IIRC mounting any other share via SMB also works) a subdirectory named <DOMAIN>/<USER> is created. Placing the SSH credentials in there lets users log in.

 

[jpawlicki]

Thanks for your suggestions. I had the same settings apart from %U, which I've added, and "No presets", called for explicitly here - https://www.truenas.com/docs/core/coretutorials/sharing/smb/homeshare/
Tested again and verified that nothing is created under the intended /mnt/tank/User_Homes, but the user gets placed into /home/DOMAIN/user with an ssh password login (temporarily enabled). Frustrating that the only answer from support is "you can't".

 

[Johnny Fartpants]

but for large file transfers from Linux rsync is desirable

Why not mount the SMB share on the Linux machine and then rsync?

 

[jpawlicki]

Again, appreciate the suggestion but this is actually the original problem. For large filesets and many small files, rsync on a host with an SMB share has AWFUL performance. There's a lot of internet background out there, but a real-world example is 19 HOURS vs. 29 SECONDS when the NAS is an actual rsync server.

 

[Patrick M. Hausen]

I remember vaguely that initially I got those home directories created under /home, too. If only I could remember what I changed. Talked over the matter with @anodos a bit and essentially if there is an AD directory service and a defined "home share", then users' home directories should get created under these.

Are you running the latest update?

 

[anodos]

I remember vaguely that initially I got those home directories created under /home, too. If only I could remember what I changed. Talked over the matter with @anodos a bit and essentially if there is an AD directory service and a defined "home share", then users' home directories should get created under these.

Are you running the latest update?

Yes, homes share is way to do this automatically in TN. Otherwise you can put auxiliary parameter for template homedir in services->smb https://www.samba.org/samba/docs/current/man-html/smb.conf.5.html#TEMPLATEHOMEDIR. Putting things directly on /home is a bad idea on TrueNAS since this is typically on the boot device. We have safeguards to prevent this in most recent versions of TrueNAS. SCALE Cobia is adding support for 2FA for AD users (as well as API / webui access for them in some circumstances).

 

[danb35]

I don't think TrueNAS is setup to persist that.

Sure it is (well, can be). Put the CA's public key somewhere in your filesystem, then add the appropriate directives in Services -> SSH -> Aux parameters:

advanced:ssh_certificates [danb35's Wiki]

www.familybrown.org

 

[jpawlicki]

As noted, running Core 13.0-U5.1, which I'm pretty sure is recent. Agreed that /home is a bad idea, so this is an unfortunate choice for default behavior. Attempts to add a "template homedir =" parameter immediately borked the SMB service and broke connectivity for everyone, so that doesn't seem safe (no, I don't have an entire separate test system). I'm not grasping why a homedir for ssh users is controlled by an SMB service setting, but presumably it's because that's how domain logins roll. If someone knows factually that auto-homedir works for domain ssh users, and can tell me where the documented procedure above is lacking, many thanks.

 

[Junx]

Use IPA as the backing store for SSH keys.

Unit 10: SSH user and host key management — FreeIPA 4.11-dev documentation

 

[jpawlicki]

Use IPA as the backing store for SSH keys.

Unit 10: SSH user and host key management — FreeIPA 4.11-dev documentation

This seems to have no relevance to the original issue.