|
Anonymous Monk has asked for the wisdom of the Perl Monks concerning the following question:
I need to run perl scripts with sticky bit set and ssh to
other server and pull out all sorts of information, like
process info etc, etc.
The problem is, running the script from command line, that I'm
prompted for password which I don't want to have.
Anybody know how to get around this, i.e. the command
will run and log the output without prompting for a password?
Thanks! |
Re: perl & ssh
by azatoth (Curate) on Aug 16, 2001 at 16:26 UTC
|
| [reply] |
|
|
Hi Captain Whiplash.
OK, thanks, that works fine!
Updated the known_hosts file locally
and authorized_keys at the other end.
Another question: I've now created a
web interface where I can click on
different buttons and to gather information
from remote server and I also should
be able to stop/start deamons. I would
need to be able to switch to root while
running the script on remote machine.
At the moment it fails (of course) because
the effective user is nobody and I would
need to be able to switch users to root.
Any ways around this? Or is this too dangerous.
Thanks!
| [reply] |
|
|
| [reply] |
|
|
| [reply] |
Re: perl & ssh
by Anonymous Monk on Aug 16, 2001 at 21:26 UTC
|
My oh my. I pity the original poster as some of the replies here are confusing several concepts into one big mess of crap.
As it appears to me the intent of the original author is to:
1. Create a web-based administration interface
2. Use this interface to cause the execution of root privileged commands on a machine other than the webserver
3. Do so in a manner that is "secure"
To accomplish this, the author is asking how to perform items 2 and 3 without the need to specify a password or any other type of manual intervention in the authentication process.
To the original author, what you are doing is reasonable, but you need to consider several things to ensure that your system can't be easily abuse to exploited:
- How to prevent an authorized user from escalating their privileges. I've seen several CGI applications that use hidden fields to key actions. These hidden fields are then passed to an action script which blindly trusts its passed parameters. There is nothing to stop an attacker from modifying the form and posting it to the action script to do bad things. A simple fix is to include some kind of secret-derived value, such as an HMAC of the form variables plus a secret key, when you post to the action script. Have the action script check this result to make sure bad things aren't taking place. Check out Digest::HMAC.
- Intermediate files create race conditions! This may not be an issue for your particular case but be wary. Particularly since you would have a root privileged process making decisions based on the contents of the file.
Now to deal with your need for remote execution. There are a couple of ways you can do this:
1. Have your script issue the remote commands directly to the remote host. This seems to be the path your are already on using SSH.
2. Run a process on the remote machine that listens on a port and processes requests as they come in.
3. Use something like Rexec or Rsh
Don't do option 3; it's security nightmare. Option 1 is fine and it seems that what you're already trying to do via SSH. If you can get the password issues worked out that's fine however you are giving a script full-blown account access. From your follow-ups it looks as if you are doing this via an RSA key without a password. That's a _lot_ of trust for the machines and processes. Security principals dictate that we minimize privileges and trust. If you choose to do it this way, limit the account's privileges with sudo or something similar. Also strongly consider using tcp_wrappers to provide additional fine-grained access control to the SSH processes.
I would suggest you also consider option 2. The password/account issues goes away. Instead, you will need to create a small daemon on the remote end that listens for requests from the web script. This daemon has a list of actions it will perform and no more. To protect this channel you can utilize a blizzard of options. Since confidentiality for this connection is not a concern utilize a scheme similar to the one I described above: a shared secret between the daemon and the CGI process that is used to key an HMAC of the request.
I just previewed my response and realized how long it's become so I'll stop now. The whole reason I can write this much is because I have both screwed-up and taken advantage of many screw-ups related to remote command execution. Just understand that because it's on an "internal" network doesn't mean you can trust that network or drop your guard.
| [reply] |
Re: perl & ssh
by Tuna (Friar) on Aug 16, 2001 at 20:31 UTC
|
Here's what I do:
Copy the contents of the user's identity.pub on the local machine, and append it to that user's authorized_keys file on the remote machine.
Then, I run an instance of sshd, as that user, and define an obscure port to connect to. You will need to create an sshd_config_<user>, and tell sshd to use that file. | [reply] |
Re: perl & ssh
by trantor (Chaplain) on Aug 16, 2001 at 17:31 UTC
|
I can't see why you need ssh if you don't want to have passwords...
To me this looks like giving to a third party the possibility to login
remotely to another server doing whatever they want. And the nice bit is that the
third party can't even be eavesdropped :-)
I'm not criticizing your choice, you might have good reasons to do it (very good reasons, I hope),
but at this point you can simplify your life and use Net::Rexec or similar, keeping your keys
safe with a password (because you might use them for other connections as well).
Happy remote execution! (No pun intended)
-- TMTOWTDI
| [reply] |
|
|
Fellow monks!
Lets not get confused between using public key authentication to enter a machine and having no passwords. The public key authentication is just as secure as the originating account. Keep in mind that in order to ssh into the remote machine the account on the far end needs to have the originating user's identity.pub in their authorized_keys file. Rather than using passphrases, you're using key exchange as authentication. Its still considered very secure. If any other user attempts to ssh into the remote machine, they will still be prompted for a username/passphrase pair. The risk you run is letting someone else get your public key. However, protecting it is fairly easy and no less complicated than choosing a good password that you don't keep under your mousepad on a sticky note. You may want to check out Univ. of Michigan's documentation on exactly what we're talking about and the risks associated with it.
As far as Rexec goes, I dont believe that Rexec is encrypted traffic, which, if we're nitpicking, would cause most infosec people to gasp out loud. Sure it can be encrypted just like rsync using ssh as the transport. So why not just use ssh to begin with?
To the original poster, if you need the user logging in to the remote box to issue superuser level commands, you might want to look into using sudo. Here is a pretty good and complete guide on using it. Once you get into this arena, you will also need to be careful about what sudo permission you allow the account that ssh's into the machine, so you're back to square one when it comes to planning your security measures, but so goes the business.
I read that Security and Convenience are inversely proportional. You'll have to be the one to decide where you draw the line at convenience and sleeping well at night.
humbly -c
| [reply] |
|
|
It's a shame i'm limited to give you only ++.
:)
honestly. Some responses need a (rep++)++ option. :)
| [reply] |
|
|
I can't see why you need ssh if you don't want to have passwords...
To me this looks like giving to a third party the possibility to login
remotely to another server doing whatever they want. And the nice bit is that the
third party can't even be eavesdropped :-)
This is true only so long as the third party already has access to your account on the local machine. If they do, chances are a keylogger wouldn't be too hard a thing to use in case you weren't using public key encryption to authenticate to another box. That way, they still have access, and you are none the wiser. Besides, ssh logs pretty thoroughly.
If you don't trust public key encryption, remember never to trust SSL or TLS on a web site. Secure shell is no different.
Chris
| [reply] |
|
|
Hi Trantor,
Sorry, forgot to mention that the web page is
passwd protected and limited to only few users.
I'm doing all this within intranet and our
security team strongly suggests us using ssh/scp/sftp
for any interaction between different servers.
I'm now looking at he net::rexec stuff, the reason
I would need to run as root is that other department
has deamons running on the server which they own and
I'm trying to offer them access to the box remotely
and only allow to start/stop certain deamons. sudo
would've been another solution but I would like to
do it perl-way, not very good at it yet but will try
my best and see how it will go.
Thanks!
| [reply] |
Re: perl & ssh
by scottstef (Curate) on Aug 16, 2001 at 17:21 UTC
|
I could be wrong, but trying to login to a machine without passwords is usually considered cracking and is usually illegal.
Edit:I did not completely comprehend what the question was asking. Please ignore my remark. I will never again attempt to respond to without a morning cup of coffee.
"The social dynamics of the net are a direct consequence of the fact that nobody has yet developed a Remote Strangulation Protocol." -- Larry
Wall | [reply] |
|
|
What the heck are you smoking.
He's not trying to bypass any security measures to enter a system he doesn't have access to.
Entering a machine without a password is not considered cracking. For example. Every webpage hit is accessing files on a remote system, usually without a password.
Obviously, all this person wants to do is connect to one of his own boxes with ssh (which requires some form of authentication). To do this autonomously requires that you not have to do local authentication to your public key.
SSH can do public key authentication, which is both more secure than password authentication, and also provides for an additional layer of authentication at the local level. To connect to a box with ssh && public key authentication, usually you password your public key so that only you can use that file to connect.
Unfortunately for standard automation, most public keys have to have null passwords. Any web server, for example, that runs SSL usually has this local layer of passwords omitted from it's configuration so that the server can start on its own, rather than requiring you to manually enter the password each time you want to bring the server up. To monitor disk usage and processor information without providing it to the entire world, you have very little option other than to use ssh, public key authentication, and a public key with a null passphrase.
As was said before, use ssh-keygen and don't specify a passphrase.
| [reply] |
|
|
