Mailing List Archive

Ola@Sigurdson.SE said:
> I'm sure there is a rationale for binding the ssh client to a
> priviledged port. (Which?)

If you are doing rsh like authentication (you trust the host (having
authenticated the host), on the identity of the user as opposed to
making the user authenticate with his own keys), then you need to be
able to read the host key (that requires root normally). Tied in with
that is the server expects connections from trusted hosts should be
originated from priv ports.

You can just knock the SUID bit off ssh if you use only user based keys
and/or password authentication, and do not use host based
authentication.

Nigel.

--
[. - Opinions expressed are personal and may not be shared by VData - ]
[ Nigel Metheringham Nigel.Metheringham@VData.co.uk ]
[ Phone: +44 1423 850000 Fax +44 1423 858866 ]

On Mon, Feb 14, 2000 at 01:54:00PM +0100, Ola Sigurdson wrote:
> I'm sure there is a rationale for binding the ssh client to a
> priviledged port. (Which?)

for rhosts/rhosts-rsa authentication the server has to trust the
username supplied by the client program.

the client is only trusted if it runs as root and 'shows' its
privileges by binding to a random low port.

you can turn this behaviour of with:
Host *
UsePrivilegedPort no
or
Host *
RhostsAuthentication no
RhostsRSAAuthentication no

-markus

Well, yes I know how to turn it off.

What I'm saying is that suid should be turned off by default as it will
cause problems for a large subset of sites who only want to use ssh as a
secure telnet replacement.

(If you want to allow automatic logins without passwords you anyway have
some serious thinking and configuration to do. Turning on the suid bit
is not that big a deal in that case. From ssh.1: /etc/hosts.equiv,
.rhosts, and the rlogin/rsh protocol in general, are inherently insecure
and should be disabled if security is desired. )

Markus Friedl wrote:
>
> On Mon, Feb 14, 2000 at 01:54:00PM +0100, Ola Sigurdson wrote:
> > I'm sure there is a rationale for binding the ssh client to a
> > priviledged port. (Which?)
>
> for rhosts/rhosts-rsa authentication the server has to trust the
> username supplied by the client program.
>
> the client is only trusted if it runs as root and 'shows' its
> privileges by binding to a random low port.
>
> you can turn this behaviour of with:
> Host *
> UsePrivilegedPort no
> or
> Host *
> RhostsAuthentication no
> RhostsRSAAuthentication no
>
> -markus

On Mon, Feb 14, 2000 at 02:49:14PM +0100, Ola Sigurdson wrote:
> What I'm saying is that suid should be turned off by default as it will
> cause problems for a large subset of sites who only want to use ssh as a
> secure telnet replacement.

ssh is a rsh replacement, too and rhosts-rsa is not
considered inherently insecure but needs the s-bit.
please tell me the problems caused by the s-bit.

-markus

Markus Friedl wrote:
>
> On Mon, Feb 14, 2000 at 02:49:14PM +0100, Ola Sigurdson wrote:
> > What I'm saying is that suid should be turned off by default as it will
> > cause problems for a large subset of sites who only want to use ssh as a
> > secure telnet replacement.
>
> ssh is a rsh replacement, too and rhosts-rsa is not
> considered inherently insecure but needs the s-bit.
> please tell me the problems caused by the s-bit.

The problems are not caused by the s-bit as such, they are caused by ssh
binding to a random priviledged port when running as root.

For example if you have a firewall denying traffic to and from port 137
(Netbios) and ssh binds to 137 (on a host not running netbios services)
you will get no connection out, and the firewall will log an illegal
packet.

The majority of people installing ssh do just "make install" or "rpm -U
openssh*" which will give them ssh connections from random priviledged
ports regardless of whether the remote host uses rhost-based login or
not.


Philosophical discussion:

Suid programs are bad, hard to debug and and only exist as a hack around
flawed security models or policies. The less the better.

Regarding the rhost-rsa authentication it is also a hack around a flawed
security model, the idea being to do two very different authentications
at the same time: The user id and the specific machine id of the
client.

It's better to split the authentication into two different steps, for
example using IPsec to verify the connection, and then using ssh with
rsa chap to verify the user.

Besides, for most applications, user authentication with a rsa
certificate should be enough for access control.

On Mon, 14 Feb 2000, Ola Sigurdson wrote:

> Well, yes I know how to turn it off.
>
> What I'm saying is that suid should be turned off by default as it will
> cause problems for a large subset of sites who only want to use ssh as a
> secure telnet replacement.

{Open}SSH is a secure _rsh_ replacement. If you think about it like this
then its use of a secure port should be no surprise.

-d

--
| "Bombay is 250ms from New York in the new world order" - Alan Cox
| Damien Miller - http://www.mindrot.org/
| Email: djm@mindrot.org (home) -or- djm@ibs.com.au (work)