2

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:

[me@localhost.ssh]$ 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 hmac-sha1-etm@openssh.com none
debug1: kex: client->server aes128-ctr hmac-sha1-etm@openssh.com none
debug1: kex: curve25519-sha256@libssh.org need=20 dh_need=20
debug1: kex: curve25519-sha256@libssh.org 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: localuser@localhost.localdomain
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Offering RSA public key: localuser@localhost.localdomain
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Offering RSA public key: localuser@localhost.localdomain
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
2

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
    (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.

|improve this answer|||||
  • 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. – Panos Kordis Feb 13 at 11:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.