passowrdless login vs. sso

themad123 · August 14, 2015, 9:28am

Hello,
I have issues with passwordless login since using nfs with kerberos:
Before the switch so kerberos we used normal ssh keys for passwordless login.
The problem now is, that the keys for this lay on the nfs share, so can not login when the share is not yet available. (when the user has logged in before and still has a valid ticket, it works)
So now my idea is to circumvent this by using kerberos for the login.
But this works only on some machines and creates no kerberos tickets, so the user has no home folder.

I would like to have this workflow:

User logs in on first linux machine or windows machine with password
User has now a TGT on the Client
User logs in passowrdless to the Server
On the server, a user and a nfs ticket is created

How can I achive this?

This are my current configs (I stripped out comments):

ssh_config

Host *
ForwardX11Trusted yes
    Protocol 2
   GSSAPIAuthentication no
   GSSAPIDelegateCredentials no
SendEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
SendEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
SendEnv LC_IDENTIFICATION LC_ALL
VisualHostKey no
HashKnownHosts yes
PreferredAuthentications gssapi-with-mic,publickey,keyboard-interactive,password

sshd_config:

PasswordAuthentication no
UsePAM yes
X11Forwarding yes
UsePrivilegeSeparation sandbox          # Default for new installations.
Subsystem       sftp    /usr/lib/ssh/sftp-server
AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
AcceptEnv LC_IDENTIFICATION LC_ALL
UseDNS  no
Protocol 2
GSSAPIAuthentication yes
GSSAPICleanupCredentials yes
KerberosAuthentication yes
KerberosOrLocalPasswd yes
KerberosTicketCleanup yes
MaxSessions 9999

krb5/conf

[libdefaults]
        forwardable = true
        default_realm = DOMAIN.NET
        clockskew = 300
        default_ccache_name = /tmp/krb5cc_%{uid}
[realms]
        DOMAIN.NET = {
                kdc = lindc1.roseninspection.net
                default_domain = roseninspection.net
                admin_server = lindc1.roseninspection.net
                forwardable = true
        }
[logging]
        kdc = FILE:/var/log/krb5/krb5kdc.log
        admin_server = FILE:/var/log/krb5/kadmind.log
        default = SYSLOG:NOTICE:DAEMON
[domain_realm]
        .roseninspection.net = DOMAIN.NET
        roseninspection.net = DOMAIN.NET
        *.roseninspection.net = DOMAIN.NET
[appdefaults]
        pam = {
                ticket_lifetime = 3d
                renew_lifetime = 28d
                forwardable = true
                proxiable = false
                minimum_uid = 900
                clockskew = 300
                external = sshd
                use_shmem = sshd
                ccache_dir = /tmp/
        }

tsu2 · August 16, 2015, 1:01am

I don’t know if there is an easy way to implement SSO without full and proper network security.
This generally means LDAP, SAMBA4 or AD (there may be other implementations) and implementing an integrated infrastructure including a PDC, DNS and DHCP.

So, in for a penny, in for a pound.
I don’t know if you can properly implement something like kerberos ticketing <only> for NFS or some other single purpose.
It might be possible, but I’d look very suspiciously at anything but a full, fully tested and widely recognized standardized solution.
But, maybe someone who thinks differently and stands by their well tested setup might say differently…

IMO,
TSU

themad123 · August 17, 2015, 12:43pm

Hello tsu2,
well, I am talking about an enterprise environment with AD, DNS etc.
The login runs via sssd and ldap/kerberos.
Nfs with kerberos is also working.
What I need is a ssh login that uses kerberos to moutn the home share.

Best regards,
themad

arvidjaar · August 17, 2015, 1:09pm

It is absolutely unclear what “this” means. Please describe step by step what you are doing, to which system you log on, what you expect to see and and what you actually see.

tsu2 · August 17, 2015, 5:20pm

A lot depends on whether your NFS server is Windows or Linux.
In any case, I don’t think you would be configuring SSH if you are configuring Kerberos auth in an AD.

I haven’t set up NFS on Linux using Kerberos in a long time.
I don’t see anything online that seems to be a recent guide except for RHEL, but the following steps make sense to me…

The following assumes you’re setting up your NFS server on openSUSE, not on a Windows box (if on Windows, that’s a whole another story).

Join your openSUSE NFS server to the AD.
Install the yast nfs server setup applet

zypper in yast2-nfs-server

verify you’ have NFS v4 installed.
Run the yast nfs server applet. In it, you’ll
- Want to check the “GSS” security checkbox, this is what enables kerberos support.
- set to start NFS which will then prompt you setup directories to export
- Set up the Host(s) which you wish to grant access. I’m not on a machine now with access to an AD, but if you’re logged in with a Domain Admin account I’d expect you should have access to AD User Groups. You may wish to grant permissions by a Host based identity (like IP addresses) instead according to the integrated documentation.

I haven’t set this up personally, but expect the above should be what you need.
If you have a problem, post back here.

TSU

themad123 · August 19, 2015, 9:55am

Hello all,
Sorry I forgot to mention that nfs server is an isilon (OneFS 7.2.0)

What works:

logging on to server1 with putty using username and password, getting home directory from nfs (which needs an kerberos ticket, so it is strange that this does not appear here)
klist
Default principal: user@DOMAIN.NET

Valid starting Expires Service principal
08/18/2015 16:07:04 08/21/2015 16:07:04 krbtgt/DOMAIN.NET@DOMAIN.NET
renew until 08/25/2015 16:07:04

logging on to server1 using centrify putty,getting home directory from nfs
output klist:
Default principal: user@DOMAIN.NET

Valid starting Expires Service principal
08/03/2015 14:30:21 08/04/2015 14:30:16 krbtgt/DOMAIN.NET@DOMAIN.NET
08/03/2015 14:30:29 08/04/2015 00:30:29 nfs/linfile2.DOMAIN.NET@DOMAIN.NET
08/03/2015 14:30:30 08/04/2015 00:30:30 nfs/linfile1.DOMAIN.NET@DOMAIN.NET

What does not work:

create ssh session to another pc, wth reason: ticket is invalid
->> the Ticket is not refreshed on login
when I refresh manually, the login works
So I think the issue might break down to refreshing the ticket on ssh login.
Can I configure this to happen automatically

arvidjaar · August 21, 2015, 6:00am

And now enters centrity …

So I think the issue might break down to refreshing the ticket on ssh login.
Can I configure this to happen automatically

In PuTTY you can enable forwardable tickets (Allow GSSAPI credential delegation). Did you do it? Also from cursory reading Centrify may have own server-side agents in which case you are better off asking them.

themad123 · October 6, 2015, 11:23am

Hello and sorry for my late answer (which was caused by vacation and sickness)
Well, we dont use centrify on the server side, I just used their putty implemetation since I found it has Kerberos support build in (I did not know that it is so easy with normal putty as well, thanks for the tip)

But this morning I tried arround as well and found something interesting when just using linux2linux: on some systems, the default principal is lowercase while on others it is camelcase.
When using 2 systems with lowercase, it work seamless, and when using kdestroy and create a ticket with the explicit lowercase username, it works as well.

So the master question is now: which process using which config creates the principal?

best regards,
themad

arvidjaar · October 6, 2015, 11:45am

Well, user side should reflect user name and server side is created by administrator. May be if you show example of them it would be easier.

themad123 · October 7, 2015, 11:25am

Hello,
I have 2 scenarios here:

First Scenario: Linux to Linux:
when I login to server1, I get a Ticket for username JDoe@DOMAIN.NET
Then logging in to server 2 with “ssh -K server2 -vvv” fails (last message regarding GSSAPI is “Delegating Credentials”)

When I use kdestroy and kinit jdoe (lowercase!) and use the same command, it works

Second Scenario:

Cached Tickets: (8)

0> Client: jdoe @ DOMAIN.NET
Server: krbtgt/DOMAIN.NET@ DOMAIN.NET
KerbTicket Encryption Type: RSADSI RC4-HMAC(NT)
Ticket Flags 0x60a00000 -> forwardable forwarded renewable pre_authent
Start Time: 10/7/2015 10:51:19 (local)
End Time: 10/7/2015 20:51:19 (local)
Renew Time: 11/4/2015 9:54:39 (local)
Session Key Type: RSADSI RC4-HMAC(NT)

Using Kerberos authentication
Using principal JDoe@DOMAIN.NET
Got host ticket host/linphystest01.Domain.net@DOMAIN.NET
login as JDoe
Successful Kerberos connection
Last login: Tue Oct 6 13:49:23 2015 from 10.16.23.51
Have a lot of fun…
jdoe@server2:~>

So when using windows/putty, the camelcase Principal works, which leads me to the suggestion, that the client is the one which is confused by the writing.

But I am not sure how to solve the struggle

Best regards,
themad

arvidjaar · October 9, 2015, 10:15am

What is your Unix user name at this server1?

Then logging in to server 2 with “ssh -K server2 -vvv” fails (last message regarding GSSAPI is “Delegating Credentials”)

And what is your Unix user name on server2?

So when using windows/putty, the camelcase Principal works, which leads me to the suggestion, that the client is the one which is confused by the writing.

That’s possible. It is also possible that you have some mismatch between actual user names.

themad123 · October 9, 2015, 2:19pm

Hello,
both Systems get their namen by the AD via sssd.
When I login locally, it makes no difference if I use Camelcase or lowercase, in both cases the command id shows me lowercase

best regards,
themad

tsu2 · October 9, 2015, 4:45pm

If you suspect your problems are related to unexpected camelcase,
Have you tried simply creating all your account names in lower case?

If this is a possible option, recommend
Create a new account using only lower case for testing. If it resolves your issues, then delete and re-create your Domain User accounts all in lower case.
Unfortunately, simply renaming your accounts won’t likely solve your problem.

TSU

arvidjaar · October 10, 2015, 6:15pm

You could try setting case_sensitive to Preserving in your SSSD AD domain configuration, assuming it is recent enough to support it. Default for AD should be False which makes SSSD convert everything to lower case. If this is not supported, try setting case_sensitive to True.

Of course it may now invalidate quite a lot of configuration, starting with home directory name.

themad123 · October 27, 2015, 9:42am

Well,
I got a account with only lowercase letters, and now it works

I found another issue: in the krb5.conf, I had to add:

ignore_acceptor_hostname = true

ind the [libdefaults] section to use the shorter names.

Now I have to think about how to modify the AD since I dont know with influences this will have on our environment.
We have here 50 admins an me as the only linux admin, so this will be hard I guess

Does anyone know with of the AD attributes has to change (I would suggest Samaccountname or principal name, but not sure)

Best regards,
themad