I've been trying to establish the following setup:
* on port 22, a vanilla sshd that allows publickey and
keyboard-interactive requests using only protocol v2
* on port 1022, a sshd that allows publickey, password and
keyboard-interactive requests using both protocol 1 and 2
The first is meant to be open to the world, the second is accessible only
from within the (firewalled) private network. The reason for that is that
I'd like to have a means of relatively secure outside access for which
the -- possibly insecure -- reusable passwords do not suffice.
I wanted to start teaching my users to use publickey authentication, with
encrypted keys. A first transfer could then be acomplished with a session
authenticated using S/Key.
My OpenSSH 2.9p2, on Solaris, is compiled with S/Key 1.1.5 (which I've
patched
to deal with Solaris shadow passwords). It works, but there's a snag.
S/Key is nice, but when researchers travel abroad, they're bound to have
the OTPs printed with them. When using them as an authentication strategy,
it suffices to have a username and a OTP to log in; I'm not at ease with
that,
given that these cards can easily be lost, stolen, copied and used by anyone
to gain access this way.
What I'd *like* to have, is a somewhat more sophisticated authentication
strategy:
- public key auth succeeded? Ok, carry on.
- otherwise, try S/Key. S/Key failed? Bail out.
S/Key succeeded? Use password authentication as a second step.
The authentication process, though, is heavily client-driven. I've found no
way yet to get this done in OpenSSH. Hints, or good ideas, anyone?
Regards, Jeroen.