openssh unix dev - Jul 2018 - Does anyone use UsePrivilegedPort=yes or setuid ssh(1) ?

Hi.

Does anyone use UsePrivilegedPort or have ssh(1) setuid, and if so for
what use case?

ssh(1) has had code in it to support installing setuid root since
approximately forever, however OpenBSD has not shipped it in that
configuration since 2002 (and I suspect these days no vendor does).

As far as I can tell, all of the reasons for this no longer apply:

 - setuid root was needed to bind to a privileged (low numbered) ports.
 - privileged ports were needed for rhosts and rhostsrsa
authentication.  rhosts is long dead, and rhostsrsa went with the last
of Protocol 1.
 - root privileges were needed to read the host keys for Protocol 2
hostbased authentication, but that need was replaced by the
ssh-keysign setuid helper program, also in 2002.

So, does anyone use these and if so why?  If it's for low numbered
ports, there are safer ways to do that these days (CAP_NET_BIND or
similar if you have it, or a small setuid ProxyCommand).

Thanks.

-- 
Darren Tucker (dtucker at dtucker.net)
GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860  37F4 9357 ECEF 11EA A6FA (new)
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

Hi,

On Fri, Jul 06, 2018 at 03:58:30PM +1000, Darren Tucker
wrote:
> Does anyone use UsePrivilegedPort or have ssh(1) setuid, and if so for
> what use case?
[..]
> So, does anyone use these and if so why?  If it's for low numbered
> ports, there are safer ways to do that these days (CAP_NET_BIND or
> similar if you have it, or a small setuid ProxyCommand).
I think we have one customer connection where their firewall admin
thinks "it is more secure that way" - read, we can't ssh in if we
come
from high ports.

OTOH, thanks for the pointer with ProxyCommand - it's a very specific
niche problem with a viable workaround, so I can't think of any 
remaining reason why we'd want suid ssh anymore ;-)

gert

-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
                             Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany                             gert at
greenie.muc.de

On 6 July 2018 at 17:24, Gert Doering <gert at greenie.muc.de>wrote:
[...]
> I think we have one customer connection where their firewall admin
> thinks "it is more secure that way" - read, we can't ssh in
if we come
> from high ports.
>
> OTOH, thanks for the pointer with ProxyCommand - it's a very specific
> niche problem with a viable workaround, so I can't think of any
> remaining reason why we'd want suid ssh anymore ;-)
There's another possibility: if you have a NAT-capable packet filter
in the path you might be able to remap the source ports using source
NAT.  I think that'd be --to-source=1.2.3.4:800:1023 in iptables (not
sure about other systems, I didn't see an obvious way to do it with
PF).

-- 
Darren Tucker (dtucker at dtucker.net)
GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860  37F4 9357 ECEF 11EA A6FA (new)
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.