On 18/10/2013 16:05, Tanstaafl wrote: > On 2013-10-18 7:19 AM, Alan McKinnon <alan.mckin...@gmail.com> wrote: >> On 18/10/2013 12:23, Tanstaafl wrote: >>> On 2013-10-17 10:30 PM, Walter Dnes <waltd...@waltdnes.org> wrote: >>>> I apologize. That is arguably a two factor system. When you said >>>> "ssh key and password", I "jumped to delusions", assuming that it was a >>>> standard ssh connection with the option of either key or password. >>> >>> Side question... >>> >>> So, wouldn't the simplest two-factor authentication be an SSH key that >>> required a password? > >> No, there is no way to verify that a user has enabled a passphrase on an >> ssh key. > > No... I mean... > > If I create an SSH key that requires a password (ie, not a 'blank' > password), then when I use this ssh key to connect to the system it was > created for, and it asks for the password... > > This is, as far as I can see, a poor man's 'two-factor' authentication, > is it not? >
I think you are misunderstanding how ssh keys work. You do not create "an SSH key that requires a password", instead the user sets up private key encryption locally with a secret. To use the key it must be unlocked (decrypted) and only then can ssh use it. This is completely under the USER's control, who is free to protect or not protect the private key as they feel like. sshd on the server is unable to enforce or influence this in any way. Secondly, the statement "use this ssh key to connect to the system it was created for" is nonsensical. A key pair has two components - public and private keys, and the only thing sshd cares about is whether the user connecting has the matching private key to the public one sshd can read locally. The user is free to use that public key on as many or as few servers as he feels like, and again sshd is in no position to enforce or influence this. It is completely up to the user what he does with his keys. Perhaps you mean that on the server end the user's account has a password defined and sshd is configured to use PAM. The PAM config could require that the user authenticates successfully with ssh keys AND with the Unix password before logging the user in. This can be done, but it is not a common configuration and does not ship out the box. It will also confuse the living daylights out of the average user who at least in my world is unable to differentiate between a local ssh prompt for a key passphrase, and a remote telnet prompt for a password... -- Alan McKinnon alan.mckin...@gmail.com
