SSH setup for the multiple server admin

[simonvlc]

Hi all,

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? Please... share!!!

[Thrillhouse]

What about passwordless public key auth with root login disabled? You'd need possession of the private key to log in but you wouldn't have to enter a password for the keypair; you'd only need the root password to su to. And if the root password is the same for all systems and you change it often enough, that would suffice for me.

This seems to be the best compromise between the two options you posed but not necessarily the best one. For me, that would depend on other factors: are these outward- (i.e. Internet) facing systems? How valuable are the data/services you're trying to protect? Are they production or development servers? Etc.

[Irithori]

1) From outside:
ONLY one server, and _not_ neccessarily the obvious choice - the gateway- exposes port 22.
This server does not accept passwords, only key auth.
Ensure by policy that everyone with a key has a passphrase on the private key.
From this server, jump to the one that needs actual attention.

From inside:
All servers can be reached via ssh.
Key auth is encouraged, but passwords are possible

2) No remote root login at all

3) Login as normal user
This will allow trackback, who was actually logged in at a certain time.

4) "sudo su -" to become root. Correctly set up, it will ask for the _user_ password.
It creates awareness, that you are root now. I will spare you the spiderman quote
The sudo approach has the advantage, that you dont have to tell the root password
to a new colleague at first.
Sure, he can set a new one. But he still doesnt know the actual one.
(and his new root password would be set back next time cfengine/puppet do their magic. See 6) )

5) Do not use ldap or similar for users that can become root. They need local passwd/shadow accounts.
In the above setup, if the ldap server fails, you would not be able to login to any server.

6) Use a central configuration tool like cfengine or puppet to ensure, that root and the admin-users are
a) set up on any server
b) every admin-user / root has a consistent password throughout all servers.

7) You can also use cfengine or puppet to change admin-users passwords on all servers at once



just my 2cents

[Irithori]

One more thing.
If
you want to avoid the additional complexity of learning cfengine/puppet
AND if the total number of servers is reasonable low (e.g. < 10 )
then
you can still keep root / admin user accounts in sync with -for example- cssh.
Cluster SSH - Cluster Admin Via SSH | Get Cluster SSH - Cluster Admin Via SSH at SourceForge.net

This parallelizes manual jobs, that have to be done on several servers.
e.g.

cssh server1 server2 server3

opens 4 windows:
3 terminals to the servers
1 small window. Everything you type there will be done on the 3 server simultanously

Two commands later, the 3 servers have a new root password.

sudo su -
passwd

If the number of servers grows, I would definitely take a look at cfengine/puppet.
For as much tasks as can be automated.
One time effort of implemeting logic in cfengine/puppet to get rid of re-occuring tasks
results in: more time for newer and shinier jobs

[simonvlc]

Thanks all for your answers !

After 3 terrible days of headache with all this matter, I finally arrived to a solution with your help.

Basically I have enforced private key and disabled root login. I have added the users who need to do root things (actually just 2 to different servers) to the sudoers file, so the root password is safe now.

Irithori, I already bookmarked this thread, there is a lot of things that I like to review like the cfengine/automation tools. Thanks a lot for sharing!!!