[Beowulf] One time passwords and two factor authentication for a HPC setup (might be offtopic? )

[Mark Hahn]

>> Seemed kinda silly to me.  My minimum level for security is something like ssh
>> with certs.
>
> Of course, we use ssh too. Are certs. the same as a public-key
> private-key exchange?

I think Bill meant the publickey mode of ssh, presumably encrypted ones
(that is, passphrases.)  technically 'cert' normally refers to X.509
certificates (as in SSL), which are somewhat more involved than ssh PKs.

>> So various attacks don't work, things like spoofing dns, network
>> sniffing, and man in the middle attacks don't work (assuming users with a clue).
>
> What can "users with a clue" do to defeat these kinds of attacks? Yes,
> users can choose smart passwords and protect them but how do users
> factor into protecting against spoofing, network sniffing etc?

your password has to either be disabled (in favor of PK) or else unguessable.

> Of course, users are important for social engineering sort of attacks
> but in these other more advanced hacking strategies how can users
> protect themselves? I thought these were more ripe for sys admin level
> security solutions.

ssh takes care of the connection, so there are still two vulnerabilities.
if you're still using a password over ssh, it can be sniffed (visually, etc).
but more fundamentally, the machine you're sitting in front of is your 
main vulnerability, so don't connect from any machine you don't trust.
using PKs means your password doesn't get sniffed, but you're still sunk
of your ssh client machine is compromised.  (be careful with agent
forwarding, as well...)

>> Sounds reasonable, so sure you get a one time password,
>> the hard part is
>> making sure nobody sees that password except the intended recipient.
>
> Yes, agreed. But that problem exists whenever you use *any* password
> exchange. OTP's just reduce the risk of an intercepted P/W being
> continuously reused, correct?

since the password is one-time, it doesn't do any good to sniff it.

> "Valid known hosts" are great but the reality is that many times users
> travel and would like to log in from a Laptop or off-site login PC
> that doesn't always have a static I/P etc.

not relevant - it's the ssh client that wants to verify the hostkey 
of the server it's connecting to.