Blog |Follow Nick on Twitter| About
 

An SSH server for windows, it's the kind of thing only a Linux/OSX user would ask for. The current defacto standard is Cygwin but if you fancy something a bit more native, something a bit backed by Microsoft then take a look at PowerShell/Win32-OpenSSH on github.

Installation is quite straight forward:

  1. Download the latest release make sure you correctly select 32bit or 64bit
  2. Create a folder, C:\Program Files\OpenSSH-Win32 and extract the contents there.
  3. Start Powershell as Administrator - cd 'C:\Program Files\OpenSSH-Win32'
  4. Setup SSH host keys (this will generate all the 'host' keys that sshd expects when its starts) - .\ssh-keygen.exe -A
  5. Enable key-based auth - .\install-sshlsa.ps1
  6. Reboot (well it is windows!)
  7. Start Powershell as Administrator again - cd 'C:\Program Files\OpenSSH-Win32'
  8. Install and run daemon as NT Service running as Local System - .\install-sshd.ps1
  9. Start the service - Start-Service sshd
  10. Make the service start on boot - Set-Service sshd -StartupType Automatic

If you have a problem running step 5 you might need to run Set-ExecutionPolicy Unrestricted; if you do disable this security, switch it back on when you're finished Set-ExecutionPolicy RemoteSigned (or whatever).

Also, don't forget to allow tcp/22 through any firewalls, either network or host based.

You'll probably want to enable SFTP, the server that is.

Edit C:\Program Files\OpenSSH-Win32\sshd_config in your favorite text editor and replace this:

# override default of no subsystems
#Subsystem  sftp    /usr/libexec/sftp-server
Subsystem   sftp    /win32openssh/bin/sftp-server.exe
Subsystem   scp /win32openssh/bin/scp.exe

with

# override default of no subsystems
#Subsystem  sftp    /usr/libexec/sftp-server
#Subsystem  sftp    /win32openssh/bin/sftp-server.exe
Subsystem   sftp    c:\PROGRA~1\OPENSS~1\sftp-server.exe
#Subsystem  scp /win32openssh/bin/scp.exe

Notice for program files and openssh-win32 I'm using the short path, you can find those using cmd.exe and using dir /x.

Your first login, from a Linux/OSX/nix machine

Ok, so this is where it gets a little odd. For your username you need SamAccountName@fqdndomain, as there is an @ in there you need to use the -l switch on ssh. Which means you have to do something like ssh -l nick.bettison@company.local mypc.company.local with a little luck that'll give you this...

linickx:~ $ ssh -l nick.bettison@company.local mypc.company.local
ssh -l nick.bettison@company.local@mypc.company.local's password: 
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation.  All rights reserved.

nick.bettison@company.local@MYPC C:\Users\nick.bettison\Documents>

If your PC is standalone (workgroup) you can use normal ssh syntax, either ssh user@pc.local or ssh -l user pc.local.

Connecting with SFTP

On a domain PC, SFTP probably won't work because there is no -l, as a workaround on my nix machine I added the following to my ~/.ssh/config file:

Host mypc
        Hostname mypc.company.local
        User nick.bettison@company.local

Which should work like this...

linickx:~ $ sftp mypc
nick.bettison@company.local@mypc.company.local's password: 
Connected to mypc.
sftp> pwd
Remote working directory: /C:/Users/nick.bettison/Documents
sftp> 

To enable public key authentication

Edit C:\Program Files\OpenSSH-Win32\sshd_config in your favorite text editor (again) and replace this...

#RSAAuthentication yes
#PubkeyAuthentication yes

with

RSAAuthentication yes
PubkeyAuthentication yes

NOTE: Public key auth doesn't seem to work with domain PCs.

I tested on a standalone (non-domain) windows7 PC and it worked fine, but on a domain PC at work it fails with the following server side error message.

Cannot logon using LSA package (err = 1300, ntStat = c0000041).

Github Issue 87 seems to imply that this is group policy related, if it is, as yet I haven't figured out which one. The other reason this might not work is username interpretation, local users are "username" where as domains are "username@domain" so I wonder if the LSA .DLL is looking in the wrong place; I will update here if I find a solution.

rgds,

Nick

 
Nick Bettison ©