Ssh – 2 Factor Authentication in SSH using public key and PAM

authenticationpamssh

I'm trying to setup 2 Factor Authentication. I want the user to login successfully if:

The public private/public key matches (authentication method: publickey) or the password is correct
My pam authentication method is successful.

The second authentication method is a PAM file. So I place it into /usr/lib/pam/ and added auth required my_pam_module.so in /etc/pam.d/sshd.
So far I can either log in using the (publickey method) or (a password and whatever is required by me pam module). So I added AuthenticationMethods publickey,keyboard-interactive in /etc/sshd_config and now I'm required to have the public key, password, and "whatever is required by me pam module".

What lines do I need to change in order to achieve what I described above? I'm using Mac OS X Mavericks (10.9). If you aren't familiar with Mac, it could also help what you'd do on your Linux system.

Best Answer

It's quite easy for "publickey->password->your_module" or "password->your_module". Can't find the way to remove password from the first chain

publickey,keyboard-interactive - means that publickey auth will be used and keyboard-interactive after that (kind of logical AND), replace comma with space for logical OR, like

AuthenticationMethods publickey,keyboard-interactive:pam keyboard-interactive:pam

Related Solutions

Custom PAM modules and security considerations

When you call into Linux-PAM for some authentication procedure, there is always one and only one stack that is run.

The stack definition is looked up in these places; the first successful attempt determines which file is read:

the file in /etc/pam.d named after the application "service name" (e.g., sshd or gdm), or
the file /etc/pam.d/other if no service-specific file exists, or
the file /etc/pam.conf if directory /etc/pam.d does not exist.

See the documentation for function pam_start for details.

The common-* files are a convention followed by many Linux distributions but are not mandated by the PAM software itself. They are usually included by other PAM files by means of @include statements; for instance the /etc/pam.d/other file on Debian has the following content:

# We fall back to the system default in /etc/pam.d/common-*
@include common-auth
@include common-account
@include common-password
@include common-session

The same @include statements may be used by service-specific file as well, and -indeed- they are in the default configuration on Debian. Note that this is a matter of configuration: a sysadmin is free to change the file in /etc/pam.d not to include any common-* files at all!

Therefore: if your PAM module is specific to your application, create an application-specific service file and call the module from there. Do not automatically add a module to other services' PAM file nor to the fall-back others file, as this may break other applications installed on the system. Management of the PAM software stack is a task for the system administrator, not for the application developers.

Ssh – PAM failing to authenticate sudo, after successfully contacting ssh-agent

Configuration is OK, but you need to have some identities in your ssh-agent to be able to authorize the sudo operation. You can verify that your agent has some identities using

ssh-add -L

It should print the public keys in your agent and at least one of them should match the public key on server in /etc/security/authorized_keys.

If the agent does not have any identities, you need to add them on your computer, again using

ssh-add [path/to/key]

and insert your passphrase, if prompted.

Best Answer

Related Solutions

Custom PAM modules and security considerations

Ssh – PAM failing to authenticate sudo, after successfully contacting ssh-agent

Related Question