OpenSSH and

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View
I am running RedHat EL3 with OpenSSH OpenSSH_3.6.1p2.

I have configured the /etc/pam.d/sshd file as follows

    auth    required      debug
    account required
    session required

What I am *expecting* is to be prompted for a password, and then
prompted for some second-factor authentication information, and then
logged in (assuming all authentication information is valid). I used
the same pam configuration for /etc/pam.d/sudo, and it worked exactly
as expected.

But for OpenSSH, this is not what is happening.  When I try to ssh into
the computer, I get

    # ssh tucker@
    tucker@'s password:
    Permission denied, please try again.
    tucker@'s password:

If I look at the /var/log/security file, I find

    Jan 10 11:30:36 dpiems sshd[23804]: pam_radius_auth: Got user name
    Jan 10 11:30:36 dpiems sshd[23804]: pam_radius_auth: Sending RADIUS
request code 1
    Jan 10 11:30:36 dpiems sshd[23804]: pam_radius_auth: DEBUG:
getservbyname(radius, udp) returned 3911708.
    Jan 10 11:30:36 dpiems sshd[23804]: pam_radius_auth: Got RADIUS
response code 11
    Jan 10 11:30:36 dpiems sshd[23804]: pam_radius_auth: Got response to
challenge code 11
    Jan 10 11:30:36 dpiems sshd[23804]: pam_radius_auth: Got response to
challenge code 11
    Jan 10 11:30:36 dpiems sshd[23804]: pam_radius_auth: Got response to
challenge code 3
    Jan 10 11:30:36 dpiems sshd[23804]: pam_radius_auth: authentication
    Jan 10 11:30:36 dpiems sshd[23804]: Failed password for tucker from port 35617 ssh

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.

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 made no difference.  I have pasted
the content of the sshd_config file below, just in case this is useful

#       $OpenBSD: sshd_config,v 1.59 2002/09/25 11:17:16 markus Exp $

# This is the sshd server system-wide configuration file.  See #
sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/local/bin:/bin:/usr/bin

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where #
possible, but leave them commented.  Uncommented options change a #
default value.

#Port 22
Protocol 2
#ListenAddress ::

# HostKey for protocol version 1
#HostKey /etc/ssh/ssh_host_key
# HostKeys for protocol version 2
#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_dsa_key

# Lifetime and size of ephemeral version 1 server key
#KeyRegenerationInterval 3600 #ServerKeyBits 768

# Logging
#obsoletes QuietMode and FascistLogging
#SyslogFacility AUTH
SyslogFacility AUTHPRIV
#LogLevel INFO

# Authentication:

#LoginGraceTime 120
#PermitRootLogin yes
#StrictModes yes

#RSAAuthentication yes
#PubkeyAuthentication yes
#AuthorizedKeysFile     .ssh/authorized_keys

# rhosts authentication should not be used #RhostsAuthentication no #
Don't read the user's ~/.rhosts and ~/.shosts files #IgnoreRhosts yes #
For this to work you will also need host keys in
/etc/ssh/ssh_known_hosts #RhostsRSAAuthentication no # similar for
protocol version 2 #HostbasedAuthentication no # Change to yes if you
don't trust ~/.ssh/known_hosts for # RhostsRSAAuthentication and
HostbasedAuthentication #IgnoreUserKnownHosts no

# To disable tunneled clear text passwords, change to no here!
#PasswordAuthentication no PermitEmptyPasswords no

# Change to no to disable s/key passwords
#ChallengeResponseAuthentication yes

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

#AFSTokenPassing no

# Kerberos TGT Passing only works with the AFS kaserver
#KerberosTgtPassing no

# Set this to 'yes' to enable PAM keyboard-interactive authentication #
Warning: enabling this may bypass the setting of
'PasswordAuthentication' PAMAuthenticationViaKbdInt yes

#X11Forwarding no
X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes
#PrintMotd yes
#PrintLastLog yes
#KeepAlive yes
#UseLogin no
#UsePrivilegeSeparation yes
#PermitUserEnvironment no
#Compression yes

#MaxStartups 10
# no default banner path
Banner /etc/ssh/sshd_banner
#VerifyReverseMapping no
#ShowPatchLevel no
# override default of no subsystems
Subsystem       sftp    /usr/libexec/openssh/sftp-server

Re: OpenSSH and

Quoted text here. Click to load it

That is a pretty ancient version, but it might work...

Quoted text here. Click to load it
Quoted text here. Click to load it

This indicates that password authentication was attempted.

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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).

Quoted text here. Click to load it

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

$ ssh -o PreferredAuthentications=password somehost
per@somehost's password:

$ ssh -o PreferredAuthentications=keyboard-interactive somehost

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

Re: OpenSSH and

Comments in-line below:

Per Hedeland wrote:
Quoted text here. Click to load it
Well, this is the version that came with RH EL3.  We are upgrading to
EL4 soon, maybe I should wait.  Or maybe I should compile my own,
upgraded, version.

Quoted text here. Click to load it

Um, I can't find any post about this from "the other day." Could you be
more specific please (such as a subject line)?

Quoted text here. Click to load it
It made no difference *at all*.

Quoted text here. Click to load it
I will try these variations out tomorrow and report the results.

Thanks for the info

Dave I

Re: OpenSSH and

Quoted text here. Click to load it


Quoted text here. Click to load it

Sorry, it was posted two days before I wrote the above, and the
(inherited) subject line was the rather informative "Re: Difference
between password and keyboard-interactive", so I thought you should
have found it already in the generally-recommended "read before you
post" phase... Anyway, here's a direct link:

--Per Hedeland

Re: OpenSSH and

Per Hedeland wrote:
Quoted text here. Click to load it

How odd.  I did look and found nothing. Thanks for the link.

Anyway, back to the problem at hand.

In my sshd_config file I explicitly set

    PasswordAuthentication no

This made all ssh attempts fail immediately with the message

    Permission denied (publickey,keyboard-interactive).

So I re-commented out the PassworkAuthentication setting (it must
default to yes), and then tried

    ssh -o PreferredAuthentications=keyboard-interactive

This also failed immediately, with the message

    Permission denied (publickey,password,keyboard-interactive).

As for ssh clients, in my above attempts I used the ssh client on the
machine (and just specify localhost as the hostname).  The version as
reported by 'ssh -v' is "OpenSSH_3.6.1p2, SSH protocols 1.5/2.0,
OpenSSL 0x0090701f"

I also tried PuTTY 0.57 and ssh version 4.3p2 from my Ubuntu desktop.
The results do not appear to differ between clients.

Thanks for your help

Dave I

Re: OpenSSH and

Quoted text here. Click to load it

Googlegroups seems to have problems lately - it couldn't find that
article based on Message-ID (the lookup method I typically use), and in
another group in a similar situation, it couldn't find either my article
or the one I had replied to, based on Message-ID *or* Subject line or
anything else - and yet the article I had replied to was actually
*posted* via Google. Though I don't know if the problems affect the
"normal" read/post interfaces, I only ever use the search/lookup stuff.

Quoted text here. Click to load it

It seems to me that your server is offering keyboard-interactive, but
immediately rejects any attempt to use it. In your sshd_config, you had
a commented-out 'ChallengeResponseAuthentication yes' - this would imply
that it's on by default, and it certainly is in current versions, but as
a "just in case" you could try uncommenting it. Though if it was really
set to 'no', sshd shouldn't offer keyboard-interactive at all.

It would of course also be prudent to run sshd with debugging on, to see
if that provides some clues as to why the keyboard-interactive attempts
get rejected. But if it's something other than an obvious
misconfiguration (and I rather doubt that at this point), it won't
really help since no-one will be interested in hunting for bugs in that
old version (well, maybe RH if you have a support contract).

If it still doesn't work, I'd definitely suggest trying a current
version of sshd. You don't have to replace the one you already have,
just download the source tarball from and build it - then
you can run it with a different config file on a different port for

FWIW, I've had great success with pam_radius_auth (somewhat modified,
but not relevant to sshd) and multi-challenge using a more recent
OpenSSH version than yours (don't remember which exactly, but it was a
3.x), on an older Linux (at least I believe RH 7.3 is older than EL 3,
if not it's about the same era).

--Per Hedeland

Re: OpenSSH and

Per Hedeland wrote:
Quoted text here. Click to load it
I had tried that earlier.  It made no difference.  In fact, since
nothing seemed to be making any difference I was starting to worry that
I was editing the wrong config file.  So I added a bogus config
setting, and sshd failed to restart.  So I am working with the correct
config file.

Quoted text here. Click to load it
I contacted RH support already, and they declined to help me since
pam_radius_auth is involved and they don't support pam_radius_auth. My
arguments that pam_radius_auth was incidental to the problem did not
sway them :-(

Quoted text here. Click to load it
We are upgrading to EL 4 within the next year, so I am going to try the
OpenSSH 3.9p1 that ships with EL 4.

Quoted text here. Click to load it
Well I am glad to hear that it *can* work.  Thanks for the inspiration

Dave I

Re: OpenSSH and

Quoted text here. Click to load it
Success! Well, kind of...

I upgraded to RedHat EL4, which comes with OpenSSH 3.9p1, recompiled just in case, and tested again.

The challenge response worked!  The second-factor challenge was
received on the client, and the response was validated at the server.

Unfortunately, once the user was authenticated, he got kicked out
immediately.  The console show the message

    Read from remote host xx.xx.xx.xx: Connection reset by peer
    Connection to xx.xx.xx.xx closed.

So something still is wrong.  I think, however, I am over the pam
authentication hurdle.

If anybody has any suggestions on my latest problem, help would be
greatly appreciated.

Thanks for the help getting this far.

Dave Isaacs

Re: OpenSSH and

Quoted text here. Click to load it


Quoted text here. Click to load it

"The console"? Do you mean that the client displays this message
(presumably wherever you're running it, which just happened to be on the
console)? If so, I think it's likely that the sshd process crashed (not
the main daemon, but (one of) the process(es) forked to handle the
session). In that case, running the server in debug mode, and/or with
core dumps enabled and doing a stack backtrace on the core dump, may
give some clues.

--Per Hedeland

Re: OpenSSH and

Quoted text here. Click to load it
By console, I meant the client.  I should have been more specific.

I tried debug mode for sshd, and found the following in the logs

    debug1: auth2_challenge_start: trying authentication method 'pam'
    Postponed keyboard-interactive for tucker from ::ffff:
port 1195 ssh2
    Postponed keyboard-interactive/pam for tucker from
::ffff: port 1195 ssh2
    debug1: PAM: num PAM env strings 0
    Postponed keyboard-interactive/pam for tucker from
::ffff: port 1195 ssh2
    Accepted keyboard-interactive/pam for tucker from
::ffff: port 1195 ssh2
   debug1: monitor_child_preauth: tucker has been authenticated by
privileged process
    Accepted keyboard-interactive/pam for tucker from
::ffff: port 1195 ssh2
    PAM: pam_open_session(): Authentication service cannot retrieve
authentication info.
    debug1: do_cleanup
    debug1: PAM: cleanup
    debug1: do_cleanup
    debug1: PAM: cleanup

At that point sshd exited (I was running it in the foreground).

This appears to point to a problem in my pam.d/sshd configuration.  If
you recall, my pam.d/sshd file contained

    auth    required      debug
    account required
    session required

I then changed this to be

    auth    required      debug
    auth       required
    account    required service=system-auth
    password   required service=system-auth
    session    required service=system-auth
    session    required

which, except for the line, is what was in the file
before I started messing with it.

My ssh logins are now successful.

I realize this isn't a PAM forum, but I must ask: is this a proper
configuration for my pam/d.ssh file?  One thing I think is wrong (or at
least unnecessary) is the password line, since password management is
now handled by my remote RADIUS server.

Thanks again for all the help!

Dave Isaacs

Site Timeline