experiences with openssh automation

[Robert Brockway]

On Tue, 9 Aug 2005, Mike Kallies wrote:

[Refering to alternatives to using ssh to get access to /etc/shadow]

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

LDAPS, NIS+ (the latter is hard to set up).

NIS is easy to setup but not secure.

> 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... )

I prefer to encourage the use of ssh through a user a/c and additional 
authentication to get root.  IMHO it should be a bit annoying to get root.  
It's easy for an admin to get lazy and do stuff as root that could be done 
through an unprivileged account.

> 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

Directly over ssh - yes.  Brute force attacks on ssh are very common 
today as many of us know.

> impossible.  The private key would have to be guessed for brute force to
> work.

And the passphrase if there is one.  With a strong passphrase in place 
this is considered an intractible problem with 1024bit RSA keys today.

> 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.

They sure can.  I do patching manually everywhere.  For one thing very few 
vendors are doing security patching properly - where you can be sure the 
box will just get the updates it needs.  I've seen many a vendor break 
functionality on supposedly safe security updates.

I rarely touch MS-Windows and I can understand MS-Windows admins needing 
to patch large numbers of workstations.  I strongly support the use of 
thin clients in the unix environment, one of the reasons being the reduced 
admin overhead (no patching of workstations :)  There are other reasons 
too.  http://www.opentrend.net goes into this a bit but we plan to add 
more information on thin clients.

In cases where the number of boxes is very large or where backend servers 
are being built and rebuild (eg, for testing) I usually use something like 
kickstart or jumpstart.

IMHO if the number of individual (unix) servers is so large that it is 
infeasible for the admins to do manual security updates then they probably 
need to expand the admin team since they are probably lacking the staff to 
do proper administration as well.

Cheers,

Rob

-- 
Robert Brockway B.Sc.		Phone:	+1-416-669-3073
Senior Technical Consultant	Email:	support-wgAaPJgzrDxH4x6Dk/4f9A at public.gmane.org
OpenTrend Solutions Ltd.	Web:	www.opentrend.net
We are open 24x7x365 for technical support.  Call us in a crisis.
--
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