Remotely executing commands

[James Mohr]

Hi All!

I am looking for a way other than ssh, rexec, rsh, etc to execute commands remotely. Because of the enviroment we are in, it is unlikely we would be allowed to open up the necessary ports and install the necessary software.

Even if we did get get permission for something like ssh, my boss is afraid that when we get audited, the fact that we are running ssh all over the place would make the auditor look too carefully at the system and find something else he didn't like (even if ssh was "100%" safe). My boss feels "safer" with an extra agent as he feels that an "uncommon" agent" (i.e. VPO's control/action agent) is less likely to raise eyebrows than ssh, for example.

So the bottom line is that we are looking for a remote execution tool where we can restrict what is started on the remote end.

Even though it is is unlikely that we will be able to open ssh to all of the machines in questions, I did a little investigation on ssh and came up with some things that might help get authorization.

I have looked into the subsystems one can include in /etc/ssh/sshd_config., which allows one to start things more easily. However, I cannot see where it says (it at all) that you can start **only** what is listed as a a sub-system.

The background is that we need to move several KB of data from one machine to another. One restriction is the level of security in our environment, so something like ftp or even http would not be allowed. We would definitely have trouble getting permission to activate ssh unless there was a sure-fire way to limit what applications could be started.

I looked into the 'forced-commands-only' option, but that seems only to apply to root. Is there a way to specify it for another user. I also looked authorized_keys, which lets you specify specific commands for specific users. However, it was not clear to me if this was an "all or nothing" deal. That is, can one user login interactively using ssh while another can only execute a specific command remotely.

The bottom line is that I need to limit what one user can execute remotely, while at the same time letting another interactively. Any suggestion or info is greatly appreaciated.

Regards,

jimmo

[Ivan Ferreira · Accepted solution]

I think that SSH will be the securest option. Using another product will give you a false sense of security.

You can use bash restricted shell to restrict what can be done on your system.

See:

http://www.network-theory.co.uk/docs/bashref/bashref_68.html

You can configure the .bash_profile, put an exit in the profile, so the user wont be able to start a session, but will be allowed to run remote commands.

[James Mohr]

Hi Ivan!

Ever read Dilbert?

Since I wrote the message I had a long talk with co-worker and we both agree that "SSH will be the securest option". In short my boss is not really interested in what is more secure, just what will "raise eyebrows". Personally, I feel that if the auditor really knows what he is doing and sees all of the things we have done to restrict access, then he will be happer with a known application like ssh.

I hadn't thought about the rbash. That definately does look like an extra security feature.

Regards,

jimmo

[Raj D.]

Hi James ,

Try to use Putty , and its a secure one , it uses ssh and other tolls as well , and well organized.

http://the.earth.li/~sgtatham/putty/latest/x86/putty.exe

Cheers,
Raj.

[Stuart Browne]

James,

I'm going to back up what Ivan said.

If you want secure, remote execution, you *ONLY* option is SSH.

Using firewalls to to dissallow access from remote sources, restricted shell, as well as clever user management (user can only do given tasks, regardless of how they are accessing the machine), couple that with only allowing 1024 bit DSA key exchanging for authentication (i.e. don't give the user account a password, and *lock* the account) further restricts access.

Just as an aside, if you aren't currently running SSH on your servers, how are you administering them?

[Nils_9]

To my mind, ssh is the better way to get remote and secure access to your machine. Iptables rules can be useful if you are afraid of having a lot of connection tries. But you can change the port, as an example, sshd on Ipcop listen on port 222, but you can choose another port that isn't used by another protocol/application.

Or maybe you can try Webmin. I like Webmin very much, as I can access it when using a proxy (I redirect Webmin's port to 443 to bypass the proxy).

[Gopi Sekar]

I am also of the opinion that SSH is the securest way for anything. Plus if you really want to restrict what can be started even from SSH, then all you can done is create a shell script (or any other script of your choice) which lists the commands in orderly fashion (like 1. ls, 2. ps etc) so the user has to simply enter the number and get the command running for him.

Put this program as the home shell for the user id (check /etc/passwd for shell option). that way the moment user comes out of the program he will be logged out automatically.


Regards,
Gopi

[James Mohr]

We are using ssd to administer the systems, but we need to hop between several others, going deeping and deeper into the customer's zone. What we are looking for now is a way to get data out directly from a central machine. Since sshd is already running, there is are no new ports, plus all of the other wonderful security aspects. Although my boss doesn't have pointy hair, he does make a lot of dilbert-ess comments.

We just had a meeting and instead of accepting the recommendation to use ssh, he wants us to look into building our own client-server application.

regards,

jimmo

[Gopi Sekar]

mm but when you write your own client/server there will be enough reasons to make mistakes and leave security holes (buffer overflows etc).

you may have to point this to your boss and tell him that it is better to go for SSH since it keeps getting updated for all security issues and the source code is continuously verified by people all around the world.

Regards,
Gopi

[Jared Middleton]

James wrote:
> The background is that we need to move
> several KB of data from one machine to
> another. One restriction is the level of
> security in our environment, so something
> like ftp or even http would not be
> allowed.

What about using rsync over ssh protocol, "rsync -e ssh"?

Jared

[Stuart Browne]

Also don't forget that you can move ssh onto a non-standard port, along with firewalling *shrug*.

I think your boss needs a quick, severe lesson in system security.

DONT REINVENT THE BLOODY WHEEL 'CAUSE YOU DONT UNDERSTAND WHAT A SPOKE IS!

*NOTHING* you'll be able to write within a cost effective time period will have the security benifits of the existing openssh implementation.

[dirk dierickx]

WHAT?! your boss is an idiot! He would trust the VPO agent above the SSH daemon, that is just plain crazy.

what is the difference of getting another 'tool' for remote commands, if SSH is not good enough nothing probably will. if you can not get the default ports for ssh open, you can configure it to use another port so it can suit your environment.

if you are scared of an auditor tripping over ssh (i wouldn't know why), rename the sshd file to something else and it will show this name in the process list (ps). but that is just silly.

[Paul Cross_1]

All I can do is backup what has already been said up there ^. Writing your own client/server application is rediculous. Two heads are better than one. While I'm sure you have smart people working there, the opensource community as a whole has a far greater chance of catching/fixing bugs than a local IT shop. Ssh is built on a known standard anyway, with many many years of development behind it.

There is also a commercial ssh product available (ssh.com) with support and blah blah blah if you manager feels that paying for something somehow will make it more secure.

-Paul.

[Paul Cross_1]

On the other hand, since your boss is "dilbert-esque" just come up with a suitable solution such as: recompile openssh under a different name. ihsd (in house secure daemon). He'll be happy as hell.

-paul