sshd_config 3.8

[kraa26]

Ok I have a question.

Using ssh 3.8, is there a way to let you scp into a server as root but still not let you ssh directly into it? I set the PermitRootLogin to no because I did not want to allow root to directly log in.. but I have some scripts that scp things for DB's and Veritas that I need to run as root.. These scripts are manual and I want to be able to enter the password so I still have authenication..

Anyone have any ideas?

[lil_freak]

Ok I have a question.

Using ssh 3.8, is there a way to let you scp into a server as root but still not let you ssh directly into it? I set the PermitRootLogin to no because I did not want to allow root to directly log in.. but I have some scripts that scp things for DB's and Veritas that I need to run as root.. These scripts are manual and I want to be able to enter the password so I still have authenication..

Anyone have any ideas?

Sad to say but I have had no luck in finding anything to answer your question.

Even my favorite site for ssh wasn't much help, but then again I'm running on empty and am about ready to fall asleep so maybe I missed something.

Here is the site I like to use for help on ssh, maybe you will have better luck finding the information you requested better than I right now:Open ssh

[TheCotMan]

Ok I have a question.

Using ssh 3.8, is there a way to let you scp into a server as root but still not let you ssh directly into it? I set the PermitRootLogin to no because I did not want to allow root to directly log in.. but I have some scripts that scp things for DB's and Veritas that I need to run as root.. These scripts are manual and I want to be able to enter the password so I still have authenication..

Anyone have any ideas?

Oh, this is a bad idea. If Root can scp, but cant (initially) ssh, then whatever you set up as root can be "undone" with scp through overwriting config files, or through other means.

Once root, always root. I cannot state my thoughts to you and discourage you from doing this enough.

However, if you are dead-set on doing this, you can take advantage of the way many *NIX systems deal with control and access as well as shells.

Check out your /etc/passwd file, and you should find root is UID 0. Depending on the *NIX system, UID is effectively root, even if it has another name. If you create another user (e.g. "toor" with UID of 0, you can also set a shell (e.g. /bin/false or something else) and then modify your allowed shells on the system or choose another method to deny interactive login, but yet still allow scp to work.

In this way, you would have two UID=0 entries in /etc/passwd but each could have different homes, different real names and different shells.

Re-stated: This is a bad idea. You probably should not be doing this.

Sub-notes:
On some *NIX systems, attempts to do this can have problems when certain commands are run. They may search the /etc/passwd file and return more than one hit on a query of UID = 0 or return the first one they encounter or return the last one they encounter. As a result, some checks for user name of the user doing things may provide ambiguous resuls. Entries made to various files like wtmp/utmp/process accounting/log files/etc may produce incorrect results saying root was doing one things when it was really toor, or toor was doing something when it was really root.

One last time:
Re-stated: This is a bad idea. You probably should not be doing this.

Good Luck!

[kraa26]

Ok CotMan,

question if not using SCP scripting.. if you have 43 Solaris servers that have all telnet, ftp, direct root login, direct root copy turned off.. how would you update all of them with a few files?

I do NOT want 2 uid 0 ids on any of my systems. I guess I can log into each one with ssh as a normal user, scp over the file, then move the file into place after I have sudo'd to a privilaged user.. BUT.. to do that for 43 systems would take hours..

My take on it then.. is to have a script that might ask me for 43 root passwords.. but put the file into place on all the servers.

I still see no real reason for root to have a direct log into the server.. which is why I have the PermitRootLogin set to no.. but for administration purposes, root SCP is a good way to set up various files and DB's.. PLUS.. you have to already have the RSA key on the server, and the Password before it will let you SCP anyways. so not just anyone can do it....

Only secure server.. is one turned off.. which makes for the perfect paper wieght.

Again, this is a good example of security vs administration.. and still have good security..

[TheCotMan]

Ok CotMan,

question if not using SCP scripting.. if you have 43 Solaris servers that have all telnet, ftp, direct root login, direct root copy turned off.. how would you update all of them with a few files?

I do NOT want 2 uid 0 ids on any of my systems. I guess I can log into each one with ssh as a normal user, scp over the file, then move the file into place after I have sudo'd to a privilaged user.. BUT.. to do that for 43 systems would take hours..

My take on it then.. is to have a script that might ask me for 43 root passwords.. but put the file into place on all the servers.

I still see no real reason for root to have a direct log into the server.. which is why I have the PermitRootLogin set to no.. but for administration purposes, root SCP is a good way to set up various files and DB's.. PLUS.. you have to already have the RSA key on the server, and the Password before it will let you SCP anyways. so not just anyone can do it....

Only secure server.. is one turned off.. which makes for the perfect paper wieght.

Again, this is a good example of security vs administration.. and still have good security..

Why not consider client-pull with automated scripting, or maybe rsync from the clients at periodic intervals?

In this way, each server can have its root user scp from another server with remote user being non-priv.

You locate those patches which you know will work in specific dirs. When the clients select to get new updates, they get only the files in these dirs and can be scheduled to apply fixes.

If you have a sufficient test lab, you can find how the patches work when applied and automate them.

Results of each update for each server would then be mailed to you.

Use of bigbrother would let you know if any services were not working as expected.

This is the route I would take.

Client pull vs server push. Both can be used to solve similar problems.

[Added content:]

Of course, with the above example, you would have the central server not allow remote logins, and have no other services, and no other users to protect its scripts and updates which would be distributed.

[More added content]

You could also gpg sign the scripts you distribute and have the clients download this from the server to verify that a person with your passphrase actually signed the scripts to be run or files to be installed.

[g-clef]

Expect?

If you're okay with keeping a file with login names and passwords lying around (which, it appears you are), why not use expect? If you're not familiar with it, expect is a scripting language that's designed for this sort of thing. You can tell it (effectively):
expect "login:"
send "$username"
expect "password:"
send "$password"
expect "#"

etc, etc. Just write a script that will run the commands you want against the devices you have one by one.

Rancid (www.shrubbery.net/rancid) uses expect heavily for this sort of thing, as well (logging into routers/switches and running commands). It works pretty well, though some seem to think that expect is a language spawned from hell itself.

[skroo]

question if not using SCP scripting.. if you have 43 Solaris servers that have all telnet, ftp, direct root login, direct root copy turned off.. how would you update all of them with a few files?

Shared certificates between the box pushing the updates and the boxes receiving them; this way, scp can be scripted as a regular user to log in to each box in turn without requiring interactive login.

A cron job running as root on the receiving boxes checks every x amount of time for the presence of the new file, moves it to its correct location, and chown/chmods it as necessary.

See http://www.linuxgazette.com/node/view/193 for some ideas.

I do NOT want 2 uid 0 ids on any of my systems.

There ya go. No need for root login, stored passwords, etc.