SSH Key Management Part 2

Easier way? by Anonymous Coward · 2001-09-09 15:25 · Score: 4, Informative

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

Re:Easier way? by jdavidb · 2001-09-09 16:12 · Score: 3, Informative

I read the first article in this series, and since then I've learned all sorts of things about secure shell. Here's my recommendations (similar to the above) for making your life easy and secure:

Create a DSA public key/private key pair:

$ ssh-keygen -t dsa

You'll be prompted to enter an encryption passphrase to protect your private key in the event that your account is compromised.

Copy (scp) the public key to other hosts you want to be able to get to easily and securely:

$ scp ~/.ssh/id_dsa.pub remotehost:

Connect to the other hosts and add this public key to your list of authorized keys:

$ ssh remotehost
$ cat id_dsa.pub >> ~/.ssh/authorized_keys2
$ exit

Presuming you are running X (specifically this worked for me with Gnome under RedHat 7.1; probably very applicable everywhere else), setup a .xsession file with these contents:

cat > .xsession
#!/bin/sh

exec /usr/bin/ssh-agent sh -c '/usr/bin/ssh-add & sleep 5; exec /usr/bin/gnome-session'

Now logout and log back in. You'll be prompted for the encryption phrase you entered for your DSA private key. Now you'll be able to ssh to the remote hosts you setup the authorized_keys2 file for without typing a password or an encryption passphrase!

I was able to ssh into my Windows NT machine at work from my Linux machine at work using this technique. I had ssh installed with cygwin. You have to setup a host key for the Windows machine with this command:

$ ssh-keygen -t dsa -f /etc/ssh_host_dsa_key -N ''

And then you have to start the server:

$ /usr/sbin/sshd

Then put your public key into the authorized_keys2 file on the Windows machine. You may need to connect as "Administrator":

linux$ ssh Administrator@winnt

You really need to try to understand how all this works to be able to make good informed decisions about security. Read some good accounts of basic public key/private key encryption (RSA/PGP) to start. If you already know how PGP works, the public key authentication of ssh (which keeps you from having to type a password) works very similarly: the ssh client basically provides a signature using the private key which the server on the remote host checks against the public key to validate your identity. Plus, this protects against the password keypress timing "attack" mentioned a week or two ago.

Be sure to always verify the host key signature of a machine you ssh to for the first time. This protects you against the man-in-the-middle attack, the only real vulnerability ssh has. (If you always verify that long hex string with the real value, you'll never be compromised.) If you need the hex host key signature for a machine, you can get it by typing:

$ ssh-keygen -l -f /etc/ssh_host_rsa_key.pub

But only do this in a verified connection, such as on the console.

BTW, many exact paths may vary. You may find things in /usr/local instead of /usr. You may find ssh config files in /etc/ssh instead of /etc. You also probably want to review manpages, look up the command-line options I used, decide between DSA and RSA, etc. Have fun!

That about sums up four weeks of learning or so for you. I hope others can benefit from what I've learned. Now I plan to go read that second article and see what else I can learn!

--
Secession is the right of all sentient beings.
Re:Easier way? by Dwonis · 2001-09-09 16:24 · Score: 2

Copy (scp) the public key to other hosts you want to be able to get to easily and securely:

$ scp ~/.ssh/id_dsa.pub remotehost:

Connect to the other hosts and add this public key to your list of authorized keys:

$ ssh remotehost
$ cat id_dsa.pub >> ~/.ssh/authorized_keys2
$ exit

There's an even easier way:
$ ssh remotehost 'cat >> ~/.ssh/authorized_keys2' < ~/.ssh/id_dsa.pub
Re:Easier way? by Webmonger · 2001-09-09 16:38 · Score: 3, Informative

Perhaps it would help if you read the article. Under "Limitations of ssh-agent", it lists the problems that Keychain solves.

The advantages of Keychain are
1. You only need to do it once each time you start your computer. For those of us who leave our boxes running for months or more, there is a significant difference between boots and sessions.

2. you can use it for cron jobs. That means you can securely perform remote operations without using unencrypted keys.

Yeah, if all you want is ssh-agent, ssh-agent might be easier. But for people who need it, keychain is key.

And by the way, I run Debian, and I don't even have an .xsession file.
Re:Easier way? by Alan · 2001-09-09 16:55 · Score: 2, Informative

$ vi .xsession
(creates new file)
(paste from above)
:x
$

Now you do :) That's what I did on my unstable box anyway.
Re:Easier way? by Alan · 2001-09-09 16:59 · Score: 2

Or even easier, there is a program called "ssh-copy-id" (in debian anyway) that does just that :)

Actually, it only does it for ssh1 keys, but that's easy enough to change :)
Re:Easier way? by cabbey · 2001-09-09 17:24 · Score: 2

So will SuSE, just change a variable in one of the config files and XDM/KDM/etc will run your entire desktop session under ssh-agent.

But that woudn't let him plug his pet project now would it? ;)

He does allow one benefit though for folks that either don't use a desktop manager, or telnet into a box multiple times... but then who does that? I mean seriously, once you setup your desktop properly, and use agent forwarding (which he didn't even mention iirc) well, by then there's no reason you should have an agent runnign anywhere other than the machine you're sitting in front of.

I'm not sure if the cronjob argument is a benefit or not... should be easy enough to salt those variables away yourself if you wanted.
Re:Easier way? by hbo · 2001-09-09 17:36 · Score: 2

The invocation of xdm on Debian must be something like:

ssh-agent xdm

Which gives the ssh-add commands something to talk to. Absent that sort of thing, merely doing ssh-agent xdm is only half the battle. I have two scripts. The first, in the best tradition of programmer laziness. just saves me typing one extra word when I start X. I call it ssx:
#!/bin/sh ssh-agent stx
and stx has:
ssh-add startx
Still, that keychain thingie sounds interesting. I have a gut reaction that "long lived ssh-agent" processes are a Bad Thing. But so far, I can't think of a specific reason why they would be that doesn't also apply to any other use of ssh-agent.

--
"Even if you are on the right track, you'll get run over if you just sit there" - Will Rogers
Re:Easier way? by Webmonger · 2001-09-09 23:58 · Score: 2

1. Yep. I leave my work machine on all the time, but I log in each morning, and log out each night.

2. The writer should definitely have been more specific about cron useage, but I think you're supposed to run a script from cron, then run keychain from the script.

Or if you want to automate it even more by Bronster · 2001-09-09 15:52 · Score: 4, Interesting

[~]$ 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.

Neat, but... by robbyjo · 2001-09-09 16:12 · Score: 2, Informative

Eventhough keychain will let you login to various hosts without passwords, I still prefer typing my password manually each time I log into those hosts. The main reason is that if there is a chance that somebody could access one of my accounts, he/she could easily log into my other accounts. At least typing each could provide some barrier.

Moreover, I could devise a "safer" plan by logging into one of the least important hosts using ssh, and then re-login to the real one that I'm going to work with. I dunno whether this provides a technically safer method, but I do feel a lot safer.

--

--
Error 500: Internal sig error

Re:Neat, but... by earlytime · 2001-09-09 17:06 · Score: 5, Informative

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.

--

Re:telnet by MavEtJu · 2001-09-09 16:17 · Score: 3, Insightful

telnet needs to be phased out.

Regarding the telnet-service, yes.
Regarding the telnet-protocol, no.
Regarding the telnet-program, no.

It's being used for more than port 23 only you know...

Edwin, can't live without small basic debugging tools.

--
bash$ :(){ :|:&};:

Using cfs with ssh keys and other secrets by ftobin · 2001-09-09 16:22 · Score: 3, Insightful

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.
CFS can much more easily be used to store other secrets, such as my GnuPG keys. It is a good general-purpose secret-storer.

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.

Re:Using cfs with ssh keys and other secrets by Dwonis · 2001-09-09 16:29 · Score: 3, Insightful

Here's the problem with what you're doing: you can't do authentication forwarding, which sucks big-time when you are scping from one remote machine to another remote machine.
Re:Using cfs with ssh keys and other secrets by ftobin · 2001-09-09 18:13 · Score: 2

Yes, it appears to be the CFS I'm talking about. The nice thing about CFS is that since it relies on NFS for its infrastructure, it is very portable, and resides entirely in user-land (with a root-running daemon).

TCFS is generally used to encrypt entire home directories, and but is generally Linux specific (kernel tie-ins). It is more advanced than CFS, though.

ssh-agent startx by smcavoy · 2001-09-09 16:35 · Score: 2, Interesting

I use this with much sucess,
I must then run ssh-add for every key I want to use. doing that once a day (assuming your not in a hostile enviroment, and never lock the console...)
saves time. Is this a bad idea?????

Wish list by XNormal · 2001-09-09 17:31 · Score: 3, Insightful

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.

ssh-keygen this you !@#$!@# by PatJensen · 2001-09-09 17:55 · Score: 3, Interesting

I read this article, it seems pretty cool to be able to store all your keys and access them using the ssh-agent, but I'm having a hard time just generating an RSA SSH2 key and having it work. Anyone mind helping me out? I've followed this process:

1. ssh-keygen -t rsa
2. typed in a 12 character password
3. copied the dsa_key.pub from my desktop and pasted it to ~/.ssh/authorized_keys2 on the server. 4. ssh -2 remotehost.

Then it asks for a password. I used ssh -v, which it said it was trying RSA but it failed. I'm running OpenSSH 2.9p2 on Mac OS X. Help me, I've read the man pages repeatedly but it's still all jibber-jabber!

-Pat

Re:ssh-keygen this you !@#$!@# by *nixie · 2001-09-09 18:18 · Score: 2, Insightful

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.

My ISP's server is running commercial SSH 3.something. I have an .ssh2 directory there, containing my (converted) public key and a file called "authorization" which points to it:

>cat authorization
Key id_dsa.pub

Hope that helps.
Re:ssh-keygen this you !@#$!@# by jovlinger · 2001-09-10 02:46 · Score: 3, Informative

in addition to the conversion step, you have to use DSA keys.

Using OpenSSH on the client, and Commercial on the Server, I was eventually able to get automatic authentication to work using DSA keys. RSA using same procedure failed.

Oh, and unlike ssh1, I had to put the key in its own file and then add a reference to it in a second file. Rather cumbersome.
Re:ssh-keygen this you !@#$!@# by CorwinOfAmber · 2001-09-10 03:04 · Score: 2, Informative

1. ssh-keygen -t rsa
2. typed in a 12 character password
3. copied the dsa_key.pub from my desktop and pasted it to ~/.ssh/authorized_keys2 on the server.

Are you sure you copied the right key? You generated an RSA key, but you copied a file called dsa_key.pub. The default RSA key filename for openSSH is id_rsa.

--
My future's determined by Thieves, thugs, and vermin -- The Offspring
Re:ssh-keygen this you !@#$!@# by mjh · 2001-09-10 05:17 · Score: 2

I did this same exact thing. I eventually figured out that OpenSSH will default to protocol 2 before protocol 1. Since you're generating an RSA key, that's a protocol 1 feature. Which means, that first, you have to copy the correct key, which should be "identity.pub" and install it in "~/.ssh/authorized_keys".
Then on your local machine, you have to specify that you want to use protocol 1. This can be done by specifying '-1' on the command line or by editing $HOME/.ssh/config and putting in:
Host *
Protocol 1,2

The alternative, is not to generate an RSA key, but to generate a DSA key, and then do exactly what you're doing.
Hope this is helpful.

--
Key to financial independence: Spend less than you earn. Save and invest the difference. Do it for a long time.

Agent risks by Dr.+Tom · 2001-09-09 18:06 · Score: 5, Insightful

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?

If your winbox can HTTP, it can SSH. by yerricde · 2001-09-09 18:19 · Score: 3, Informative

Do you honestly think we are rid of 'dumb' wintel boxes that can only 'telnet'?

Yes. If a Wintel box can HTTP, it can SSH. From Google.com, type in putty ssh and click "I'm Feeling Lucky" to be taken to PuTTY, an X11-licensed SSH client for Win32. (If your firewall restricts HTTP and FTP downloads of binary programs, it probably also restricts outgoing telnet and ssh.)

--
Will I retire or break 10K?

Easier way? by dirtyrat · 2001-09-09 21:23 · Score: 2, Informative

Here's my .xsession. Works on Red Hat Linux, and needs ssh-askpass-gnome installed.

#!/bin/sh if [ ! "$SSH_AGENT_PID" ]; then exec ssh-agent $0 else ssh-add exec /etc/X11/xinit/Xclients fi

Did you read the first part of the article? by Balinares · 2001-09-09 22:04 · Score: 2

You'll find it here: http://www-106.ibm.com/developerworks/library/l-ke yc.html
Hope it will help, it's informative and well-written.

--

-- B.
This sig does in fact not have the property it claims not to have.

Big deal! I do it w/bash login and logout scripts! by Kaz+Kylheku · 2001-09-10 11:51 · Score: 2

I have login and logout scripts for managing and ssh agent. The first time I log into my system, it starts and ssh agent. It records three things into a file: the agent's PID, a reference count initialized to 1, and the agent's socket.

Subsequent login sessions simply use the existing information and bump up the reference count.

The logout script decrements the reference count, and if it reaches zero, it kills the agent. Thus so long as I have at least one remaining shell, the agent is running, and I don't have to retype the password phrase.

A little extra subtlety takes care of cases like nested subshell invocation and so on. A kill -0 is used to verify whether the agent is running, which takes care of cases when the reference file is bad (e.g. reboot without logging out).

There are no concurrency controls in the reference counting, the assumption being that I will never switch between shells fast enough to create a race among two or more logouts or logins.

If I wanted to, I could change from reference counting to a system which keeps the agent persistent, but I don't entirely like the idea of leaving the agent running when I'm not logged in.

If any ssh user wants these scripts, just write me!

28 of 109 comments (clear)