Re: OPIE considered insecure
- From: Daniel Roethlisberger <daniel@xxxxxx>
- Date: Mon, 9 Feb 2009 23:48:06 +0100
Lyndon Nerenberg <lyndon@xxxxxxxxxx> 2009-02-09:
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
My use case is primarily to log in from highly untrusted and
malware infested systems. OPIE has been a usable solution to
that problem. I'm primarily worried about keyloggers and USB
memory stick content dumpers. OPIE fits that bill quite 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
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@xxxxxxxxxxx). 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.
I prefer OPIE also because it does not need anything fancy on the
client side beyond a standard SSH2 client.
freebsd-security@xxxxxxxxxxx mailing list
To unsubscribe, send any mail to "freebsd-security-unsubscribe@xxxxxxxxxxx"