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)
it's about time we got rid of telnet and only allowed ssh. telnet needs to be phased out.
Personally, I like to use CFS, the Cryptographic File System, to store my filesystem-stored secrets. CFS works as an NFS loopback server, encrypting directories using a symmetric cipher.
When you 'cattach' (unlock) a CFS directory by entering the passphrase needed to decrypt the directory, you can then access the directory as normally as any other directory. The encryption/decryption is done on a need-to basis; sorta like PGPDisk for Windows, I imagine.
The reason I like to use CFS over thing such as ssh-agent is that has several features and advantages over ssh-agent:
One can set attached directories to detach after a set idletime or a fixed time. I find this very convienent, and an almost mandatory security measure. For example, I have my ssh keys set to detach after 20 minutes of non-use.
It is much easier and plain to use decrypted secrets in multiple concurrent sessions than ssh-agent. For example, a certain environment need not be mirrored across several xterms that are all accessing the secrets (e.g., I ssh from different xterm's).
With ssh-agent, it can be cumbersome to keep this in-sync across multiple windows.Of course, it can help to start ssh-agent with the X session, but this is not always available; for example, I could have multiple console terminals open, all accessing my ssh keys. Or I could login multiple times to a box which has ssh keys on it remotely several times (open up several ssh connections); I want to be able to unlock the secrets in one session and have it apply to the others.
Personally, I think CFS's approach to having secrets available across multiple concurrent sessions is a 'better' approach than some hacks that have been suggested.
Unfortunately, I can't find a good URL for CFS, so you'll have to do some searching on your own. It's in the FreeBSD ports collection, though.
Such as when you are trapped at a client site and they have Wintel boxes and vt320s. If you can't telnet, you can't get to resources you might need.
Sometimes it is important to be able to get through to a less important server. Systems using ssh should perhaps WARN whenever a telnet login is sucessful (as a reminder to change passwords) but to say it should be phased out is very naieve, and absolutely WRONG.
An ssh-agent which supports physical tokens like the Dallas semiconductors iButton (decoder rings are cool!)
Using ssh-agent to access cfs encrypted directories.
Using ssh-agent to unlock GnuPG keys.
All of the above, tunnelled through ssh-agent forwarding.
Using the same physical token to log in locally.
World peace.
Stop worrying about the risks of nuclear power and start worrying about the risks of not using nuclear power.
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?
Is the server running commercial SSH? If so, you'll need to convert the public key using ssh-keygen -e before putting it on the server. Also, the authorization file is a little different; it doesn't contain the key directly.
.ssh2 directory there, containing my (converted) public key and a file called "authorization" which points to it:
My ISP's server is running commercial SSH 3.something. I have an
>cat authorization
Key id_dsa.pub
Hope that helps.