Unwound Stack

This was a post from my old blog, which I’m just now getting around to posting here.

I run Cygwin on my Windows boxes. I use OpenSSH a lot. I’d wanted to run OpenSSH daemons on my Windows boxes for a long time, but I’ve found it, ahem, challenging. One weekend, I finally decided to dig into the problem & get get to the bottom of the matter. Since others have had problems (for instance, see here, here, & here), I thought I’d post what I learned & what I did.

Initially, I installed according to the stock instructions. That is, I installed Cygwin as usual, then ran ssh-host-config. However, I could never log in and have access to my home directory. I poked at the problem a bit with FileMon, and saw that the sshd process, running as SYSTEM, was trying to access my home directory, which is mounted via Samba from a Linux box — no go.

So, I dug in & did a little reading. The first thing I came across was the notion of
Privilege Separation:

Privilege separation, or privsep, is method in OpenSSH by which operations that require root privilege are performed by a separate privileged monitor process. Its purpose is to prevent privilege escalation by containing corruption to an unprivileged process…When privsep is enabled, during the pre-authentication phase sshd will chroot(2) to “/var/empty” and change its privileges to the “sshd” user and its primary group. sshd is a pseudo-account that should not be used by other daemons, and must be locked and should contain a “nologin” or invalid shell.

(diagram courtesy of Niels Provos).

Now, I noticed that on Windows Server 2003, due to some privilege issues with the SYSTEM account, the install script would create a separate user under which the service would be run:

“Since Cygwin release 1.3.3, applications that are members of the Administrators group and have the Create a token object, Replace a process level token and Increase Quota user rights can
switch user context without giving a password by just calling the usual setuid, seteuid, setgid and setegid functions.

On NT and Windows 2000 the SYSTEM user has these privileges and can run services such as sshd. However, on Windows 2003 SYSTEM lacks the Create a token object right, so it is necessary to create a special user with all the necessary rights, as well as Logon as a service, to run such services. For security reasons this user should be denied the rights to logon interactively or over the
network. All this is done by configuration scripts such as ssh-host-config.”

If you look at ssh-host-config, you can see the logic for setting this up.

That was the trick– I just needed to run the service under an account that had sufficient privileges to access the Samba-mounted drives. I went to my Linux box & added a new user, nw (for network). I didn’t give him a login shell, but I did make him part of my users group. I added him to my Samba database via:

/usr/local/samba/bin/smbpasswd -a nw

Then, I went to each Cygwin machine & ran mkgroup -d to get the relevant passwd entry for the new user. Once that was done, I added the new user to the local administrators group on each machine, & granted it the required privileges:

editrights -a SeAssignPrimaryTokenPrivilege -u BYWATER\nw
editrights -a SeCreateTokenPrivilege -u BYWATER\nw
editrights -a SeTcbPrivilege -u BYWATER\nw
editrights -a SeDenyInteractiveLogonRight -u BYWATER\nw
editrights -a SeDenyNetworkLogonRight -u BYWATER\nw
editrights -a SeDenyRemoteInteractiveLogonRight -u BYWATER\nw
editrights -a SeIncreaseQuotaPrivilege -u BYWATER\nw
editrights -a SeServiceLogonRight -u BYWATER\nw

Note that Bywater is my Windows domain name.

Ok– then, I ran ssh-host-config as usual, but declined to install as a Service. I did that myself like so:

cygrunsrv -I sshd -d "Cygwin sshd" -p /usr/sbin/sshd -a -D -u BYWATER\nw -w "xxx" -e "CYGWIN=binmode winsymlinks ntsec" -y tcpip

I started the service, and, naturally, it died. As a means of debugging it, I granted Bywater\nw logon privileges, and did the following:

runas /user:BYWATER\nw cmd bash -i /usr/sbin/sshd -D

Running in the foreground, the thing happily told me that it was having permissions problems with /var/empty, /var/log/sshd.log, and /etc/ssh_host*. Easily remedied:

chown nw.Administrators /var/empty /var/log/sshd.log /etc/ssh_host*

Presto! All was well. I could even forward X11 over an ssh session from my Linux box!