With SSH1 there was a way to PermitRootLogin=No and still allow root to do some commands remotely to facilitate some system administration but not an unrestricted logon in the authorizedkeys file. I need to do this with SSH2, however, I have been unsuccessful.


I would greatly appreciate some assistance

Thanks in advance,
Mark

Is there any problem to login with another user & 'su -' to root user?

Thats exactly what we want. We want people to logon and then su for an audit trail. However, we still need the ability to push changes out after you have su'd on one server to the others with scp or sftp.

Mark

Ok, I'm not sure I fully understand what you are trying to achieve...
I think you want to copy changes on one machine to other machines with scp/sftp..

If someone logs in and su - to root, they can then scp/sftp from there to another machine.

Usually for maintenance, if this is a common repetitive action, it can be scripted. It depends on whether you want to use shared keys or just passwords.

I usually make a softlink to any file I have changed into a "transfer" directory, then list the softlinks with ls -l to catch the original file name, and then scp those files to other destinations in one action. (using shared keys)

This requires root privelege coz some files are only root accesible and writeable...

We don't want to use keys and we don't want people to be able to logon as root. Unfortunately on my lab servers when I set "PermitRootLogin=No" root is no longer capable of moving files around, because in order for the "scp -p file root@server:/somewhere" to happen root must logon. In my Orielly book it indicates that SSH1 (even with PermitRootLogin=No) could be configured to permit root remote login access for a specific command (ie ssh -X root@server ls) but not a full logon. The forces people to logon as themselves and su to root so at least you always know "who" is on the system vs's if people can logon as root it can be very difficult to determine who did what. I could use NFS mounts and perl to move files that change but that is messy when you just need to make a simple change to a file and push it to all the servers scp is much better. Also while I can program in perl and shell languages not all of the admins can. So the desire is to keep this simple and what other sysadmins are familiar with.

Thanks,
Mark

Hi mark,

I know what you're trying to do - I've done the same thing and had the same problem. Its all very well doing things manually, but if you've got a file to push out to 200 servers, or a command to run, you can save hours of time by running it from a central point to multiple servers.

One way I got round it was to allow root login, but put some code in root's .profile that blocks logins (the code needs to check the parent process doing the login and just exit if it is ssh, telnet, rsh etc.). You have to be careful, but this can work well.

Another approach you could take is to allow the same thing with a non-root user. This is a lot less flexible (e.g. you can only copy out files where that user has the permissions to write to the directories/files) but is safer and can be used for limited purposes.

Of course, one thing to remember with the root solution is that nothing stops you running rm -r / across all your servers in one command.

Why don't you create a shell script which checks for tasks to be done by a group of machines? For instance you could use perl and it's excellent DBI to query a MySQL database for commands to be done. That way you can easily create a webmanagement area for your servers :-)

Hey Iainr,

I like that idea. I had not thought of that and I have done some similiar stuff with Tier 1's .profiles to limit thier access. I'll give it a shot.

Thanks!!

Hey Markus,

Your idea would work as well....but honestly.....I just think a couple of the other admins would not like giving up their scp ability. So I guess more for political reasons vs's techinical that can't be done........

Why do you want to force changes across the platforms? Can you not
use a DNS style change policy where servers automatically expire their
configs after 'n' days and then recollect the new versions? This would
remove the requirement for root scp at all, all configs could be stored on
a central system under a different user.

Whilst you would sacrifice immediacy, you would gain a lot more stability
and security. Pull rather than push, always easier to maintain.

--
\ /
\/\/ isey

True that is indeed another way of doing things and for items that change regularly we have something like that in place. However, some of the people with a valid "root" requirement are not local and will provide strong opposition to the increased security if we don't facilitate a less intrusive way for them to continue business as usual. So as always security must maintain that balance of "risk vs's requirements".

Thanks,
Mark