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
