In article <1168545415.674920.181610@i39g2000hsf.googlegroups. com> "Dave
Isaacs" 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
>the computer, I get
>
> # ssh tucker@10.4.148.25
> tucker@10.4.148.25's password:
> Permission denied, please try again.
> tucker@10.4.148.25's password:
>
>If I look at the /var/log/security file, I find
[snip]
> 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@hedeland.org

Comments in-line below:

Per Hedeland wrote:
> In article <1168545415.674920.181610@i39g2000hsf.googlegroups. com> "Dave
> Isaacs" writes:
> >I am running RedHat EL3 with OpenSSH OpenSSH_3.6.1p2.
>
> That is a pretty ancient version, but it might work...
>
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.

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

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

>
> > 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:
>
It made no difference *at all*.

> $ ssh -o PreferredAuthentications=password somehost
> per@somehost's password:
>
> $ ssh -o PreferredAuthentications=keyboard-interactive somehost
> Password:
>
I will try these variations out tomorrow and report the results.

Thanks for the info

Dave I

In article <1168573788.364355.262280@38g2000cwa.googlegroups.c om> "Dave
Isaacs" writes:
>
>Comments in-line below:

Thanks.:-)

>Per Hedeland wrote:
>>
>> 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.
>>
>
>Um, I can't find any post about this from "the other day." Could you be
>more specific please (such as a subject line)?

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:

http://groups.google.com/group/comp....8e9cf45949a6f1

--Per Hedeland
per@hedeland.org

Per Hedeland wrote:
> >
> >Um, I can't find any post about this from "the other day." Could you be
> >more specific please (such as a subject line)?
>
> 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:
>
> http://groups.google.com/group/comp....8e9cf45949a6f1
>

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
tucker@localhost

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

In article <1168613239.137410.216370@v45g2000cwv.googlegroups. com> "Dave
Isaacs" writes:
>
>Per Hedeland wrote:
>>
>> http://groups.google.com/group/comp....8e9cf45949a6f1
>>
>
>How odd. I did look and found nothing. Thanks for the link.

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.

>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
>tucker@localhost
>
>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.

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 openssh.org and build it - then
you can run it with a different config file on a different port for
testing.

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
per@hedeland.org

Per Hedeland wrote:
> In article <1168613239.137410.216370@v45g2000cwv.googlegroups. com> "Dave
> Isaacs" writes:
> >
> >Per Hedeland wrote:
> >>
> 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.
>
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.

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

> 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 openssh.org and build it - then
> you can run it with a different config file on a different port for
> testing.
>
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.

> 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).
>
Well I am glad to hear that it *can* work. Thanks for the inspiration
;-)

Dave I

sword:
> >
> I will try these variations out tomorrow and report the results.
>
Success! Well, kind of...

I upgraded to RedHat EL4, which comes with OpenSSH 3.9p1, recompiled
pam_radius_auth.so 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

In article <1168897289.689701.187330@a75g2000cwd.googlegroups. com> "Dave
Isaacs" writes:
>
>I upgraded to RedHat EL4, which comes with OpenSSH 3.9p1, recompiled
>pam_radius_auth.so 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.

Great!:-)

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

"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
per@hedeland.org

>
> "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.
>
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:10.4.148.59
port 1195 ssh2
Postponed keyboard-interactive/pam for tucker from
::ffff:10.4.148.59 port 1195 ssh2
debug1: PAM: num PAM env strings 0
Postponed keyboard-interactive/pam for tucker from
::ffff:10.4.148.59 port 1195 ssh2
Accepted keyboard-interactive/pam for tucker from
::ffff:10.4.148.59 port 1195 ssh2
debug1: monitor_child_preauth: tucker has been authenticated by
privileged process
Accepted keyboard-interactive/pam for tucker from
::ffff:10.4.148.59 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

#%PAM-1.0
auth required pam_radius_auth.so debug
account required pam_radius_auth.so
session required pam_radius_auth.so

I then changed this to be

#%PAM-1.0
auth required pam_radius_auth.so debug
auth required pam_nologin.so
account required pam_stack.so service=system-auth
password required pam_stack.so service=system-auth
session required pam_stack.so service=system-auth
session required pam_loginuid.so

which, except for the pam_radius_auth.so 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