Thanks for Paolo and Ivan for the great solutions. # mrs
On 6/22/06, Ivan A. Beveridge <[EMAIL PROTECTED]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 12/06/2006 14:19, Paolo Lucente wrote: > > One day Pedro shall really update his Cacti document about this point. Cacti > > requires to read output of the executed command; you can "wrap" your command > > with anything required to spawn remote commands as long as the wrapper is > > transparent. This means that you can use rsh or ssh (together with a key > > pair, > > in order to avoid the ugly password prompt) to fit the job. > > Using keypairs is more secure (primarily) ... > > > remotely - encrypted) > > shell> ssh [EMAIL PROTECTED] pmacct -s > > > > You can also get encryption by pre-arranging tunnels with stunnel. Just few > > pointers. Any thoughts ? > > You shouldn't use rsh any more (for security reasons) .. period. ssh is > able to cover all the required functionality (assuming you don't > consider "the ability for someone else to sniff your traffic" as > required functionality ;). > > You can tie down ssh access fairly tightly, for a given login/key. Read > the sshd manpage, but some things you may like to do/consider are: > 1) restrict the IP address that the key is to be used from (eg if your > script will always be running from the same IP) [from="pattern-list"] > 2) disallow "interactive shell" [no-pty] > 3) restrict the command to be run [command="command"] > 4) use a key without a passphrase (in combination with above) > 5) use ssh-agent type app to "keep authentication in RAM". > > 1-3 can be specified in the ~.ssh/authorized_keys file for the > particular user on the router. If you have added such security, you may > feel happy-ish not supplying a passphrase (4) to the key (as the user > will only be able to connect from the specified IP and run the specified > command); you will, however, want to make sure that the private key is > fairly secure in that case. It can be argued both ways that (5) is more > or similarly secure compared to (4), but it means that if your stats box > reboots you need to manually run the agent again. > > By "restricting the command to be run", you just have to "ssh > routername" and it will run the command & exit. You could do something > similar (but perhaps less secure) by running the command as the login shell. > > NOTE: the above does not restrict ssh access for all users (just this > particular key). If you want to be more strict, you could run a separate > sshd on a different port with a restrictive sshd_config (see man > sshd_config), and then disallow people from logging into the main sshd > as your router-user (see "DenyUsers" in man sshd_config). > > I have done similar things (a script needing to login to a remote box to > run a single command), and so it is why I've investigated the above :) > > If you want the same router-user to be able to run different restricted > commands, you _may_ be able to use a different ssh-keypair for each > command (untested). > > This isn't particular to pmacct/cacti/etc, but it may be a useful > pointer if you've not considered security matters/implications. > > Hope that helps. Now, please wait whilst normal service resumes ;) > > Cheers > > > Ivan > P.S. I haven't written a procedure for the above because I don't know > what exact commands will be wanted. If I wrote much more it would even > read like the sshd manpage ;) > - -- > Ivan Beveridge > <[EMAIL PROTECTED]> http://www.linx.net/ > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.1 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFEmZFIQQZN5jq7vncRAnVAAJ0ZqEYLyTxYCCxkWMvqWuLh5XgAHwCfSbTt > QhJuGxV2aJPQVSSUgYj9fOE= > =Mw7u > -----END PGP SIGNATURE----- > > _______________________________________________ > pmacct-discussion mailing list > http://www.pmacct.net/#mailinglists > _______________________________________________ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists
