Bug 32387 - Adding description of configuration kbinteractive
Summary: Adding description of configuration kbinteractive
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: openssh
Version: 7.1
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Nalin Dahyabhai
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2001-03-20 14:10 UTC by Henri Schlereth
Modified: 2008-05-01 15:38 UTC (History)
0 users

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2001-03-20 14:10:37 UTC
Embargoed:


Attachments (Terms of Use)

Description Henri Schlereth 2001-03-20 14:10:34 UTC
While researching a syslog message from sshd 

Failed keyboard-interactive for henris

I noticed that while the open was set there was no explanation of it's usage.

Below is Nalin excellent description. Something like this should be added to the
man pages of ssh.

"The keyboard-interactive method is one of the methods which the SSH2
protocol supports for authenticating users, and can be a big win on
a system which uses PAM.

SSH1 (and SSH2's password authentication) is implemented by having the
client send the user's name and password over the encrypted channel to
the server.  When doing this on a system with PAM, sshd assumes that
all queries from the PAM library and modules for data which should be
echoed to the screen should be answered with the user's name, and data
which shouldn't be echoed to the screen is a request for the user's
password.

If you need more than one password (say, if you want to require multiple
kinds of authentication, like S/Key *and* password-based auth, or
even S/Key with both MD4 and MD5 (yikes!)), this breaks horribly.


for information to the client, which then prompts the user for it and
relays it back to the server.  This method lends itself pretty well to
letting you do full PAM-style conversations, and the above examples
will work if you use it.  But here's the rub: both the client and the
server need to have support for it, and both have to enable it.  It's
also currently only a draft standard, but it's a pretty good one.
The keyboard-interactive protocol allows the server to send a request
for information to the client, which then prompts the user for it and
for information to the client, which then prompts the user for it and
relays it back to the server.  This method lends itself pretty well to
letting you do full PAM-style conversations, and the above examples
will work if you use it.  But here's the rub: both the client and the
server need to have support for it, and both have to enable it.  It's
also currently only a draft standard, but it's a pretty good one.

The current support for challenge-response authentication is implemented
via keyboard-interactive, so switching on challenge-response has the
same effect, but challenge-response also enables support for the BSD_AUTH
functionality (which won't build under Linux)."


Note You need to log in before you can comment on or make changes to this bug.