> Doesn't work when using strong authentication; ie, hardware tokens and/or
> one-time passwords.
Ah! (This seems to imply that ssh *doesn't* use strong authentication ;-)
Another implication of this statement is that he's using password
authentication (traditionally regarded as weak) with a one-time
password generator (or similar) to strengthen it; and he's *not*
using RSA user authentication. So he can't use the ssh-agent to
avoid having to enter the passphrase for each connection.
Comments:
1) SSH User authentication is probably of broadly similar strength
to the system he's using. Why isn't he using it? Possibly
company policy/system administrators policy. Possibly he
or they don't like the idea of storing a secret user key on
a computer and prefer to use a token.
2) SSH User authentication *could* be used in conjunction with
a different method of unlocking the secret user key if there
were worries about using a "simple" passphrase on the client
machine. That would require code modifications. If a hardware
token were in use that could be used to *supply* the passphrase.
That still leaves the actual secret user key on the client computer.
3) The ssh-agent could be modified to consult a token instead of
keeping a "database" of unlocked keys from the ssh-add command.
4) The ssh-add command could be modified to get the secret user
key from a token instead of from a file stored on the client
computer. This would avoid leaving the secret user key on the
client computers.
5) Given strong encryption of the conversation there is much
less need to avoid the use of repeatable passwords because they
can't be "sniffed" and used later by a miscreant. Perhaps
with this consideration one-time passwords are unnecessary.
It seems he doesn't want to have to authenticate multiple times
(understandable) but doesn't want to use the mechanism SSH provides
to avoid this (the ssh-agent connection). In that case, (and assuming
RSA host authentication is unsuitable which I think it is), there
needs to be a different mechanism for carrying the files that can be
automatically associated with the original SSH connection. A thought
that springs to mind is a pair of processes, one on the client
machine that listens for a connection from the *local* host only,
and a command on the server machine to use that process via the
SSH connection using port forwarding. Or a similar pair set up
to operate in the other direction. *That* gets the association
with the original SSH connection and would presumable be covered
by the original authentication.
That's the "best" way I can think of to match two basically
mis-matched models of when and how authentication should be done.
Of course, given a lot of time for a systems administrator, you
could always use kerberos tickets over the SSH connection - but that's
yet another authentication model that would have to be bent to fit.
--
David Pick
