Cygwin setup

Mainly concentrating here on getting openSSH running on Windows

First, get the Cygwin installer (a single .exe). Run this, set the proxy and choose a mirror. When the install tree comes up we want to select:

• openSSH (in the Net category)
• nano (in the Editors category)

(It is also useful to install notepad++ or some other Windows text editor that plays nicely with UNIX style line endings.)

This has apparently got a lot easier. In particular, if you let the setup process create the ssh service account it does all the setting of additional user rights. Open the cygwin terminal and run ssh-host-config

N.B. for the yes/no queries you need to type yes or no. Also, for the query Enter the value of CYGWIN for the daemon: [] type ntsec (some older documentation has tty as well, but this is apparently deprecated these days. ntsec tells cygwin to use the NT security model.)

According to https://www.ibm.com/developerworks/wikis/display/tivoliaddm/Setting+up+a+Cygwin+OpenSSH+Server+for+Windows+Domains+on+a+TADDM+Gateway+Server these are:

• Adjust memory quotas for a process.
• Create a token object.
• Log on as a service.
• Replace a process-level token.

According to http://www.cs.bham.ac.uk/~smp/projects/ssh-windows/ you should also deny interactive logon, network logon and remote interactive logon.

Once the script has done its thing, start the newly created sshd service. Try a test login using the admin account.

By default the configuration script generates /etc/passwd and /etc/group files from the local security database. Use mkpasswd and mkgroup to generate domain accounts as follows:

mkpasswd -D > /tmp/somefile
mkgroup -D > /tmp/somegroupfile

(see http://cygwin.com/cygwin-ug-net/using-utils.html#mkgroup for details)

Merge the generated group file with the existing /etc/group file (easiest to edit the files in Windows). Note that most of the local group ids are duplicated in the domain list. For the users, either pick out the users that need ssh access and copy the lines to /etc/passwd, or use the mkpasswd -U option to generate data for one user at a time (could append to the passwd file with:

mkpasswd -D -U username >> /etc/passwd

You may want to edit the usernames (first column) to get rid of the domain name - in most cases (single domain with no name clashes with the local account database) this should be acceptable.

For ssh you need local logon permissions on the target system. By default in Server 2003 ordinary users do not have this right, so even after setting up the user you get “access denied” when trying to connect. Add the user (or make a ssh group and add it) to the “Allow log on locally” in the User rights assignment of the local security policy.

There are a couple of ways to do this - you can do it per user by creating username files in /etc/fstab.d/ or by editing the main /etc/fstab file. So to mount a directory F:\stuff for example:

# For a description of the file format, see the Users Guide
# http://cygwin.com/cygwin-ug-net/using.html#mount-table
 
# This is default anyway:
# none /cygdrive cygdrive binary,posix=0,user 0 0
 
F:/stuff /exported/stuff ntfs posix=0 0 0

Note that, as usual with mounts, the directory /exported/stuff must exist. Also note the forward slash in the Windows path specification!

openSSH allows you to change the root directory once a user has logged in, to restrict them to (for example) their home directory. In this case it was done to limit the view of the users to the directories to be shared - Cygwin creates mounts (by default under /cygdrive) for each drive letter, so anyone who connects by default can browse the entire Windows filesystem (depending on security settings, of course).

To do this you need to edit /etc/sshd_config and add (using the previous example of /exported/stuff/)

Subsystem sftp internal-sftp
 
# Example of overriding settings on a per-user basis
#Match User anoncvs
#	X11Forwarding no
#	AllowTcpForwarding no
#	ForceCommand cvs server
 
X11Forwarding no
AllowTcpForwarding no
ChrootDirectory /exported/stuff
ForceCommand internal-sftp

The Subsystem command must come first, the order of ChrootDirectory and ForceCommand doesn't seem to be important. Using internal-sftp means that there are no binaries required in the chrooted path (e.g. sftp). This is only the case if we are allowing sftp access only - if we wanted full shell access it wouldn't work.

The sshd service must be restarted if sshd_config is changed.

There are some very specific permissions required in the path of the chroot. The chroot directory, and everything above it up to /, must be:

1. owned by root (chown 0 directory)
2. not writable by anyone else (chmod 755 directory)

Following the guide at http://doc-sql.blogspot.co.uk/2008/12/openssh-using-cygwin-with-chroot.html works, although it might also work with the Windows 'root' (UID 544). Note there is a gotcha here - if the group ownership is Administrators as well, the permissions are the the same for both, as Administrators seems to act both as a user and a group. The errors this can generate end up in the Application Event Log.

If you are using the internal-sftp subsystem and only want sftp and not shell access, then you can change the user account in /etc/passwd to disable this, e.g. by using :/var/empty:/bin/false for the homedir and shell entries.

File listings appear with the primary group apparently set to the owner's primary group. The primary group appears to come from AD, so would have to be changed there if necessary. groups username now gives all the user's groups - so they are obviously coming from Windows. Thus the purpose of setting the group in /etc/passwd is a little unclear, although it seems that the group you set here is the default group when the user creates files. Maybe.