> I have wondered the same thing. What is the point of having/using a
> passphrase if it can be ignored and simply use the password instead.
> I'm new to SSH2 using latest OpenSSH and found that if I type the
> wrong passphrase, I get the password prompt. So what is stopping
> someone else who may have compromised (stolen) my password from
> one of my non-secure accounts (where I use telnet) to simply bypass
> the passphrase and use the password to get in ?
>
> Conceptionally I woud have expected SSH2 protocol
Protocol or implementation?
> to require passphrase
> only or *both* with the password.
You can configure the server (sshd) to prohibit (server-end) password
access and allow *only* user RSA authentication. This is what I do myself.
However, this is checking that the client "knows" the correct key, not
that the client has that key protected by a passphrase while it is stored
on disc. It would be possible to use a client that passes the challange
from the server to an external device (link an iButton) that actually
contains the key and returns the response; but none of the current
SSH clients do so.
> This means that even if someone gets
> your password, they can't get in to your secure accounts (where I use ssh).
> Without this basic concept in place, the whole SSH protocol is nothing
> more than an encrypted telnet session. The other problem with this is
> someone getting access to one machine and because of .rhosts or
> .shosts being setup, they can gain access to the others.
>
> At work I use secureID *and* a password, one is useless without the other.
> IMHO, this is what SSH2 should be as well... passphrase AND password.
OK, lets look at SecureID for a moment. The "token" contains a hash
function which is run once a minuit with the previous hash value *and*
a unique "secret" used as the inputs. This time-varying hash value is
used as the "password" for an otherwise normal "login" process (telnet,
FTP, &c).
*Some* versions of the SecureID token demand that the owner input a
PIN (password) onto the device before disclosing the hash value to him.
But only the actual hash value is sent across the network. The target
system has no knowledge about which type of token the user is using;
the correct hash value gets the user access. This is analogous to the
way the SSH passphrase is used; and the target system has no way of
knowing if the source system actually uses a passphrase to encrypt
the users private key value. Provided it can pass the test (produce
the correct response to a random challange) the source connection is
allowed access.
Some target systems demand both the SecureID hash *and* a password
before allowing a login to succeed - effectively two passwords. That
is a decision for the daemon on the target host receiving the call,
and also afected by the definition of the access protocol (it might
not allow two independant passwords to be carried across the network).
An alternative sometimes used by SecureID is to make the password
sent across the network the concatenation of the (current) hash value
and a string remembered by the user. This allows a two-part password
to be treated by the protocol as a one-part password. SSH does not
support this because the method used to validate a SSH user key
uses a challange and response, not just a one-way password transfer.
But SecureID and SSH are attempting to "solve" slightly different
problems. SecureID allows you to use an untrusted client machine
to access your server without exposing your server to subsequent
login from the client which "stole" your password. Of course it
is exposed to a naughty client during your session. SecureID
polices a relationship between the server and the token. SSH, on
the other hand, trusts the client machine but doesn't trust the
network. If anything it trusts the client machine *more* than the
server - the client machine gets to keep your private keys and
the server never sees them!
And there's nothing to stop you using the "UseLogin" option on the
SSH daemon and letting that check your SecureID "password"...
To state a few significant factoids about SSH:
1) it offers the server administrator the choice of *which* of a
set of authentication methods will be supported on *her* server;
it allows access (in the default setup) if any one of these
methods works on any individual connection
2) it offers the user the choice of which method supported by
any individual server he will use for any individual connection
3) it offeres better anti-spoofing/diversion protection than
SecureID which ofers none to the user that he is talking to
the correct server
4) but it's not necessarily the best solution for your problem,
only the best for a very common set of problems many people
on the net do face; or the best at the moment ;-)
--
David Pick
