I've been beating myself senseless trying to build OpenSsh 3.0.1 on Solaris 2.5.1 and get AFS login working. The symptoms of the problem are: sshd builds (used --with-afs and -with-kerberos4 - there is no PAM on this box), accepts connections from non-AFS users, but does not accept a connection from an AFS user; the user sees "permission denied" after entering the password. The server (in debug mode) at this point says: debug1: attempt 2 failures 2 kerberos-iv/udp unknown service, using default port 750 Kerberos v4 TGT for joeuser unverifiable: Principal unknown (kerberos); rcmd.grimble not registered, or srvtab is wrong? debug1: krb4_cleanup_proc called Failed password for joeuser from 123.45.67.89 port 34375 ssh2 Snooping the network reveals that client machine 'grimble' sends a packet that includes the kerberos realm and "rcmd.grimble' to 'kerberos', our auth server. Server sends response that includes username, part of realm (last component is missing), and text "code = 8: Exec format er" Snooping the network when the old (SSH1) server (which works) runs reveals *no connection* to 'kerberos' over port 750 during successful login... only some stuff on 7004. So I looked at the code, wondering how the ssh1.2.21 could work where this didn't... and found that 1.2.21 used a patch from dugsong that called ka_UserAuthenticateGeneral at this point... but 3.0.2 does not call any ka_ routines. I am suspecting that ka_UserAuthenticateGeneral is what talks over 7004 and that if I could make an equivalent patch to 3.0.2 that would use it, I'd be able to talk to our kaserver. It's been pointed out that if we created a principal rcmd.grimble I might be able to use what I've got, but I don't want to do anything that requires an admin. Which is the same answer to the suggestions that we're running an out-of-date kaserver. I am not the cell admin. I want 3.0.2 to work on AFS the way 1.2.21 did. I tried a naive patch to 3.0.2 to use ka_UserAuthenticateGeneral and I couldn't even get it to link; usually I eventually figure out an order of all those wretched AFS libraries that works but not this time. Why doesn't 3.0.2 call ka_UserAuthenticateGeneral? Is there a patch to make it do so? -- Peter Scott Peter.J.Scott at jpl.nasa.gov
On Fri, 4 Jan 2002, Peter Scott wrote:> I've been beating myself senseless trying to build OpenSsh 3.0.1 on Solaris > 2.5.1 and get AFS login working. > > The symptoms of the problem are: sshd builds (used --with-afs and > -with-kerberos4 - there is no PAM on this box), accepts connections from > non-AFS users, but does not accept a connection from an AFS user; the user > sees "permission denied" after entering the password. > > The server (in debug mode) at this point says: > debug1: attempt 2 failures 2 > kerberos-iv/udp unknown service, using default port 750 > Kerberos v4 TGT for joeuser unverifiable: Principal unknown > (kerberos); rcmd.grimble not registered, or srvtab is wrong? > debug1: krb4_cleanup_proc called > Failed password for joeuser from 123.45.67.89 port 34375 ssh2 >- You need a srvtab for your machine to accept kerberos 4 logins. Accepting logins without verifying them against a srvtab is not considered acceptable security practice by most people.> > > I am suspecting that ka_UserAuthenticateGeneral is what talks over 7004 and > that if I could make an equivalent patch to 3.0.2 that would use it, I'd be > able to talk to our kaserver. It's been pointed out that if we created a > principal rcmd.grimble I might be able to use what I've got, but I don't > want to do anything that requires an admin. Which is the same answer to > the suggestions that we're running an out-of-date kaserver. I am not the > cell admin. I want 3.0.2 to work on AFS the way 1.2.21 did.- Then you should use 1.2.21. IMHO 3.0.2 is doing things the correct way and 1.2.21 did them the wrong way.> > I tried a naive patch to 3.0.2 to use ka_UserAuthenticateGeneral and I > couldn't even get it to link; usually I eventually figure out an order of > all those wretched AFS libraries that works but not this time. > > Why doesn't 3.0.2 call ka_UserAuthenticateGeneral?- Because it's insecure?> Is there a patch to make it do so?- It's wildly insecure in my humble opinion, but there was a post on this list last month to allow kerberos 4 logins without access to a srvtab. You are leaving your machines wide open to anybody that can inject packets into your local network. It's pretty much the equivalent of using hosts.allow with old versions of rsh. (i.e. you're trusting the ip address in the packet as sufficient authentication. ) - Look for a message with the subject PATCH: Kerberos password authentication w/o KDC verification - It was posted to the list in early December 2001. You might want to read Dug Song's current opinion on how kerberos logins should work. http://www.monkey.org/~dugsong/kdcspoof.tar.gz - Booker C. Bense
At 01:27 PM 1/4/02 -0800, Booker C. Bense wrote:> > The server (in debug mode) at this point says: > > debug1: attempt 2 failures 2 > > kerberos-iv/udp unknown service, using default port 750 > > Kerberos v4 TGT for joeuser unverifiable: Principal unknown > > (kerberos); rcmd.grimble not registered, or srvtab is wrong? > > debug1: krb4_cleanup_proc called > > Failed password for joeuser from 123.45.67.89 port 34375 ssh2 > >- You need a srvtab for your machine to accept kerberos 4 logins. >Accepting logins without verifying them against a srvtab is not >considered acceptable security practice by most people. > > > I am suspecting that ka_UserAuthenticateGeneral is what talks over 7004 and > > that if I could make an equivalent patch to 3.0.2 that would use it, I'd be > > able to talk to our kaserver. [snip] > > I tried a naive patch to 3.0.2 to use ka_UserAuthenticateGeneral and I > > couldn't even get it to link; usually I eventually figure out an order of > > all those wretched AFS libraries that works but not this time. > > > > Why doesn't 3.0.2 call ka_UserAuthenticateGeneral? > >- Because it's insecure?Thanks for this information. I've read the thread and URL you provided. If you don't mind what may be a stupid question - does this imply that the stock AFS login - or at least the Transarc one we are using - is insecure? Because all it has to go on is a username and password, and we already know that the kaservers don't have a srvtab for the client machine. If it isn't insecure, what makes it secure? I looked in OpenAFS source and if I'm looking at the right place, the login does call ka_UserAuthenticateGeneral... and without a srvtab for the client how can that be good enough? -- Peter Scott Peter.J.Scott at jpl.nasa.gov