Re: OpenSSH and pam_radius_auth.so
- From: per@xxxxxxxxxxxx (Per Hedeland)
- Date: Thu, 11 Jan 2007 20:56:00 +0000 (UTC)
In article <1168545415.674920.181610@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> "Dave
Isaacs" <dave.isaacs@xxxxxxxxx> writes:
I am running RedHat EL3 with OpenSSH OpenSSH_3.6.1p2.
That is a pretty ancient version, but it might work...
But for OpenSSH, this is not what is happening. When I try to ssh into[snip]
the computer, I get
# ssh tucker@xxxxxxxxxxx
tucker@xxxxxxxxxxx's password:
Permission denied, please try again.
tucker@xxxxxxxxxxx's password:
If I look at the /var/log/security file, I find
Jan 10 11:30:36 dpiems sshd[23804]: Failed password for tucker from
10.4.148.25 port 35617 ssh ^^^^^^^^
This indicates that password authentication was attempted.
By looking at the logs on my RADIUS server, I can see that the password
is being successfully authenticated, and then a second-factor challenge
is being sent. It appears as if sshd is (1) not displaying the second
factor authentication to the user, and (2) responding to the challenge
with some other piece of information. This of course fails, and the
RADIUS server tries again 2 more times before giving up.
Right, see my post the other day about the difference between password
and keyboard-interactive authentication, and how sshd tries to map the
non-interactiveness of password to the interactiveness of PAM.
I then discovered the PAMAuthenticationViaKbdInt entry in the
sshd_config file, and set it to yes (it was commented out previously)
and restarted the sshd service.
This option doesn't exist in current versions (probably replaced by the
combination of ChallengeResponseAuthentication and UsePAM), but you will
most likely need it on. However as a general principle (and mentioned at
the top of your file), as shipped the OpenSSH config files have the
default settings, but commented out - i.e. uncommenting an option
without changing it should be a no-op. If in doubt, consult the man page
(and hope that your Linux distributor hasn't changed the code w/o
changing the man page, which unfortunately is common among them).
This made no difference.
If it made no difference *at all*, i.e. the log still says "Failed
password", the most likely problem is that your SSH *client* isn't
*attempting* keyboard-interactive authentication. The server can't force
it to... The format of the prompt above is another hint in that
direction:
$ ssh -o PreferredAuthentications=password somehost
per@somehost's password:
$ ssh -o PreferredAuthentications=keyboard-interactive somehost
Password:
If your OpenSSH client is as old as the server, I'm not sure if it has
the PreferredAuthentications option, otherwise you can obviously try the
second variant above - and then update your ssh_config or
~/.ssh/config. Another possibility may be to disallow password
authentication on the server - your sshd_config seems to indicate that
PasswordAuthentication has the default value of 'no', but it's pretty
mangled by your news-posting program, and the comment above it doesn't
make sense - plus of course all the evidence from your failed attempts
indicate that it is *not* disabled.
--Per Hedeland
per@xxxxxxxxxxxx
.
- Follow-Ups:
- Re: OpenSSH and pam_radius_auth.so
- From: Dave Isaacs
- Re: OpenSSH and pam_radius_auth.so
- References:
- OpenSSH and pam_radius_auth.so
- From: Dave Isaacs
- OpenSSH and pam_radius_auth.so
- Prev by Date: OpenSSH and pam_radius_auth.so
- Next by Date: Re: PuTTY + cluster + server fingerprints
- Previous by thread: OpenSSH and pam_radius_auth.so
- Next by thread: Re: OpenSSH and pam_radius_auth.so
- Index(es):
Relevant Pages
|