Has anyone been able to get SSH to ‘fully’ work for network users?

This topic has 5 replies, 1 voice, and was last updated 18 years, 1 month ago by tegtmeye.

Viewing 6 posts - 1 through 6 (of 6 total)

Author

Posts

October 1, 2008 at 2:27 pm #374308

Participant

I say fully work because getting SSH to just authenticate seems pretty easy but once authenticated, network users don’t have a Kerberos ticket and are unable to get one.

‘macserver’ with ‘macclient’ bound to ‘macserver’. Kerberos realm ‘FOO.EXAMPLE.COM’
Opendirectory user ‘macuser’ on ODM ‘macserver’
‘linuxmachine’ in its own linuxland, maybe kerberized to some other realm, maybe not.
‘linuxmachine’ user ‘foouser’

linuxmachine:~ foouser$ ssh macuser@macclient
linuxmachine:~ foouser$ password: ****
macclient:~ macuser$ klist
Operation not permitted while initializing Kerberos 5
macclient:~ macuser$ kinit
kinit: Unable to create principal for current user: Operation not permitted
kinit: Error getting initial tickets: Operation not permitted

Anyone?

Mike Tegtmeyer

October 1, 2008 at 5:41 pm #374313

tegtmeye

Participant

You actually mounting a homefolder?

Trying to. Seems any file sharing protocol that requires a ticket screws everything. For example:

Setting macuser’s home folder to none or (NFS with standard auth for example) Works fine.

eg with home dir set to none

clutch:~ arl_admin$ ssh tegtmeye@clutch
Password:
Last login: Wed Oct  1 13:24:01 2008 from example.com
Could not chdir to home directory 99: No such file or directory
clutch:/ tegtmeye$ klist
klist: No Kerberos 5 tickets in credentials cache
clutch:/ tegtmeye$ kinit
2008-10-01 13:30:22.329 kinit[813:10b] CFPreferences: user home directory at /99 is unavailable. User domains will be volatile.
Please enter the password for tegtmeye@EXAMPLE.COM:

Now set home dir to kererized NFS or AFP with guest access turned off. Here AFP no guest, no other changes:

clutch:~ arl_admin$ ssh tegtmeye@clutch
Password:
Last login: Wed Oct  1 13:30:17 2008 from example.com
Could not chdir to home directory /Network/Servers/foo.com/Users/tegtmeye: Unknown error: 118
-bash: /Network/Servers/foo.comUsers/tegtmeye/.bash_profile: Unknown error: 118
clutch:/ tegtmeye$ klist
Unknown Error Code: 118 while initializing Kerberos 5
clutch:/ tegtmeye$ kinit
kinit: Unable to create principal for current user: Unknown Error Code: 118
kinit: Error getting initial tickets: Operation not permitted

secure.log says:

Oct  1 13:35:27 clutch com.apple.SecurityServer[36]: checkpw() succeeded, creating credential for user tegtmeye
Oct  1 13:35:27 clutch com.apple.SecurityServer[36]: checkpw() succeeded, creating shared credential for user tegtmeye
Oct  1 13:35:27 clutch authorizationhost[922]: k5_store_ticket_in_cache(): got -1765328188 (Internal credentials cache error) on plugins/krb5/krb5_operations.c:83
Oct  1 13:35:27 clutch com.apple.SecurityServer[36]: Succeeded authorizing right system.login.tty by client /usr/sbin/sshd for authorization created by /usr/sbin/sshd.
Oct  1 13:35:27 clutch sshd[916]: Accepted keyboard-interactive/pam for tegtmeye from 123.456.789.123 port 50055 ssh2

for nfs, things get even worse. system.log says:

Oct  1 09:13:28 clutch gssd[2539]: Error returned by svc_mach_gss_init_sec_context:
Oct  1 09:13:28 clutch gssd[2539]:      Major error <1> Unspecified GSS failure.
  Minor code may provide more information
Oct  1 09:13:28 clutch gssd[2539]:      Minor error <1> Unknown Error Code: 19777
Oct  1 09:13:28 clutch gssd[2539]: nfs client Kerberos: exampe.com:/Users, uid=0 - Unknown Error Code: 19777

October 1, 2008 at 6:33 pm #374315

tegtmeye

Participant

Getting the ticket beforehand doesn’t work either.

Also, it was my understanding that ticket caches were in memory now for security reasons (CCacheServer) but between your post and googling around just now I’m not so sure anymore: From MIT Mac Kerberos: http://mailman.mit.edu/pipermail/kerberos/2008-January/012880.html

But looking in a user’s home folder who does have tickets, I find nothing that remotely looks like a ticket cache, Also, inspecting Kerberos.app with valid tickets shows me suspicious things like

/private/var/folders/+Q/+Q8xCPFMFRmVtQkuDhIMck+++TI/-Caches-/com.apple.IntlDataCache.le.sbdl
/private/var/folders/+Q/+Q8xCPFMFRmVtQkuDhIMck+++TI/-Caches-/com.apple.ATS/annex_aux

Which a random user would not be able to write to if they were logged on some random machine (or maybe this is done as root?)

In any case, this seems to open up a pretty big security hole if you have to mount your home folders with pretty limited security enabled.

I’ve looked around on the web pretty extensively regarding this and haven’t found much. I’m wondering what is the “best practice” setup for large enterprise setups who have users who are married to the command line across multiple machines? Surely it can’t be vanilla NFS?

Thanks,
Mike

October 1, 2008 at 8:56 pm #374318

tegtmeye

Participant

OK I’ve managed to make some headway, but not much.

I’m still not convinced that the kerberos ccache is not an in memory one. There are plenty of hits on google for “in memory cache kerberos mac” but admittedly none authoritative.

In any case, some testing leads me to the following: I can get tickets to forward one hop and one hop only and I’m suspicious that the underlying problem is still the credential cache on the receiving machine.

Stock setup with network user gives me:

clutch:~ arl_admin$ ssh tegtmeye@clutch
Password:
Last login: Wed Oct  1 16:03:48 2008 from foo.com
clutch:~ tegtmeye$ klist
klist: No Kerberos 5 tickets in credentials cache
clutch:~ tegtmeye$

Attempting to log into another machine in the same realm asks me for my password. Reading http://trs-new.jpl.nasa.gov/dspace/bitstream/2014/39809/1/06-1646%20.pdf and knowing that logging into ssh requires the system.login.tty right, I try adding builtin:krb5login,privileged to system.login.tty (stock apple sshd_conf)

                <key>system.login.tty</key>
                <dict>
                        <key>class</key>
                        <string>evaluate-mechanisms</string>
                        <key>mechanisms</key>
                        <array>
                                <string>push_hints_to_context</string>
                                <string>authinternal</string>
                                <string>builtin:krb5login,privileged</string>
                        </array>
                        <key>tries</key>
                        <integer>1</integer>
                </dict>

Which properly forwards my tickets (at least once)

clutch:~ arl_admin$ ssh tegtmeye@clutch
Password:
Last login: Wed Oct  1 16:11:50 2008 from foo.com
clutch:~ tegtmeye$ klist
Kerberos 5 ticket cache: 'API:Initial default ccache'
Default principal: tegtmeye@FOO.COM

Valid Starting     Expires            Service Principal
10/01/08 15:46:56  10/02/08 01:46:56  krbtgt/FOO.COM@FOO.COM
	renew until 10/08/08 15:46:56
10/01/08 15:47:12  10/02/08 01:46:56  host/FOO.COM@FOO.COM
	renew until 10/08/08 15:46:56

I’m in! However, I notice in secure.log the error message:

Oct  1 16:22:21 clutch authorizationhost[9758]:
  k5_store_ticket_in_cache(): got -1765328188 (Internal credentials cache error)
    on plugins/krb5/krb5_operations.c:83

Trying to go somewhere else via sso (GSSAPI enabled), doesn’t help but at least I didn’t have to put in my password! It appears that ssh via sso doesn’t require system.login.tty right. I’m not sure what is right it does require though and how ultimately the new user is getting set.

clutch:~ arl_admin$ ssh tegtmeye@clutch
Password:
Last login: Wed Oct  1 16:35:26 2008 from foo.com
clutch:~ tegtmeye$ klist
Kerberos 5 ticket cache: 'API:Initial default ccache'
Default principal: tegtmeye@FOO.COM

Valid Starting     Expires            Service Principal
10/01/08 15:46:56  10/02/08 01:46:56  krbtgt/FOO.COM@FOO.COM
	renew until 10/08/08 15:46:56
10/01/08 15:47:12  10/02/08 01:46:56  host/foo.com@FOO.COM
	renew until 10/08/08 15:46:56

clutch:~ tegtmeye$ ssh pawl
Password:
Last login: Wed Oct  1 16:36:29 2008 from foo.com
pawl:~ tegtmeye$ klist
klist: No Kerberos 5 tickets in credentials cache
pawl:~ tegtmeye$

Notice secure.log in the second hop machine (/etc/authorization configured the same, all GSSAPI options enabled in sshd_config):

Oct  1 16:26:55 pawl sshd[2098]: Authorized to tegtmeye, krb5 principal tegtmeye@FOO.COM (krb5_kuserok)
Oct  1 16:26:55 pawl sshd[2098]: Accepted gssapi-with-mic for tegtmeye from 123.456.789.123 port 53471 ssh2
Oct  1 16:26:55 pawl sshd[2098]: krb5_cc_initialize(): Internal credentials cache error

So the punch-line is that at this point if you add builtin:krb5login,privileged to system.login.tty you can at least partially keep your tickets giving you a one hop sso experience via ssh. Still can’t havin any ticket-relying network home directory as far as I can tell though.

Mike

October 1, 2008 at 9:00 pm #374319

tegtmeye

Participant

MacTroll wrote:

So when you say it doesn’t work from the Linux box when you get the ticket there first… does that mean that SSH doesn’t auth? Or you get in via kerb ssh but don’t get your home?

Sorry, messages crossed.

No matter where I got the initial ticket (via kinit), I can log in but I do not retain the ticket. ie (prior to my previous post)

kinit on machine A (Linux)
login to machine B (Mac) ticket accepted, no password
klist on machine B says I have no tickets

October 3, 2008 at 3:11 pm #374360

tegtmeye

Participant

MacTroll wrote:

Let me see if I can replicate that…

Any luck? Is this a configuration problem that I am not aware of or is it truly a bug ?

Mike

Author

Posts

Viewing 6 posts - 1 through 6 (of 6 total)

You must be logged in to reply to this topic.