OPIE considered insecure

[Lyndon Nerenberg]

> Right, but that's not the problem they're trying to solve.  They're trying to 
> solve the problem of logging in _from_ an untrusted machine, to a trusted 
> machine.

Okay, I got it backawrds.

> So, an alternative might be to carry around a USB key with a one-time private 
> key, different from your normal private keys, and have the public key 
> command-squashed on the server to remove itself from authorized_keys before 
> running the shell.

That's what I do -- multiple throw-away keys on a USB stick, for 
emergencies. However if you're that paranoid you better be carrying around 
your own set of ssh binaries on that stick as well.

> You could generate several, each with a different passphrase (assuming that 
> you could manage to remember that many passphrases and which keys they go 
> with), and get a similar effect to printing out a card with the next ten OPIE 
> passwords.

It's not that hard to come up with a scheme that lets you map from an 
identifier tagged to the private key to the corresponding password (in 
your head). It's a pain at the start, but once you've used a given scheme 
for a while it becomes second nature.

Akso, note that you can get similar behaviour using K5 with one-off 
instances of your principal (e.g. lyndon.a6d5mps at EXAMPLE.ORG). The 
advantage here is that there are no key files involved (but you still want 
to carry a trusted kinit binary with you). The downside is that most sites 
don't have K5/GSSAPI enabled. And of those that do, a significant 
percentage of the implementations still don't to dynamic realm discovery, 
therefore you need a pre-existing arrangement to map your realm to the 
appropriate KDCs.

--lyndon

   Happiness is a good martini, a good meal, a good cigar, and a good woman ...
   or a bad woman, depending on how much happiness you can stand.
   			-- George Burns