Re: Workarounds for OpenSSH problems

From: Andrew McNaughton (andrew@scoop.co.nz)
Date: 06/25/02 

Date: Tue, 25 Jun 2002 19:38:44 +1200 (NZST)
From: Andrew McNaughton <andrew@scoop.co.nz>
To: Brett Glass <brett@lariat.org>

On Tue, 25 Jun 2002, Brett Glass wrote:

> At 12:02 AM 6/25/2002, Andrew McNaughton wrote:
>
> >I've installed it. It griped and wouldn't start without `mkdir
> >/var/empty`. Having added that it's running, but it hasn't griped about
> >the lack of an 'sshd' user/group. I added them anyway. I don't see any
> >sign of an sshd process running as anything other than root though.
> >Compression is enabled when I connect, but I'm not sure that the privilege
> >separation is actually working.
>
> I'd be inclined to think it wasn't. Did you make with -D OPENSSH_OVERWRITE_BASE
> so that it overwrote the old implementation? (You might still be running the
> old one.)

No, looks like it's operational. It did complain about /var/empty
being missing, and on inspection, there's plenty of other evidence.

The machine in question is on the other side of the world. I rely on ssh
to administer it and losing access would be a serious pain. I therefore
make a practice of installing new ssh version with PREFIX specified, and
run the new version on a different port while the old one is still
operational. I then disable the old version, and start up a backup sshd
of the new version. I'm fairly familiar with this process, and I'm very
sure of which executable and configuration I'm using.

Still, I verified it with lsof just now. definitely the right executable,
but nothing connected to /var/empty after I've logged in through it. In
the output of lastcomm I can see that there was a process owned by sshd
which lasted for 0.05 seconds during authentication. I turned on lots of
debugging, and there's plenty of other indications of the privilege
separation. This includes messages like:

Jun 25 19:12:10 a2 sshd[68320]: debug1: monitor_child_preauth: andrew has
been authenticated by privileged process

68320 is the pid of the process which survives, and runs as root.
I don't see any syslog entries from the unpriviledged process.

So, I don't entirely understand the partitioning of responsibility, and
am somewhat surprised that it's the root process which persists. I'm left
somewhat uncertain of what has been bought by the split. However, it
looks like its enabled, including compression.

I did see one odd bug: When I started the server up with -D -d -d -d, the
message "debug3: channel_close_fds: channel 0: r -1 w -1 e -1" came
through on the client rather than the server.

Andrew McNaughton

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message

Relevant Pages

  • Re: why sshd is running under root ?
    ... I new that it needs roots to launch ... This needs root privilege. ... You can reduce the risk by using privilege separation which is often the ... There is very little real risk as long as you keep sshd up to date. ...
    (comp.os.linux.networking)
  • Re: cannot start sshd on cygwin- win xp
    ... 'installing' sshd on cygwin. ... There has to be added a special user etc. ... Could start cygwin automatically, it starts the bash shell, and I ...
    (comp.security.ssh)
  • Start sshd from OpenSSH3.4p1
    ... after installing OpenSSH3.4p1 sshd is now ... stopping the old sshd and start of the new ... debug1: read PEM private key done: type RSA ...
    (comp.security.ssh)
  • sshd_config in CYGWIN - cannot edit
    ... to have its permissions changed with chmod. ... The Cygwin prompt indicates I am logged in as a computer administrator ... Prior to installing cygwin I ... Sshd was installed using the ssh-host-config file: ...
    (comp.security.ssh)
  • Re: Start sshd from OpenSSH3.4p1
    ... > after installing OpenSSH3.4p1 sshd is now ... > stopping the old sshd and start of the new ... > debug1: read PEM private key done: type RSA ...
    (comp.security.ssh)