Slashdot Mirror
SSH Key Management Part 2
LKH writes "The second part of Daniel Robbins' ssh key management articles is up at developer works. Daniel covers passphrase-less authentication using keychain."
← Back to Stories (view on slashdot.org)
← Back to Stories (view on slashdot.org)
Well, there's two sides to this.
/root/.rhosts ). It's extremely convenient though.
The keychain folks have apparently taken the "rsh isn't so bad" approach. rsh and its counterparts are insecure for many reasons, only one of those is cleartext password authentication. Other reasons include unrestricted pre-authenticated per-user sessions (.rhosts files), and the ease with which someone can set up these sessions ( echo $myhostip >>
The other side is where you're coming from, that each and every session needs authentication. That's a fair stance, just inconvenient when you're making multiple connections.
I prefer an in-between approach. Start ssh-agent on login, and do the ssh-add manually. Then you can feel comfortable that someone must learn your RSA/DSA private key passphrase to use your credentials, and also that you have the convenience of not having to retype passwords, again and again, once you've authenticated once in that login session.
That's how the ssh folks designed the system to work, and I like that solution. You could also decrease your risk by requiring both RSA/DSA and passwords for authentication.
However, agents can be complex to install and configure, and can potentially decrease security. The agent knows all your secrets, after all. Especially, using non-local agents is highly inadvisable.
It is also worth pointing out that agents can be used with password based systems as well. Unfortunately, SSH implementations are only using agents for key management. It is possible, and highly desirable when a chain of hosts is involved, for the remote side to contact your local agent to manage a remote passphrase-based authentication, using a protocol such as SRP that doesn't leak. An SRP agent would live on your desktop, present a familiar interface that is unambiguous, and provide secure authentications network wide, even chained. You never enter or store any security information on any host other than your own local client (this also solves all traffic analysis attacks based on password length).
A well designed agent needs to be a library, with pluggable user interfaces that are adapted for all the different GUI/CLI systems out there. Agent interfaces need to be familiar and distinct. There is a huge risk in communicating with an agent over a CLI, for example, when you can't distinguish the agent's prompts from the server's prompts. Ideally, agents should be started and configured automatically on the client machine by the client software. Sensitive information should time out.
You also don't want your agent to become a huge database of fluff with things like addresses and phone numbers. Use a database for that, and equip your database with an agent, and your agents with protocols that let them perform client/agent/agent/server transactions (with only LOCAL agents of course).
MS's Passport, for example, violates all these rules. It's non-local, it's full of tons of information that's irrelevent to most transactions, and the interface is variable and confusing.
It would be great if projects like OpenSSH develop (or use) full-blown agents and agent protocols that allowed these features. I for one would be interested in hearing about general purpose client/agent/server architectures and protocols that have already been developed for use in Free Software projects, and/or TLS-based protocols that use agents. Any ideas?