securely set environment variables per user

[Nico Kadel-Garcia]

On Tue, Aug 7, 2012 at 6:44 PM, Christoph Anton Mitterer
<calestyo at scientia.net> wrote:
> On Tue, 2012-08-07 at 18:37 -0400, Nico Kadel-Garcia wrote:
>> That's not an SSH problem. That's a shell environment problem.
> Well in principle I wanted to avoid using any shell... this means just
> more forking and so on... and I really need to squeeze out the
> microseconds ;-)

>> Why are you trying to do this?
> What exactly do you mean? Setting a path?
> Well I use the whole thing for Icinga/Nagios remote check commands...
> The check_plugins are typically not in the standard PATH, but something
> like /usr/lib/nagios/pluings...
> And it would be nice if the client side could run the plugins by:
> ssh host check_foo
> instead of
> ssh host /usr/lib/nagios/pluings/check_foo

> And yes this is actually more than just a cosmetic difference.
> Cause later on, the whole command string will be used by Icinga/Nagios
> (well actually by PNP4Nagios) for some matching.... and the prefix
> "/usr/lib/nagios/pluings/" makes everything more complicated (and
> resource intensive).

*Oh*. That one. But Christoph, those are typically going through a
shell account *anyway*. You should be able to manipulate
~nagios/.bashrc, or ~nagios/.profile, to add the relevant element to
the PATH on the clients.

If you really want to make the paths consistently accessible, consider
using a designated symlink target: "/usr/local/libexec/nagios/plugins"
and linking in the components on all your clients. I do this to mix
and match system provided and locally built versions of Nagios checks
as needed.

I do urge you to look at NRPE rather than OpenSSH for this, which also
tends to be a bit lighter weight for the Nagios server and Nagios
targets than handling thousands of SSH connections every 5 minuts. It
also tends to be more secure in configuration: NRPE is normally
configured not to allow arbitrary command line arguments, and locking
down the permitted SSH commands for Nagios access can be.... a real
adventure. I've seen way too many people saying their hosts are
*secure* while leaving a passphrase free SSH key for Nagios access
lying around, and leaving it availble not only for unfettered shell
access but even granting extensive "sudo" access to check the details
of system status or to allow traps for handling failures reported by
Nagios.


> Cheers,
> Chris.
>
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>