openssh unix dev - Mar 2002 - Non-interactive root access via hostbased using shosts.equiv

Hello all!

I'm looking for a solution to the following problem -
I need to be able to use OpenSSH from root on one
system to perform work on several dozen other systems
using some automation.  The restrictions that have to
be met to keep the business happy are that no
cleartext passwords or unencrypted private keys can be
stored on disk.  Since this is within an automated
environment, there is no opportunity for human
intervention to type in passwords or passphrases.

The original intent was to use host-based
authentication via the shosts.equiv file.  This is
essentially a drop-in replacement for what is already
being done, just replacing rsh with OpenSSH.  However,
OpenSSH is hard-coded to *not* check
hosts.equiv/shosts.equiv if the target uid is 0.  It
is possible to get around this by setting
"IgnoreRhosts" to no, and putting a .shosts file in
the root directory, but this has the highly undesired
side-effect of allowing users to create their own
.rhosts/.shosts files as well.

I modified the source to provide a new option
"PermitRootViaHostBased" that would permit the desired
behavior, while leaving the default behavior as-is. 
But there is apparently some reluctance to add these
changes to the official source tree.

I've also suggested making the change conditional via
#ifdef blocks, but this has also met with resistance.

As things stand, I'll be forced to make this
modification locally each and every time we desire to
upgrade OpenSSH, which seems to be counter to what
open source is all about.

So it was suggested that I present the problem to this
list for any other suggestions or comments.  Any and
all comments appreciated!

Joe


__________________________________________________
Do You Yahoo!?
Yahoo! Greetings - send holiday greetings for Easter, Passover
http://greetings.yahoo.com/

You can set up an ssh-agent, add your key(s), and then reference that
agent in any process that needs to make the connection. The only problem
is that if your server gets rebooted, the agent needs to be restarted (and
your passphrase must be entered) before any automated processing can
happen.

Here's how you do that:

ssh-agent > /path/to/store/agent_info_file
. /path/to/store/agent_info_file
ssh-add
(add keys)

Now, any process owned by the user (or, of course, root) who runs the
agent_info_file (which merely sets two environment variables which
reference the socket created by ssh-agent) can access any machine that is
accessible by the keys added. This is, therefore, not all that much more
secure than what you had specified with regards to setting up an
shosts.equiv, except only one user can use the authorization set up in
this manner.

And just to comment on your statement about the enhancement not being
accepted being "... counter to what open source is all about", I would
disagree, in that you are actually doing something which is EXACTLY what
open source is all about - you are modifying the source code to perform a
function that is missing in the original product. The open source notion
does not specify that any and all patches to a product have to be
accepted. If this solution doesn't work for you, you will just have to, as
you pointed out, maintain a patch that you apply to every upgrade. Welcome
to a little piece of the world that the folks who create the portable
version live in all the time (bless them, the poor souls).

Good luck, and let me know if you need better instructions than the lousy
ones I provided above.

			Bill Knox
			Senior Operating Systems Programmer/Analyst
			The MITRE Corporation

On Fri, 29 Mar 2002, Joe Berry wrote:
> Date: Fri, 29 Mar 2002 09:39:53 -0800 (PST)
> From: Joe Berry <jberry02 at yahoo.com>
> To: openssh-unix-dev at mindrot.org
> Subject: Non-interactive root access via hostbased using shosts.equiv
>
> Hello all!
>
> I'm looking for a solution to the following problem -
> I need to be able to use OpenSSH from root on one
> system to perform work on several dozen other systems
> using some automation.  The restrictions that have to
> be met to keep the business happy are that no
> cleartext passwords or unencrypted private keys can be
> stored on disk.  Since this is within an automated
> environment, there is no opportunity for human
> intervention to type in passwords or passphrases.
>
> The original intent was to use host-based
> authentication via the shosts.equiv file.  This is
> essentially a drop-in replacement for what is already
> being done, just replacing rsh with OpenSSH.  However,
> OpenSSH is hard-coded to *not* check
> hosts.equiv/shosts.equiv if the target uid is 0.  It
> is possible to get around this by setting
> "IgnoreRhosts" to no, and putting a .shosts file in
> the root directory, but this has the highly undesired
> side-effect of allowing users to create their own
> .rhosts/.shosts files as well.
>
> I modified the source to provide a new option
> "PermitRootViaHostBased" that would permit the desired
> behavior, while leaving the default behavior as-is.
> But there is apparently some reluctance to add these
> changes to the official source tree.
>
> I've also suggested making the change conditional via
> #ifdef blocks, but this has also met with resistance.
>
> As things stand, I'll be forced to make this
> modification locally each and every time we desire to
> upgrade OpenSSH, which seems to be counter to what
> open source is all about.
>
> So it was suggested that I present the problem to this
> list for any other suggestions or comments.  Any and
> all comments appreciated!
>
> Joe
>
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Greetings - send holiday greetings for Easter, Passover
> http://greetings.yahoo.com/
> _______________________________________________
> openssh-unix-dev at mindrot.org mailing list
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> I'm looking for a solution to the following problem -
> I need to be able to use OpenSSH from root on one
> system to perform work on several dozen other systems
> using some automation.  The restrictions that have to
> be met to keep the business happy are that no
> cleartext passwords or unencrypted private keys can be
> stored on disk.  Since this is within an automated
> environment, there is no opportunity for human
> intervention to type in passwords or passphrases.
Uh, basically you can't do this.  You have to have _some_ sort of
authentication token, and eventually it has to be provided in cleartext to
the processes that use it, either by a human providing or decrypting the
token, or by the token being already available to the system in plain
text.

> The original intent was to use host-based
> authentication via the shosts.equiv file.
Note that the key, the client machine's private host key, is the key you
are using to authenticate, and it is sitting on the disk in plaintext.
This is no different from giving root a regular, per-user (ie,
/root/.ssh/authorized_keys), un-encrypted key, but at least with the
per-user key, you can add restrictions to the key on the server side only
allowing logins from the main client machine, only allowing one or a
small, well-defined set of commands to be run with that key, etc.


 -Jason

 -----------------------------------------------------------------------
 I worry about my child and the Internet all the time, even though she's
 too young to have logged on yet.  Here's what I worry about.  I worry
 that 10 or 15 years from now, she will come to me and say "Daddy, where
 were you when they took freedom of the press away from the Internet?"
	-- Mike Godwin

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (FreeBSD)
Comment: See https://private.idealab.com/public/jason/jason.gpg

iD8DBQE8pQBtswXMWWtptckRApA1AJ9tj2h62nRhKOQcUUHLFTBj1kDaQQCfaq/r
BG/AjfOSfE6aBxuA1TvL2lY=aXSI
-----END PGP SIGNATURE-----