Re: pam/sshd question: allowing a user to try logging in more than once
Michael Sims wrote:
Jeremy Brown wrote:
Debian:
Permission denied (publickey,keyboard-interactive).
Fedora:
Permission denied (publickey,password,keyboard-interactive).
Perhaps getting PAM to spit out this extra data would be more, eh,
amiable to PuTTY?
That's some good info. I noticed that if I set "PasswordAuthentication" to "yes",
and leave "UsePAM" as "yes", this is what I get:
Using username "michaels".
Password:
Access denied
michaels@gnu3.crye-leike.com's password:
Access denied
Password:
Access denied
michaels@gnu3.crye-leike.com's password:
Access denied
Password:
So, it actually prompts me 5 times. What's odd is that the first style of prompt,
simply "Password:", pauses after I hit enter...while the second one,
"michaels@gnu3.crye-leike.com's password:", immediately returns.
This may be good enough of a solution for you...it appears to be still using PAM,
although I'm not sure because my test box is still using /etc/passwd, and it prompts
more than once. It still bugs me that the output is different from my Red Hat
boxes.
I get the feeling that if either of us could spend a couple of solid hours reading
PAM and SSH docs we'd figure it out. To me, it hasn't been critical enough to
warrant that (yet). :)
OK. This is starting to make a little more sense.
I'm going to go ahead and bring debian-user back into the mix, for
feedback and progeny's sake (no pun intended).
Apparently OpenSSH has two authentication "modules", a "Password"
authentication module (which works with "/etc/passwd"), and a "PAM"
authentication module. You can set "PasswordAuthentication" and
"UsePAM" both to "yes", but if you do so you'll get two prompts (kind of
like what happens when you list two auth modules in a PAM file without
"use_first_pass"). One will be the PAM prompt:
Password:
and one will be the /etc/passwd authentication prompt:
michaels@gnu3.crye-leike.com's password:
This may work for you, if your box stores passwords in "/etc/passwd",
but it won't for me, because my box authenticates against an LDAP server
*and* /etc/password (for root and system-specific users). My LDAP
logins will work for the first prompt, but fail for the second.
Additionally, sshd has (at least) 3 ways it can obtain authentication
information from a client: publickey, password, and
keyboard-interactive. With "password" authentication, I believe the
client generates an appropriate prompt and passes the password back to
the sshd server. In the case of "keyboard-interactive", I believe the
server generates the prompt and communicates directly with the client
even before authentication has been completed (kind of like telnet). I
believe "password" here is distinctly different from
"PasswordAuthentication" in the sshd config file, which I think is
referring to using the file "/etc/passwd" as an authentication mechanism
itself (for systems that don't want or need PAM).
Now:
My PAM knowledge is a little hazy, but my rough understanding is that
one popular usage model for PAM authentication is as follows: an
authenticating application retrieves the username itself, then is
supposed to pass input/output file descriptors to PAM. PAM then uses
these to print the password string (in this case, "Password:") and read
the result. It then returns a success or failure code to the
authenticating application.
Apparently earlier versions of OpenSSH contained a
"PAMAuthenticationViaKbdInt" option which allowed you to specify whether
you would prefer PAM talk to the user itself or you would rather have
OpenSSH obtain the user's password directly (via "password"
authentication as opposed to "keyboard-interactive"), then send this
password to PAM. See this debian-security post for a better explanation
than I can give:
http://www.mail-archive.com/debian-security@lists.debian.org/msg06881.html
I tried putting this option in my "/etc/ssh/sshd_config" but got a "this
option has been deprecated" message when I tried to start up sshd. I
looked through the sshd_config man page but couldn't find any mention of
a new, equivalent option. Additionally, a Google search for "PAM
AuthenticationViaKbdInt" turned up mention of some security problems, so
I'm guessing that the OpenSSH team may have decided that it's just
better to let PAM modules "do the talking" (as it were) in all cases
where PAM authentication is necessary.
So, I think the Debian box is using keyboard-interactive to obtain
passwords (the model I described above), whereas the Fedora box is using
password to obtain them. This might also explain why when
authentication fails, the Debian box only returns:
Permission denied (publickey,keyboard-interactive)
while the Fedora box lists password authentication (not to be confused
with the "PasswordAuthentication" setting):
Permission denied (publickey,password,keyboard-interactive)
I got curious, so I physically walked up to both machines and logged in
at the console. Both machines gave me a "Password:" prompt (I think it
comes directly from PAM), which I believe confirms my suspicion: the
Fedora sshd is collecting your password, then passing it to PAM, whereas
the Debian sshd is letting PAM talk to the client directly.
This doesn't solve my immediate problem, which I am growing more
inclined to believe is a bug in PuTTY (a mishandling of
keyboard-interactive authentication). My only other guess is that on
authentication failure, PAM may be writing some control character that
PuTTY can't deal with.
Maybe someone on comp.security.ssh would have an answer?
I can try. Is comp.security.ssh more general ssh questions, or mostly
OpenSSH-specific? If the former (and no one on debian-user has an
answer), I'm more inclined to move this to OpenSSH, PAM, or PuTTY
user/developer lists.
Well, the reason I recommended that is because there is no PuTTY mailing list. From
the FAQ:
<quote>
A.9.6 If putty-bugs isn't a general-subscription mailing list, what is?
There isn't one, that we know of.
If someone else wants to set up a mailing list or other forum for PuTTY users to
help each other with common problems, that would be fine with us, though the PuTTY
team would almost certainly not have the time to read it. It's probably better to
use the established newsgroup comp.security.ssh for this purpose
</quote>
If I understand correctly though, I could still report this as a bug via
putty-bugs; it's just that I won't be involved in any developer
discussion about the bug.
Thanks for the help. I think I will send this over to putty-bugs in a
few, and if I don't get any response there, I'll probably just stop
worrying about it and use the Cygwin port of OpenSSH more :)
Jeremy
Reply to: