Re: Is SSH worth it??

[David Corking <david.corking2 () dol net>]

Sorry for late response --- but I just noticed that one of your
questions was not yet answered.

On Tue, 08 Oct 2002, Trevor Cushen wrote:

> We would be using SSH and SCP.  SCP for automated scripts.  To get
> scripts automated my understanding is that the best security in this
> scenerio is use RSA authentication only. 

'Best' seems to be the consensus -- but as far as I understand even
password-based ssh (protocol v 2) is safe from sniffing and needs
brute force to compromise -- a penetration tester please correct me if
I'm wrong.

> Thus no password request when
> I do 'scp host:file filedst'.  But then does that mean that my SSH
> client will not be prompted for a password.  

Yes.  (no password prompts also makes it easy to use ssh in pipelines,
such as 
cat /dev/cdrom | ssh david@burnerhost "cdrecord dev=1,0,0 - "
 that burns to a remote burner ** )

> In that case accountability
> is at the machine level.  If I am wrong please inform me gently as I

No you are wrong.  Accountability is still at the user account
level. The reason is that 'scp host:file filedst' is actually an implied 
'scp user@host:file filedst' where 'user' is the user on the client
machine.

Your duty (whether you have scp or rcp) is to ensure that "user" on
the server machine has minimum necessary privileges (they can, and
probably should, be very different to the privileges on the client
machines.  Hopefully your predecessors took care of this when they
implemented rsh/rcp.)

Important thing to remember is that both the ssh and scp client
commands are designed to be exact drop-in replacements for rsh and
rcp.  Maybe there are exceptions but that is something easy to
test with your scripts on the testbed.

> I am currently installing a SCO machine, Solaris machine and NT machine
> to set all this up and emulate the site as much as possible.  I will
> post the final result in time.

Many security consultants have practical ssh experience, so given that
your client takes this seriously, it might profit you to subcontract a
few hours consulting time to get this right (there are a number of
other pitfalls* and a lot of docs to read -- it is easy for a newbie
to connect together a few servers for remote interactive admin -- but
a little harder to convince yourself and your customer that a network
of automated remote scripts is as secure as it can be, and make it
work first time.)

* Mistakes I made as a recent newbie, or that I saw in mailing
lists and even cookbooks, included :-
not disabling protocol v1 fallback,
not disabling fallbacks to unintended auth methods, 
more than minimum privileges on remote machine (for example to do a
root backup -- you could give the backup server root access to the
remote machine, but imho it is better to swap client+server and give
the remote machine write access only to a private directory on the
backup host), 
leaving private keys in accessible places (or incorrectly automating
key distribution),
not knowing if keyboard-interactive was disabled when the notorious
undisclosed bug warning came out this summer, 
even generating key-pair files with the wrong tools (it took me 30
minutes after ssh failed to connect to find the docs that said that
the key files I made with puttygen would not work on an openssh
server.)
The consequences of these mistakes would be enough to convince me to spend
dollars on getting help with the design you propose, until I can grow
and maintain same experience.  Your mileage may vary --  but I have no
doubt that done correctly it will be cost-effective enhancement to an
otherwise secure network.

** the pipeline is easy to use which is the charm of ssh to me, but you
   could say it violates my rule of minimum privileges, since cdrecord
   is suid.

David