Lyndon Nerenberg <lyn...@orthanc.ca> 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 > well.
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 > >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. I prefer OPIE also because it does not need anything fancy on the client side beyond a standard SSH2 client. -- Daniel Roethlisberger http://daniel.roe.ch/ _______________________________________________ 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"
