Subject: Re: ssh - are you nuts?!?
To: None <firstname.lastname@example.org>
From: Simon J. Gerraty <email@example.com>
Date: 12/21/2000 00:27:20
> opentrax writes:
> > SSH does a reasonable job, it supports RSA, and TIS, and even passwd.
> > The other forms don't interest me.
> Okay, then you are stating that while authentication can be
> an issue, you believe that SSH is doing a "reasonable job";
> especially by offering such options as RSA and TIS.
> Is that correct?
That's pretty much what I said. I don't find the RSA key management
of SSHv1 particularly scalable, but it is almost trivial to setup and
"does the job". Setting up and running CA's etc is hard by
comparison so unless you have 1000's of users SSHv1 is probably ahead.
> > 2. I have to interwork with a bunch of different sites, they've all
> > invented their own "*telnet". So I have N different clients and
> > servers to install and maintain if I want to have secure
> > communications outside of my own net.
> It a good point. I'd qualify it as a reason for SSH.
> But, That follows with the assumption that if you have
> N different clients and servers, each has been "tweaked"
> by someone other than yourself.
> Isn't that a schenario issue with SSH also?
No, because you don't need a differen "tweaked" SSH version to talk to
each site you deal with. SSH is capable enough that tweaking it is
largely unnecessary. The only hack I recall doing to it is modifying
SSHD so that if authentication as user "foo" fails, check if the RSA
key would be able to authenticate as "root" and if so allow it to be
"foo". This allows you to "scp file foo@dest" without needing to
replicate authorized_keys accross every account on the box.
I think I also modified it to ask the TIS authsrv if X11 forwarding
should be allowed. Neither of these changes impact the protocol or
the client in any way.
> > I'm talking about certs as used in SSL, there need be no single point
> > of failure. I don't like the cert based authentication schemes that
> > rely on a directory server to hold all the public keys - they are
> > generally designed by people who sell directory server's. The only
> > advantage they can offer is semi-real time checking if a cert has been
> > revoked. Publishing CRL's is after all the big headache faced by
> > most PKI solutions.
> Can you expand on these "Publishing CRL" issues? Or at least
> point me in the direction of more information?
A CRL is a Certificate Revocation List. You validate the cert you've
been handed and if all looks cool you try to find its serial number in
the latest CRL available from the issuer. The CRL is available either
in a file on local disk, from a URL or via lookup in a directory.
When using local files - as supported by OpenSSL, there are 4 possible
results, my SSLrshd deals with them thus:
* 1 we cannot find a CRL for issuer, return 0
Assumption is that site doesn't care about CRL's so they probably
consider the user authenticated.
* 2 we have a CRL which revokes xs, return -2
Pretty unambiguous. Note that in this case we don't care whether the
CLR is current or not.
* 3 we have an expired CRL for issuer which does not revoke xs,
* return -1
* 4 we have a valid CRL for issuer which does not revoke xs,
* return 1
In both these cases, there is a risk that the certificate may have
been revoked since the CRL was published - even if it was published an
The only sure way to know that the cert has not been revoked is to
query the issuer's directory dynamically. This does not scale well at
Perhaps when we have secure DNS available, one could use it to do the
> Okay, for the sake of arguement. I'll concide that, perhaps
> many passwords on ALL users may not be effective.
> But for System Admins, that would almost seem a must.
> Would you agree?
Not really. I only allow root logins via the console or via SSH or
stelnet. Both SSH and stelnet allow multiple keys to authenticate as
root. On many of my systems the root account is the only one that has a
password - all the others just have 'x', so can only be used via SSH
or stelnet and root can only login on the console. Mind you I also
have systems setup where every user is root (firewall bastions where
normal users have no place), but normally I use sudo or su accounts
(foo can login as foosu for rootly powers) both schemes avoid the need
to propagate the root password widely.