I got mine for free from a user of my software who wanted me to add support :)
In fact I finished that just this week, I'm considering using it full-time for some of my machines now.
The nice thing as far as I'm concerned is that unlike some other similar devices, all the specs for the OTP generation and all the software components are open-source.
The price point was right for me; I just ordered one.
They mention a coupon on their site for the "VIP" token:
http://www.yubico.com/january-2011-newsletter
It looks like the VIP version is exactly the same as the regular, but it comes with a Symantec identity that can be removed.
If someone "borrows" your thumb drive they could extract the secrets and return it without you knowing, but AFAIK secrets cannot be extracted from a real token such as a Yubikey.
Come on mate, just use a bit of imagination.
You use the pam_usb module to login locally and an encrypted passkey stored on the same usb thumbdrive for remote SSH connections.
One thing the article did not really answer was why this is necessary - why is it necessary? I thought that public and private keys were a pretty secure way to SSH into a machine.
Unless you lose them. Authentication isn't just about allowing people you know in, if they know the secret pass-phrase that never changes. It's also about knowing they are who they say they are. Two-factor authentication radically improves that second aspect (in most / ideal cases).
Indeed, as long as you only log in from trusted devices, you can just as well use private key-based authentication.
This kind of two-factor authentication solution is good in case you have to log in from non-trusted computers to your private server sometimes. It prevents someone running a keylogger from being able to log in. And you'd never copy your private key in that case as it could be easily stolen.
OPIE one-time passwords are similar and have been used for a long time. I don't know the advantages and disadvantages of the Google approach (except that you have to trust Google).
I could see where this could get annoying for those who create many separate SSH sessions. What would be the best way to require two-factor authentication only if a user is connecting from a new IP address?
I was thinking about the same but I guess that's the downsize of having an extra security.
Something to make it less painful is to use the ControlMaster ssh feature which should allow to reconnect to your server during your session (as long you have the first ControlMaster still connected).. tutorial how to use it randomly taken from google here http://goo.gl/26Oxx
ssh-agent + ssh-add or ControlMaster (depending on how you set things up) will share either a key or the whole connection without requiring you to re-authenticate
I use this approach and it works absolutely wonderfully.
The single, small, annoying caveat (there is always one) is that after an unexpected reboot, you will have lingering dead sockets; if you forget to delete them before starting ssh, ssh will complain and will not overwrite the dead socket.
There's probably a way to get it not to do that, but it happens so infrequently to me that I've never bothered.
I've also noticed that if you SSH into some arcane embedded devices, they behave strangely if you try to open a new channel on the same connection. Tread lightly on anything not OpenSSH on the far end.
Isn't an auth code regenerated every 30 seconds? Just enter the new code displayed on your phone? Two passwords is okay by me for an added layer of security.
interesting, but two factor ssh authentication can be achieved mucheasier than this: encrypted ssh keys. Something you have (the private key) and something you know (the password to the private key).
"Something you have" actually implies "something an attacker wouldn't have".
Hardware tokenizers, SMSes via mobile phones or secrets available only on your phone are all things that confirm a physical link with you that the attacker cannot reproduce even if it has a keylogger and root access on your computer.
Which cannot be said unfortunately about private keys. You can regard them as long passwords saved in a file on your computer (which you need to bring with you on a USB stick and copy on any remote computer from where you'd like to login). Sure, they do not travel over the network, but they have zero protection in case your laptop is rooted and keylogged.
The whole US financial industry has their heads in the sand over this one. In 2005 the FFIEC (a US regulator) declared that single-factor authentication alone wasn't sufficient for high-risk transactions.
What did the industry do? They rushed half-baked solutions out the door. One of the worst offenders is Harland Financial Solutions. They created a "Multi"-Factor authentication product for online banking, which is multi-factor in name only. When you login using a computer without a cookie set, the "MFA" system asks a security question (like, "What was your elementary school?"), then sets a cookie.
Harland considers the computer+cookie combination "something you have", and will claim with a straight face that this system is secure and multi-factor.
Unfortunately as an administrator (outside of a soft policy) there doesn't seem much I can do to ensure that my users have an encrypted ssh private key nor can I control what other machine it's copied to. Which is something that worrying when users add 5 different authorized_keys from this and this account on physical machines and VMs and Android devices.
