SCIENTIFIC-LINUX-USERS Archives

August 2008

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Wayne Betts <[log in to unmask]>
Reply To:
Wayne Betts <[log in to unmask]>
Date:
Fri, 22 Aug 2008 16:20:33 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (102 lines)
Troy Dawson wrote:
> Wayne Betts wrote:
>> I inadvertently had sl-contrib enabled on an SL4.6 system and this 
>> morning it updated openssh,
>> openssh-server, etc, getting them from sl-contrib.  For instance:
>>
>> openssh-server-3.9p1-22.SL.4.22.i386
>>
>> According to the changelog, the changes appear to only include some 
>> bug fixes compared to the
>> "stock" SL version (3.9p1-8).  But upon logging in, it now tries 
>> (unsuccessfully) to get an AFS
>> token with the aklog command, which I'd rather it not do.  I don't see 
>> any reason for this in the
>> sshd_config, which matches a box with the 3.9p1-8 version.  
>> Specifically, all the Kerberos options
>> are commented out:
>>
>> # Kerberos options
>> #KerberosAuthentication no
>> #KerberosOrLocalPasswd yes
>> #KerberosTicketCleanup yes
>> #KerberosGetAFSToken no
>>
>>
>> Could the package in sl-contrib be a build for SLF instead of an SL 
>> build or possibly have some
>> remnant(s) of the changes for SLF/LTS?
>>
>> I know I can downgrade to the non-contrib version, but am wondering if 
>> this might be a small oops in
>> the contrib section?  Or perhaps I don't understand the contrib 
>> section's purpose.  Then again,
>> perhaps all of this will clear up with the openssh updates due out 
>> later today for other reasons.
>>
>> -Wayne
> 
> Hi Wayne,
> This is not an oops, it is on purpose.
>  From the README in that directory
> 
> "These versions of openssh have been patched to be able to use
> both the old and the new versions of gssapi.  This allows them
> to do kerberos authentication with both kerberized openssh before
> openssh 3.9, and after openssh 3.9"
> 
> But we do not have the openssh server configured so that it does 
> kerberos only, like we do in SLF's version of openssh-server.
> Why?
> Well, if we did, you'd be worrying alot more than just having it do 
> aklog when you log in.  You wouldn't be able to log in any other way 
> than kerberos.  And I don't think you want that.
> So we have it configured to have the same settings that you get with the 
> regular openssh-server that you get from RedHat.
> 



Thanks for the response Troy, but I'll have to put on the SL dunce hat and sit in a corner for a 
while, because I've searched in vain for the README or directory you're referring to.

Obviously it doesn't do only Kerberos authentication, since I was able to log in but still I'm 
confused...

You say it matches the Redhat settings, yet the aklog never happens on my genuine Redhat servers 
which have the same GSSAPI and Kerberos options in their sshd_config files:


# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no

# GSSAPI options
#GSSAPIAuthentication no
GSSAPIAuthentication yes
#GSSAPICleanupCredentials yes
GSSAPICleanupCredentials yes

I also tried uncommenting the "KerberosAuthentication no" and "KerberosGetAFSToken no" lines to be 
explicit, but it claims KerberosGetAFSToken is an unsupported option and still tried to aklog, so 
I'm further confused.  I also tried explicitly setting "GSSAPIAuthentication no", but same thing.

I'll keep wearing the dunce hat until a patient teacher educates me... :-)


-Wayne


> Most people who use this version of openssh are really more concerned 
> with having a openssh client, not the server, that does both the old and 
> new kerberos.
> 
> Anyway ... the real problem is that annoying message about doing aklog 
> when you log in isn't it?
> I remember another lab having that problem and we fixed it for them ... 
> I think.  It might have been changing the aklog stuff in /etc/krb5.conf 
> ... but let me check.
> Troy

ATOM RSS1 RSS2