Given the recent rash of SSH vulnerabilities, exploits, and attacks, I'm trying to implement some sort of 2-factor (or 1-and-a-half-factor at the least) authentication. It seems the easiest thing to do would be to make openssh require both a public key and a (server-validated) password (PAM or not). The ssh.com version of ssh has a configuration option called RequiredAuthentications which does exactly what I would like - require one or more forms of authentication:

Code:

RequiredAuthentications publickey,password

It's too bad, then, that net-misc/ssh is masked for removal from Portage.

I've found a few people around the net asking the same question as myself, such as this guy who gets pointed to a 3-year-old openssh bug, and an unresolved bug over at Debian (somewhat ironic, i think...). Unfortunately most of the threads I found elsewhere either had no replies, or linked to an old bug somewhere.

So, what am I to do? Leaving my systems allowing only key-based auth seems scary, and going back to passwords doesn't seem much better. Perhaps there's some trick that PAM can do that I'm not aware of?

Any insight would be greatly appreciated.

Last edited by reverendryan on Tue Sep 02, 2008 3:58 pm; edited 1 time in total

I'm already using Denyhosts, the problem is the new attacks are using stolen (legitimate) keys, either following the chain of trust from the recently compromised RedHat servers, blacklisted keys from the Debian OpenSSH thing, or both. Basically I don't trust the other people with access to my boxen to not get their private keys stolen.

Basically I don't trust the other people with access to my boxen to not get their private keys stolen.

You could enforce key expiration. Set up a cron job that runs once a week/month/quarter that examines the authorized_keys files of the untrusted users and deletes any entries that were there last time and are still there this time. Then, any stolen key will be worthless after the next run of the cron job.

Are you not handing out keys _with_ passphrase anyway? That requires whoever logs in with the key to know the password for the key as well. That is 2 tier auth isn't it??

If your handing out keys with empty passphrases (generating key without entering a passphrase when prompted), that's not a good idea!

Thus far I haven't generated others' keys, they've generated them and given them to me out-of-band (on a flash drive). Perhaps what I'll do is "expire" their keys and generate new ones for them (with some warning, of course). It is possible to remove the password from a private key, (first google hit) but I'm not sure any of my users are crafty enough to do that.

The best solution still seems to be a RequiredAuthentications equivalent. I suppose I could create my own overlay and maintain my own patched version of openssh, but where would I find that kind of time?!

I made some combinations
During logon I have to:
1. enter password for private key (retries depends from sshd_config)
2. enter password for user (retries depends from script /usr/scripts/sshauth.sh)
like: