ssh key management

[support_5]

Hi folks,

I was wondering what the forum thought about issues relating to ssh key management. My initial look into it made me cringe. I have several users, with accounts on several machines, and they need to be able to log in from one host to another without specifying a password. I know this can be done by specifying a .shosts file in each users home directory on each server. Also, there is the preffered way via ssh protocol 2 using RSA authentication. I have gotten this latter method working, but it seems a hassle to set up for multiple users on multiple machines. So, does anyone have any ideas, or know of any good documentation on this issue? What are the best practices regarding this?

Thanks heaps,

- Andrew Gray (IT Support, WorkCover QLD, Australia)

[Steven E. Protter]

answer in the hpux thread.

SEP

[Balaji N]

this time i am releiving the job of SEP by attaching Chris's doc.

here u go. this doc is written by a fellow forumer Chris.

-balaji

Chris -> A fantastic write up. Never got the forum to thank u for this.

[Balaji N]

SEP, u beat me. :-(
-b-

[Stuart Browne]

Just a reasonably off-topic rant here..

It's amazing what you take for granted after a while in this business.

I almost posted something along the lines of "I've never used .shosts before, but use the 'authorised_keys' exchagne.", but thought "but isn't that how most people do it anyway?"..

*sighs* Shoulda posted.. ;P

Just went through this kafuffle with a DR machine over in the UK, using 'ssh' to rsync the data on a regular basis (whee!), so it was all fresh in my mind..

Funny thing is that this is documented in the training maual you get for the RHCE..

Information, taken for granted..

*hangs head in shame* Ah well. I try to help wehre I can..

Balaji, SEP, nice doc. Didn't know it existed.

[Balaji N]

oh! have seen this quoted by SEP a few times.

-b-

ps: btw, how come u guys are awake now. i thought its day only in india. after a small hibernation, i am back on the forums.

[Balaji N]

oh! have seen this quoted by SEP a few times.

-b-

ps: btw, how come u guys are awake now. i thought its day only in india. after a small hibernation, i am back on the forums.

[Steven E. Protter]

Hi Balaj,

I've finally figured out what was wrong with my Red Hat 9 server.

Red Hat pulled the old stop up2date from working trick. I downloaded and installed all my utilities and then pulled sendmail out and re-installed.

Suddenly without my 8.11 sendmail.mc file, sendmail works a lot better. I'm wondering of sendmail.mc is no longer needed, but running experiments.

I want the second server to forward all mail to the mail one so when it takes over service during an outage, it just queues mail until the production server is brought back on line

This is somewhat complicated, so I'm up. I'm also worrying about a issue with my son's education. Can't sleep.

Andrew,

If we helped, please assign points.

SEP

[Jerome Henry]

Can we do sth to help you Steven ?

(Welcome back Balaji !)

J

[Balaji N]

hello steven

--snipped from ur post--
I've finally figured out what was wrong with my Red Hat 9 server.

Red Hat pulled the old stop up2date from working trick. I downloaded and installed all my utilities and then pulled sendmail out and re-installed.

>>> may be u should try apt-rpm when u find time. am setting up a test box here and going t o try it on this box.

Suddenly without my 8.11 sendmail.mc file, sendmail works a lot better. I'm wondering of sendmail.mc is no longer needed, but running experiments.

I want the second server to forward all mail to the mail one so when it takes over service during an outage, it just queues mail until the production server is brought back on line

>>> how are u collecting mails and forwarding. if this is going to be a DNS wont a secondary mx help. if this is going to be an internal mail server and if mail clients directly submit mails to these server, then how abt using a virtual ip address on the production server and then switiching the ip to the second server when u notice there is some issues. may be run a script on a third server which monitors and moves the ip. (idea flicked from MC/SG :-( )

This is somewhat complicated, so I'm up. I'm also worrying about a issue with my son's education. Can't sleep.

>>> hmmm. dont miss ur sleep. let me know if i will be of some help. we can take this offline.
perl -le 'print pack"H*", "62616c616a694062616c616a696e2e6e6574"'

-balaji

ps: 1. andrew, sorry for hijacking this thread.
2. hello jerome. congrats for moving up on the list. not sure if i congratulated u on ur wizardry.

[Stuart Browne]

It's 5pm here in AU (I'm a few thousand KM's south of Andrew).

[support_5]

Thanks for the document.

I was really interested in ways people manage the key distribution problem.

In my own research I came upon two interesting ways of working around this.

Firstly, in reply to the document by Vhris Vail, this method is by far the easiest, but it still leaves a security hole in that if someone compromises the server, then they have access to your private key, because it is not encrypted. This might be okay for some situations, where that doesn't matter, but what if it does?

Well, as many of you may know there is a program bundled with open-ssh called ssh-agent. This program allows you to encrypt your private key file and still have password-less logins. The way it works is like this: When you first log into a host, you should run the ssh-agent program. It will ask you ONCE for the password to decrypt the private key, and then will cache the unencrypted key in memory, and ssh will talk to ssh-agent via a unix domain socket and get the private key that way. Thus, each time you run ssh, it won't ask for the key, yet the private key is still encrypted. Of course, it is still possible for a hacker to do a memory dump of the process and get the private key that way.

Another way is with authentication forwarding. You run ssh-agent on a trusted, secure system, and then you configure ssh on each machine to use authentication forwarding (in ssh_config). Then, you can log into a host without a password, and from that host log into another host without a password...what happens is that the authentication is passed back through each ssh session to the originating one which has the ssh-agent running and authenticates from that.

Both these methods are more secure that passwordless private key method explained in Chris Vails document, but not necessarily more convenient.

An excelent document I found on ssh-agent and authentication forwarding, along with another little program to make ssh-agent easier and better to use can be found at:
www-106.ibm.com/developerworks/library/l-keyc.htm

This document explains some of owhat Chris Vail writes about, but continues onto the more advanced topics. Well worth the read. Also, there are two other documents after it:
www-106.ibm.com/developerworks/library/l-keyc2.htm
www-106.ibm.com/developerworks/library/l-keyc3.htm

The author has written a program that goes along with ssh-agent called keychain. Looks useful, although it does make logins slow (but still passwordless).

I am still interested in hearing other peoples stories and/or suggestions.

eg how to get the simplicity of passwordless private key files, with the security of password-protected private key files within ssh??

Thanks again

- Andrew Gray

[Stuart Browne]

I've unfortunately never had much luck using the 'ssh-agent' program (caused me far too many headache's trying to get it working in a non-x environment), thus I tend to stick with password-less ID keys and authorised_keys.

But in most environments, I leave it all passworded. I don't mind re-typing a password.

If your talking a 'user' however, ... I have no users who use ssh. Just the admins.

[John Meissner]

logging in from one server to another is a HUGE security hole. To set up your environment like this is a very bad idea.
In a situation where an intruder would gain access to one server he would then be able to move from box to box unhindered.
A password should always be required of a user when logging into a box.

[John Meissner]

(edit above message)
logging in without a password is a huge security hole

[Steven E. Protter]

Apologies for the earlier thread hijack.

I do not think password free login between servers is a security risk if implemented properly.

The public files need permissions to be tight and the file I attached is quite strict about permissions.

The chances of a public key being intercepted and decrypted by anyone other than the NSA is quite low. Still, I do regenerate the keys and distribute them on a regular basis, even though my keys are not passing through the public Internet.

SEP

[Bob_Vance]

I don't think that John's point was about decrypting keys, but was about compromising one system and thereby gaining access to others, if passwords are not required. At the admin level, from system to system, I generally stick with passwords, also, which obviates this particular problem, except, of course, that the hacked root could get to other systems as any regular user that did not require ssh password.

For users, passwords would be, most likely, unacceptable. OTOH, I'm not sure why a user would need to go from one *server* to another (I'm thinking of users with PCs and network logon. Serial connections are another matter.). I would think that they should simply open another session on the second server.

bv

[Tony Hansmann_1]

I have attached a ksh script to add new user's ssh key info to remote machines, makes quick work of it.

I use ssh-agent and ssh-add to login without passwds. If you are running a recent version of RedHat, Gnome and KDE are factory installed with ssh-agent running and ready to use for your X session. Just type ssh-add in a shell, it should prompt you for a passwd and notify you what keys it is adding. After that you should be able to log into hosts that have your pub keys in the authorized_keys file without a passphrase.

Gottchas:
- No keys in authorized_keys, no passphraseless login.
- sometimes you have to force "ssh -2 host" to make things work. If you run into this problem, you can set the "Protocol=2,1" in ~/.ssh/config to goto ssh2 first.
- Perms have to correct on all directories and files on both ends to do pub key logins.

-Tony

[support_5]

I agree with John that password-less logins around hosts is a security risk, but unfortunately a necessary one on the site I work on due to various system and database administration scripts requiring this mechanism.

I also agree with Stephen that it can be an acceptable risk if implemented properly. ie, don't think of it being a bad thing if someone hacks into on server and then another through password-less logins, as long as the two machines are relate. ie, don't think of servers as individual islands, but as grouped, so that servers lookin after one particular application are grouped, and servers looking after another particular application are grouped. It's only really bad if there is password-less logins across groups/applications.

The problem with ssh-agent is that you are still reqired to enter your password (to decrypt the private key file) at least once, which obviously isn't useful for automated scripts etc which need access to other machines. That is why in my previous post, the keychain program looked promising (see www-106.ibm.com/developerworks/library/l-keyc2.htm).

It seems that a script like the one Tony submitted, along with non-password protected private key files is the best way to go so far. But it's not the best idea to have password-less key files...

Thanks for the discussion... Any other ideas/comments?

- Andrew Gray