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

Re:Easier way?

[jdavidb]

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!

Re:Easier way?

[Webmonger]

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?

[Alan]

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

Now you do :) That's what I did on my unstable box anyway.

Neat, but...

[robbyjo]

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.

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.

Re:telnet-service

[Anonymous Coward]

MavEtJu said:
"Regarding the telnet-service, yes."

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

Any admin securing a secure box already knows not to run telnet, but for the other 99.999% of boxes out there, being able to access when stranded on crappy clients is important.

If your winbox can HTTP, it can SSH.

[yerricde]

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

advice

[Anonymous Coward]

I recommend using the new (currently in the late beta stages) ssh client NetRes SSHRes. You can find information about it here. This client uses public key cryptography with their new key hiding technology, that maintains your security even if the box youre sshing into has been compromised. You can even forward authentications and stay authenticated between sessions. SSHRes is available for NetBSD, OpenBSD, and Linux, with versions for Solaris, A/IX, Windows 2000, Mac OS X, and BeOS to be developed. The project is open source, and will be supported by selling documentation, tech support, and installation to corporations.

Easier way?

[dirtyrat]

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

Re:ssh-keygen this you !@#$!@#

[jovlinger]

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 !@#$!@#

[CorwinOfAmber]

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.