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.a6d5...@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
_______________________________________________
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
