Public Key Authentication Windows Port of OpenSSH

ssh windows-server-2012-r2 powershell known-hosts

11,773

Solution 1

Wow. Just spent a couple of hours debugging this.

So, turn logging for the ssh server:

Edit /ProgramData/ssh/sshd_config
- Ensure you have SyslogFacility LOCAL0
- Ensure you have LogLevel DEBUG3
Restart the OpenSSH SSH Server in Services
- CMD:
  C:> net stop sshd
  C:> net start sshd
- GUI: a quick way to get to Services is to press the Windows+R key combo, and enter services.msc in the resulting Run dialog.

Now you will find full debug info is being written to /ProgramData/ssh/logs/sshd.log. Just look in the log file after you have attempted to ssh into the machine.

I had two problems:

Problem 1: The correct authorized_keys file

The debug log said:

2019-03-08 … debug1: trying public key file __PROGRAMDATA__/ssh/administrators_authorized_keys

Ah, so not .ssh/authorized_keys then. I am in the Administrators group, and sshd_config has a special stanza for us folks. I copied the contents of my .ssh/authorized_keys file to /ProgramData/ssh/administrators_authorized_keys, and restarted the server.

Problem 2: Loose permissions

Now I had

2019-03-08 … debug3: Bad permissions. Try removing permissions for user: S-1-9-22 on file C:/ProgramData/ssh/administrators_authorized_keys.

icacls said

C:\ProgramData\ssh> icacls administrators_authorized_keys
administrators_authorized_keys NT AUTHORITY\SYSTEM:(F)
                           BUILTIN\Administrators:(F)
                           NT AUTHORITY\SYSTEM:(I)(F)
                           BUILTIN\Administrators:(I)(F)
                           NT AUTHORITY\Authenticated Users:(I)(RX)

There's a lot of permissions inherited from the folder and above (that's what (I) signifies). Remove the inheritance. /inheritance:r is your friend here.

C:\ProgramData\ssh> icacls administrators_authorized_keys /inheritance:r
processed file: administrators_authorized_keys
Successfully processed 1 files; Failed processing 0 files

Looks good now:

C:\ProgramData\ssh> icacls administrators_authorized_keys
administrators_authorized_keys NT AUTHORITY\SYSTEM:(F)
                           BUILTIN\Administrators:(F)

So I restarted the server, and it's working. Sheesh.

Don't forget to undo your changes to LogLevel and SyslogFacility in sshd_config.

Edit

Of course, none of this detective work was needed if only I knew where the docs were. See

https://docs.microsoft.com/en-us/windows-server/administration/openssh/openssh_server_configuration

Sigh.

Solution 2

As mentioned in https://stackoverflow.com/a/66008728, there is a specific non-english issue to this problem

We ran the same problem in a Windows 2019 and Windows 2016 AND on a non english system (french)

We had to change acl from Administrators to Administrateurs AND modify sshd_config content in programData/ssh as follows

Line Match Group administrators has been uncommented AND modified as Match Group administrateurs

These specific non english settings were not necessary on a Windows 2012 R2 system

Good luck

Solution 3

Just wanted to add some quick notes to compliment @bobbogo's fantastic answer.

Per: https://github.com/PowerShell/Win32-OpenSSH/wiki/Security-protection-of-various-files-in-Win32-OpenSSH#administrators_authorized_keys

I was able to push my private key to a Workgroup (non-domain joined) workstation:

:From WSL(linux) --> Win10 machine
scp ./my/public/key someadmin@somedesktop:'C:\ProgramData\ssh\administrators_authorized_keys'

Then I ran the following via WinRM/PSRemoting (though ssh with password would probably have worked):

PS C:\> cd C:\programdata\ssh

PS C:\programdata\ssh>icacls administrators_authorized_keys /inheritance:r
PS C:\programdata\ssh>icacls administrators_authorized_keys /grant SYSTEM:`(F`)
PS C:\programdata\ssh>icacls administrators_authorized_keys /grant BUILTIN\Administrators:`(F`)

PS C:\programdata\ssh>net stop sshd
PS C:\programdata\ssh>net start sshd

I was then able to ssh with keyauth as expected.

Note: as this was not domain joined, on my first attempt I lost access as the first command removed inheritance, which disabled my stock 1909 OOBE admin's permission to the administrators_authorized_keys file. The next to grants and restarting the service made it work as expected.

Solution 4

Modify sshd config (C:\ProgramData\ssh\sshd_config)

Comment out these rows (should be the last couple of lines of sshd_config)

#Match Group administrators
#    AuthorizedKeysFile __PROGRAMDATA__/ssh/administrators_authorized_keys

After this add your public key to __HOME__/.ssh/authorized_keys as usual.

View more solutions

11,773

Foo Barberger

Updated on September 18, 2022

Comments

Foo Barberger almost 2 years

I have been attempting to get Public Key Authentication working with the PowerShell port of OpenSSH onto a VM running Windows Server 2012 R2.

I have faithfuly followed the installation instructions and have assured that my file permissions are correct for .ssh\authorized_keys. (Can't post link to the specific instructions in the Win32-OpenSSH wiki, since I'm too little to post more than two links, see comment below).

I am able to log in to the windows host from a linux host as expected with username/password. No luck with Key Authentication, however.

Local (linux host) Configuation

My local .ssh/config file contains:

Host remotehostname
    HostName remotehostname
    User remoteuser
    Port 22
    IdentityFile /home/myusername/.ssh/id_dsa

The permissions in the local .ssh directory appear correct:

[[email protected]]$ ls -ltrh
total 56K
-rw------- 1 cengadmin cengadmin 1.6K Sep 11 10:01 known_hosts
-r-------- 1 cengadmin cengadmin  672 Sep 11 10:06 id_dsa
-r-------- 1 cengadmin cengadmin  580 Sep 11 10:13 config

Remote (windows host) Configuration

The .ssh directory on my remote host is as follows:

 Directory of C:\Users\REMOTEUSER\.ssh

09/11/2017  10:07 AM    <DIR>          .
09/11/2017  10:07 AM    <DIR>          ..
09/11/2017  10:07 AM               623 authorized_keys
09/11/2017  10:05 AM               672 id_dsa
09/11/2017  10:05 AM               623 id_dsa.pub
               5 File(s)          4,012 bytes
               2 Dir(s)  10,752,004,096 bytes free

C:\Users\REMOTEUSER\.ssh>icacls authorized_keys
authorized_keys NT SERVICE\sshd:(R)
                NT AUTHORITY\SYSTEM:(F)
                BUILTIN\Administrators:(F)
                FOODOM1\REMOTEUSER:(F)


C:\Users\REMOTEUSER\.ssh>icacls id_dsa
id_dsa BUILTIN\Administrators:(F)
       NT AUTHORITY\SYSTEM:(F)
       DHDOM1\REMOTEUSER:(R,W)

My authorized_keys file contains only the output of type id_dsa.pub > authorized_keys.

C:\Users\REMOTEUSER\.ssh>fc id_dsa.pub authorized_keys
Comparing files id_dsa.pub and AUTHORIZED_KEYS
FC: no differences encountered

sshd_config has PubkeyAuthentication enabled

PubkeyAuthentication yes

The configuration and permissions appear sane to me. However, I get the ubiquitous missing begin marker error I always get when I botch permissions.

sshd.log

I see: debug2: key not found

which generally means I have the wrong key in authorized_keys but I think the diff above disproves this problem.

Clues? Be gentle, I've not used Windows in anger in nearly 10 years.

ssh -v output

(note that I have a other rsa keys in this directory, not included above for clarity)

$ ssh -v -i .ssh/id_dsa myhostname
OpenSSH_6.6.1, OpenSSL 1.0.1e-fips 11 Feb 2013
debug1: Reading configuration data /home/localuser/.ssh/config
debug1: /home/localuser/.ssh/config line 21: Applying options for raleys-etl
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 56: Applying options for *
debug1: Hostname has changed; re-reading configuration
debug1: Reading configuration data /home/localuser/.ssh/config
debug1: /home/localuser/.ssh/config line 15: Applying options for remotehostname
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 56: Applying options for *
debug1: Connecting to remotehostname [00:00:00:00] port 22.
debug1: Connection established.
debug1: identity file /home/localuser/.ssh/id_dsa type -1
debug1: identity file /home/localuser/.ssh/id_dsa-cert type -1
debug1: identity file /home/localuser/.ssh/ssis_rsa type -1
debug1: identity file /home/localuser/.ssh/ssis_rsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6.1
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.5
debug1: match: OpenSSH_7.5 pat OpenSSH* compat 0x04000000
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr [email protected] none
debug1: kex: client->server aes128-ctr [email protected] none
debug1: kex: [email protected] need=20 dh_need=20
debug1: kex: [email protected] need=20 dh_need=20
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA e7:aa:c8:d4:8b:02:58:da:64:e6:18:26:d3:be:6a:b2
debug1: Host 'remotehostname' is known and matches the ECDSA host key.
debug1: Found key in /home/localuser/.ssh/known_hosts:5
debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering RSA public key: [email protected]
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Offering RSA public key: [email protected]
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Offering RSA public key: [email protected]
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Trying private key: /home/localuser/.ssh/id_dsa
debug1: key_parse_private2: missing begin marker
debug1: read PEM private key done: type DSA
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: keyboard-interactive
Received disconnect from 00:00:00:00: 2: Too many authentication failures

the.1337.house over 4 years

Fantastic answer thank you very much. Another important thing to mention is that for the administrators_authorized_keys keys (and not the ~/.ssh/authorized_keys) to work is that it should be accessible by only the the SYSTEM and the Administrators groups. In my case, the file created had included the creator's account which at the time of the installation was an admin. So in that case I had to remove that user from the file's permitted accessors.
Michael Herrmann over 3 years

You, Sir, are a hero. Thank you for this fantastic answer.
sunny moon over 3 years

What's funny is that neither supplied FixHostFilePermissions.ps1 nor FixUserFilePermissions.ps1 scripts would handle that special case. Your answer is literally the single relevant one on the Internet!
Admin about 2 years

Depending on the state of your permissions, it might be more useful to run icacls administrators_authorized_keys /inheritance:d (d instead of r) to copy the current permissions while removing inheritance, then adjusting the permissions from there. In my case I had to remove an extra permission via icacls administrators_authorized_keys /remove "NT AUTHORITY\Authenticated Users", and then it worked.