2

I´m looking for a good ssh password/key setup for a system administration of multiple servers.

The ideal one will be one that can be at the same time comfortable and secure, but after thinking a lot around the problem, no solution seems acceptable.

Basically I arrive to these 2 setups:

One where every server has a strong (and unique) root password. To manage them, instead of logging with the password, I added a password'ed public key to their authorized keys.

I can login to all of them with the combo of the private key / private key passphrase from any computer.

Problems: Direct root login allowed.

The other one:

Direct root login disabled. Same setup with private key to login to a user account with su permission. Once logged as user, use su to login as root (must type root password).

Problems. Not very comfortable to retrieve each server root password. More comfortable, use a one for all root password (taking in account that no direct root login is allowed).

What do you think is better? Do you know any other good setup? Thanks in advance!

1
  • The use of a root account for routine system administration is considered a security risk. You are better off using sudo as this allows finer grained control over operations, detailed logging of actions and doesn't require you to change a bunch of root passwords if someone quits or is fired.
    – Chris Nava
    Aug 18, 2009 at 18:13

4 Answers 4

14

Have you considered simply disabling the root account, but allowing sudo? That way, the only password that each admin needs to know is his or her own, all access is logged to the individual, and key management becomes entirely optional.

4
  • +1 this is my preferred approach for all of my servers.
    – egorgry
    Aug 18, 2009 at 18:12
  • 1
    Thanks for all the answers ;). Just one point with the setup suggested. If a user can get root rights with just their account password, I suppose that disallow password logins is a must, right?
    – Simon
    Aug 18, 2009 at 18:37
  • It's not a must. If you've got sensible passwords, and are running something like fail2ban, it's unlikely to be an issue. That said, if it's an option in your environment, it may be worth doing. Just remember to back up your ssh keys :-D.
    – Cian
    Aug 18, 2009 at 20:05
  • 1
    In addition to this, set a strong root password and store it somewhere safe (nowhere near the server -- a physical fireproof safe is good), but only allow root logins on the local console. This is your "safety valve" if the available admins lose their keys.
    – womble
    Aug 18, 2009 at 21:48
2

Give each admin their own account on each server, and give them access to root-restricted things with sudo instead of su. Then you can use public/private key pairs or whatever other authentication method to log in to the server.

1

Tangentially related, depending on the number of servers, the number of admins, and whether all admins need access on all servers, consider a configuration management system such as (in no order of preference) bcfg2, cfengine, lcfg, or puppet. You can start small, managing admin accounts and keys as well as restricting ssh logins with the AllowUsers and AllowGroups directives in sshd_config.

Usually there's never enough time to learn to configure or deploy a CM system but if you target a test group of 2-3 machines and work at managing simple things at first (static files like authorized_keys, resolv.conf, etc.), you'll be surprised at how quickly you can get it implemented and ready to deploy to more systems. As more systems are brought under central management you'll also be surprised at the subtle misconfigurations which will turn up.

What does this have to do with setting root access? Simple: Once you manage configurations from a central system, it's much faster and easier to manage keys and access. Auditing is simplified which may or may not be important to you. Further, if you couple a CM system with an automated build system like Kickstart or Jumpstart, you can seriously reduce backup overhead and server deployment time. Access control is an important facet of configuration management; sometimes it helps to have a glimpse of a bigger picture.

0

Further than the sudo solution, you can use public key authentication and ssh-agent. You don't even have to enter the password every time to ssh the servers. See here

You must log in to answer this question.