experiences with openssh automation

[Mike Kallies]

On Tue, August 9, 2005 2:24 am, Robert Brockway said:
> On Mon, 8 Aug 2005, Mike Kallies wrote:
>
>> 1.  Is there a way to programmatically update the host key identifier?
>
> Yes as Frank points out.  But you have to ask yourself if this is a path
> you want to follow.  The host key identifier is there for a reason.  In
> particular it helps to prevent man-in-the-middle attacks.

Frank's comments solve one of my problems.  This is only for situations
where a clump of known-new servers are introduced into the network and the
host keys need to be added to the database.  For general operation, host
key checking is in place and won't be ignored.

>> I never had such problems with rsh...
>
> You never had any security with rsh either :)

True, but I'm referring to the problem where ssh freezes indefinately
because of a bad sshd on a target server.  I would hope that the OpenSSH
client could timeout.

Hmmm...  not sure why I didn't see this earlier:

ServerAliveInterval
      Sets a timeout interval in seconds after which if no data has
      been received from the server, ssh will send a message through
      the encrypted channel to request a response from the server.  The
      default is 0, indicating that these messages will not be sent to
      the server.  This option applies to protocol version 2 only.


http://www.openbsd.org/cgi-bin/man.cgi?query=ssh_config

I think describing the problem might have solved it.  I'll follow up later
with my results.

...

> IMHO if you have so many boxes that auditing /etc/shadow can't be done
> manually you need to look at some other form of authentication.  Allowing
> automated access via ssh to an account that can sudo to root is just
> opening a window for exploitation.

I've heard this argument many times, but I've never heard of any
alternatives.

Remote root access from ssh is risky somehow because the root account is
common. (IMHO it's not such a big deal because you can force key-only
authentication for root and spare everyone a lot of trouble... )

Remote access with a non-root account which has root-like priviliges
through sudo is supposedly less risky because no password authentication
is possible, making brute force password attacks on the account
impossible.  The private key would have to be guessed for brute force to
work.

It can be secured further by setting up the authorized_keys file to only
allow access from known IP addresses.

The only real danger as I can tell is if your automation servers are
compromised... but that's unavoidable.  If you need to have central
servers from which you can install updates or monitor systems, those same
servers can be used to install trojans or steal data.

To protect against people stealing backup tapes,  the private key can be
encrypted by using a key agent to ask for the passphrase on the automation
server at boot time... the private key is only ever decrypted to volatile
system memory.

For a very well-understood environment, like a cluster farm, I could see a
situation where the servers could all be configured to report status,
operational and security data without relying on a central server to poll,
e.g. email everything you need PGP encrypted through SMTP,  but there will
still be a risk when a central server offers security updates, whether
they're pulled or pushed... so there's no difference.

I can't conceive of any other models, I don't know how any other tools
would be any better.


-Mike


--
The Toronto Linux Users Group.      Meetings: http://tlug.ss.org
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://tlug.ss.org/subscribe.shtml