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."

Comments

Easier way?

[Anonymous Coward]

Debian's XDM will start X with ssh-agent if its installed....

$ cat .xsession
...
(ssh-add
xterm -e ssh -X host1&
xterm -e ssh -X -1 otherhost &)&
...
exec pwm
$

the ssh-add will pop up ssh-askpass and then log you in to all your hosts. And since X was started using ssh-agent, you never have to type in your passwords or passphrase for the entire session.

If your not using debian I think you can just run
$ ssh-agent startx

-Justin

Or if you want to automate it even more

[Bronster]

[~]$ cat .bashrc
...
SSH_AUTH_SOCK=`/bin/ls /tmp/ssh-*/agent.* | cut -f1 -d\ '
export SSH_AUTH_SOCK
...
[~]$

This works because the /bin/ls line with the pattern above will only get sockets that you can read, which means either owned by you or you are root (lucky you). It grabs the first one, which is fine for non-root users, though not wonderful if you're root - then again root shouldn't be doing this anyway.

It works from the console too!

P.S. - remember to nuke that agent when you've finished, otherwise anyone else who can get in as you has privs on every box that trusts you.

Re:Neat, but...

[earlytime]

Well, there's two sides to this.

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 >> /root/.rhosts ). It's extremely convenient though.

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.

Agent risks

[Dr. Tom]

Agent systems are interesting, and there is something to be said about the trend from simple server/client systems to server/agent/client systems. Agents can be very helpful in brokering transactions locally that involve sensitive information, or information that needs to be accessed repetitively.

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?