Martin Forssen wrote:
> First the big issue. After some thinking I have reached the conclusion
> (this is all IMHO of course) that we do not need to try to define some
> generic protocol which can handle all smart-cards biometric devices
> etc. Instead we need a way to let the client and the server load new
> authentication methods dynamically. Therefore we should be able to
> remove everything but the keyboard input type, and thus postponing many
> potential problems (divide and conquer).
I'm in complete agreement with this. Adding generic tty based
authentication support and then forcing the server/client to only
support certain types of non-tty input would be a real shame.
> The imporant thing is to define a common API (perhaps some modfied form
> of PAM) which those methods cna use to connect to ssh.
The approach that we took when making our PAM extension to ssh-1.2
looked a lot like the stuff contained in this draft, so I'm confident
that the eventual form of the draft will be suitable for adding proper
PAM support to ssh.
The non-tty input methods we implemented were via a single 'BINARY'
message type.
Each binary message contained some indication of how the message was to
be used. The typical approach was for the server to send a binary
message ('binary-prompt') requesting that a given flavor of
authentication was initialized, the client would do this if it possessed
the corresponding PAM-agent and subsequent binary-prompts would be
directed to the agent for client side processing and the return of a
corresponding binray-prompt with the processed authentication
information. Not possessing the PAM-agent, the client would so state and
the server would be given the chance to offer some other method. This
approach could be configured from the PAM configuration file (by the
server's sys admin) and it was then possible to dynamically support all
flavors of authentication scheme in a way that the server's admin could
control/combine. (All without recompiling ssh again. :^)
If PAM module/PAM agent combinations had been written, you do things
like this:
1. is the client host trusted to be locally maintained?
Yes: goto 6
2. can client do XXX authentication?
Yes:
they authenticated so grant access
they did not authenticate correctly so permission denied
3. can client do YYY authentication?
Yes:
they authenticated so goto 7
they failed to authenticate so permission denied
4. ask the user if they like s/key?
Yes: try s/key via simple tty exchange)
they authenticated so grant access
they failed to authenticate so permission denied
5. try OPIE (via simple tty exchange)
they authenticated so grant access
they failed to authenticate so permission denied
6. do convenient authentication (something silly like identd)
they authenticated so grant access
they failed to authenticate so permission denied
7. YYY needs to be backed up with the user doing ZZZ too, can the
client support it?
YES:
they authenticated so grant access
they failed to authenticate so permission denied
NO:
the local admin will not trust YYY without ZZZ too: permission
denied.
I'd like to see this sort of authentication prompting supported by the
eventual form of this authentication draft.
The client/server telling all regarding supported methods on the first
exchange, does not gel well with PAM as it is currently implemented. In
this generic authentication environment, I'd be happy to learn why this
is an important requirement.
Cheers
Andrew
