[355] in athena10
Re: update_server and remote access
daemon@ATHENA.MIT.EDU (Jonathan Reed)
Fri Aug 1 12:25:57 2008
Cc: Timothy G Abbott <tabbott@mit.edu>, athena10@mit.edu
Message-Id: <06E8DBF5-504A-4D01-8FEC-EB19FDE168DB@mit.edu>
From: Jonathan Reed <jdreed@MIT.EDU>
To: Quentin Smith <quentin@mit.edu>
In-Reply-To: <Pine.LNX.4.64L.0808011219100.11949@vinegar-pot.mit.edu>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v919.2)
Date: Fri, 1 Aug 2008 12:25:10 -0400
"PasswordAuthentication" is set to "no".
And anyway, it is accepted my Kerberos password at the first prompt.
It's just weird that if I hit enter at the Password prompt (supplying
a null password, essentially), the next prompt is for my kerberos
principal.
Most users are unlikely to encounter this, so if it's a known bug that
will eventually get fixed, then that's fine.
-Jon
On Aug 1, 2008, at 12:19 PM, Quentin Smith wrote:
> Is it possible that the ssh server has "PasswordAuthentication yes",
> so the SSH server is first prompting for a password, and then
> falling through to PAM authentication?
>
> --Quentin
>
> On Fri, 1 Aug 2008, Timothy G Abbott wrote:
>
>> On Fri, 1 Aug 2008, Jonathan Reed wrote:
>>
>>> - When I ssh to an Athena 10 machine, ssh first prompts for
>>> "Password:". If I (accidentally, for example) simply hit Return,
>>> it then prompts for "Password for jdreed@ATHENA.MIT.EDU:"
>>> Presumably that's a result of PAM stacking, but it's a weird and
>>> potentially confusing behavior, especially since the first prompt
>>> will happily accept the user's Kerberos password. It's a minor
>>> thing, but is there any way around that?
>>
>> The use_first_pass option to pam_krb5 (which we use) is supposed to
>> do this (see pam_krb5(5) for details), but it does seem it behaves
>> as desired.
>>
>> -Tim Abbott
>>
>>
>>