Is there any setting to use to make ssh present a fake skey challenge
for nonexistent accounts? It would need to save the challenge for
reuse later otherwise an attacker could try it several times and see if
the challenge remains the same.
It would be kind of nice if an attacker could not use ssh with skey to
determine whether or not an account exists and has been initialized
with skey.
Here is an example. First, we connect to a machine with use of normal
passwords prohibited in the /etc/ssh/sshd_config file.
rum: no such account
whiskey: account exists and skey has been enabled
vodka: account exists, but no skey
$ ssh -l rum:skey 10.1.1.1
Permission denied (publickey,keyboard-interactive).
$ ssh -l whiskey:skey 10.1.1.1
otp-md5 996 trom02893
S/Key Password:
otp-md5 996 trom02893
S/Key Password:
otp-md5 996 trom02893
S/Key Password:
Permission denied (publickey,keyboard-interactive).
$ ssh -l vodka:skey 10.1.1.1
Permission denied (publickey,keyboard-interactive).
Now, another machine with the same accounts set up but with normal
passwords permitted in ssh:
$ ssh -l rum:skey 10.1.1.2
rum:[EMAIL PROTECTED]'s password:
Permission denied, please try again.
rum:[EMAIL PROTECTED]'s password:
Permission denied, please try again.
rum:[EMAIL PROTECTED]'s password:
Permission denied (publickey,password,keyboard-interactive).
$ ssh -l whiskey:skey 10.1.1.2
otp-md5 99 monk57993
S/Key Password:
otp-md5 99 monk57993
S/Key Password:
otp-md5 99 monk57993
S/Key Password:
whiskey:[EMAIL PROTECTED]'s password:
Permission denied, please try again.
whiskey:[EMAIL PROTECTED]'s password:
Permission denied, please try again.
whiskey:[EMAIL PROTECTED]'s password:
Permission denied (publickey,password,keyboard-interactive).
$ ssh -l vodka:skey 10.1.1.2
vodka:[EMAIL PROTECTED]'s password:
Permission denied, please try again.
vodka:[EMAIL PROTECTED]'s password:
Permission denied, please try again.
vodka:[EMAIL PROTECTED]'s password:
Permission denied (publickey,password,keyboard-interactive).
Thus, an attacker would know that 10.1.1.1 requires skey and 10.1.1.2
does not and that an account named whiskey exists and has skey enabled
on both computers. About the only thing the attacker would not know is
that on the second machine, the vodka account exists and the rum
account does not exist.
As you can see, it is trivially easy to determine which server requires
skey, which doesn't, and which accounts exist and have skey enabled.
Obviously, a fake skey challenge would need to be saved so that if the
attacker tried again, he would see the same challenge. If he saw
wildly different challenges on each try, he would know that it was
random.
How much use would this knowledge be to an attacker? My impression is
that the reason opening the finger daemon to the net is not viewed
favorably is that it identifies usernames to potential attackers. If
this is wrong, why not open it up again? Of course, we need to make
sure that any security holes in the code are fixed.
(Note. In the above cases, the FQDN was replaced with a nonrouteable
IP address.)
Eric Johnson
