"That which is overdesigned, too highly specific, anticipates outcome; the anticipation of outcome guarantees, if not failure, the absence of grace."
-- William Gibson, All Tomorrow's Parties
Secure remote authentication methods

I've been thinking recently (again) about how to securely connect to a machine you have to administer.

For users, this isn't a major problem. You can have random passwords for each host you need to connect to as long as you set up ssh keys with passphrases and alternatively, ssh-agent to deal with the annoying parts of actually connecting to the machine. As long as you have "trusted" hosts which house the private ssh keys, you're good.

For admins, it's different.

I need to have root access on a target host, which requires either knowing the root password (su) or knowing my user account password to sudo to root (sudo su). So if I want random passwords along with my ssh keys, I have to keep a list somewhere, probably on my "trusted" keyhost, of my account passwords. When I want to become root, I then have to check that crib sheet to see what the nice random password is. This very rapidly becomes tedious when you have upwards of 50 hosts you have to admin (I can keep about fifteen passwords in my head at any given time, and it takes about two weeks for a new password to really settle in), so I was curious what sort of secure (read: mostly secure, more secure than having the same account password for every machine, etc) auth methods people were using to administer their boxes.

I've never been happy with my own method of doing it, which is having different passwords for each "domain" of hosts. I've thought about switching this around and using the same root password for each cluster of machines (work: LAN, DMZ, etc; personal; projects, etc, etc) and using phrased ssh keys to actually get to the box... that means a lot less passwords you have to memorize, but it also means that if you're co-administrating the machine, more people have to know the root password. Of course, if you're just using sudo, and someone gets their account password, an attacker has root anyway...

On the other hand, if an attacker gets a user account, but sudo is not allowed, they can't get root access without some amount of work...

I can't think of anything that resembles a sane solution, and I've been thinking about this for years; I have yet to come up with anything that doesn't make me unhappy in one way or another.

January 22, 2004 6:22 AM

Couple more thoughts.

Set up keyhosts in each segment of the networks. The keyhost has a different root password than the other machines in their segment. So to gain access to the other machines (assuming you forget the password), you just have to remember this one password to get it.

The keyhost has shell logins for people who need it, with no UNIX passwd access -- keys only -- and no sudo ALL.

The problem with this is firewall traversal. Assuming your internal network is completely segmented, you have to ssh to your firewall to gain access to your LAN, you don't get to keep your key credentials (obviously). The solution here is a authenticated tunnel or bridging box (VPN, etc) which allows you to get access to the internal network, and therefore your key to the keyhost is valid.

Once you have a tunnel, you use your external network key to gain access to the keyhost, from there you have access to internal network resources -- other hosts -- using your ssh key on the LAN keyhost.

Alternatively, your external network keyhost is where you're allowed to VPN in from, and you can use your private keys on that machine to gain access to the internal networks keyhost.

This all seems very convoluted.

Posted by: bda at January 22, 2004 7:47 AM

After much discussion with a couple people in #215 (kyoorius, nullboy, yuckf00), I came up with the following rough draft:


It really needs to be rewritten for coherency and readability, but I think there's a few useful points made, if only for discussion purposes.

I will be attempting to implement this for myself and those who require root access at work, and perhaps at PWF if Ian (my fellow remaining System and Networking Triumvir) is amiable to being a guinea pig.

Posted by: bda at January 23, 2004 4:23 AM
Post a comment

Remember personal info?