Bug 32387 - Adding description of configuration kbinteractive
Adding description of configuration kbinteractive
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: openssh (Show other bugs)
7.1
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Nalin Dahyabhai
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-03-20 09:10 EST by Henri Schlereth
Modified: 2008-05-01 11:38 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-03-20 09:10:37 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Henri Schlereth 2001-03-20 09:10:34 EST
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.