Windows SSH server refuses key based authentication from client

2

1

On Windows 10 1809, I have enabled the in-built SSH server, and have configured it.

On another machine, I have used WinSCP and PuTTy generator to generate an authentication key. I copied the public key portion and appended that to the Authorized_Keys file in .ssh folder of my SSH server user. I fixed file permissions as required, to only my user, i.e., the logged in user, for the key file.

On the client machine, I used the .PPK private key, with WinSCP to try and connect into an SFTP session with my server, but I get a message that the serveR refused the key which I had selected.

I am able to authenticate using password, but the key pair isn't working out. Digging through the sshd logs generated on the server, I see this:

 10200 2019-06-07 01:38:16.376 debug1: attempt 1 failures 0 [preauth]
10200 2019-06-07 01:38:16.376 debug2: input_userauth_request: try method publickey [preauth]
10200 2019-06-07 01:38:16.376 debug1: userauth_pubkey: test pkalg ssh-rsa pkblob RSA SHA256:B6s0omPbz6HJB2cIZf3+5MKHU42wp+JfOTyAM+EVqoY [preauth]
10200 2019-06-07 01:38:16.376 debug2: userauth_pubkey: disabled because of invalid user [preauth]

I am not sure what happened here, and if this is the reason why connection was refused. Firewall cannot be an issue since I am able to log into the server using password authentication. The client machine, and WinScp are being recognized on the server, it's just that the server refuses the provided key.

Is the key generated by PuTTy (or the key content copied with public key) not supported in either place? There's no passphrase associated with the key, but I don't suppose that should be an issue.

There's only one user on the server machine, which is the logged in user. The sshd service is running under LOCAL SYSTEM account. Should it run under a user account (I tried that but the service does not start at all, Event logs complain of a missing privilege...)

EDIT - More information

I commented out the following -

Match Group administrators

AuthorizedKeysFile PROGRAMDATA/ssh/administrators_authorized_keys

..in sshd-config, but now, a connection attempt complains that authorized_keys has bad permission. The machine only has one user, and the authorized_keys within the .ssh folder of that user only that one user access. I tried using Repair-AuthorizedKeyPermission on the key file, which added SYSTEM and sshd (NT Service user) as users to the key file, sshd having read access. But now, a connection attempt complains that bad permission has been set for user S-1-5-80 which is the same NT Service user sshd added by Repair-AutorizedKeyFile. Removing read permission (only permission) for this user again gives the old error, saying Access Denied.

EDIT - sshd.exe Logs from a connection attempt :

2696 2019-06-10 03:57:09.020 debug2: fd 3 setting O_NONBLOCK

2696 2019-06-10 03:57:09.020 debug3: sock_set_v6only: set socket 3 IPV6_V6ONLY

2696 2019-06-10 03:57:09.020 debug1: Bind to port 22 on ::.

2696 2019-06-10 03:57:09.020 Server listening on :: port 22.

2696 2019-06-10 03:57:09.020 debug2: fd 4 setting O_NONBLOCK

2696 2019-06-10 03:57:09.020 debug1: Bind to port 22 on 0.0.0.0.

2696 2019-06-10 03:57:09.020 Server listening on 0.0.0.0 port 22.

2696 2019-06-10 03:57:35.475 debug3: fd 5 is not O_NONBLOCK

2696 2019-06-10 03:57:35.477 debug3: spawning "C:\WINDOWS\System32\OpenSSH\sshd.exe" "-R"

2696 2019-06-10 03:57:35.483 debug3: send_rexec_state: entering fd = 8 config len 287

2696 2019-06-10 03:57:35.484 debug3: ssh_msg_send: type 0

2696 2019-06-10 03:57:35.485 debug3: send_rexec_state: done

9428 2019-06-10 03:57:35.556 debug1: inetd sockets after dupping: 3, 3

9428 2019-06-10 03:57:35.556 Connection from 130.147.168.135 port 64534 on 161.85.17.107 port 22

9428 2019-06-10 03:57:35.556 debug1: Client protocol version 2.0; client software version WinSCP_release_5.15.2

9428 2019-06-10 03:57:35.556 debug1: no match: WinSCP_release_5.15.2

9428 2019-06-10 03:57:35.556 debug1: Local version string SSH-2.0-OpenSSH_for_Windows_7.7

9428 2019-06-10 03:57:35.556 debug2: fd 3 setting O_NONBLOCK

9428 2019-06-10 03:57:35.568 debug3: spawning "C:\WINDOWS\System32\OpenSSH\sshd.exe" "-y"

9428 2019-06-10 03:57:35.572 debug2: Network child is on pid 6944

9428 2019-06-10 03:57:35.573 debug3: send_rexec_state: entering fd = 6 config len 287

9428 2019-06-10 03:57:35.573 debug3: ssh_msg_send: type 0

9428 2019-06-10 03:57:35.575 debug3: send_rexec_state: done

9428 2019-06-10 03:57:35.575 debug3: ssh_msg_send: type 0

9428 2019-06-10 03:57:35.576 debug3: ssh_msg_send: type 0

9428 2019-06-10 03:57:35.576 debug3: preauth child monitor started

9428 2019-06-10 03:57:35.607 debug1: list_hostkey_types: ssh-rsa,rsa-sha2-512,rsa-sha2-256,ecdsa-sha2-nistp256,ssh-ed25519 [preauth]

9428 2019-06-10 03:57:35.607 debug3: send packet: type 20 [preauth]

9428 2019-06-10 03:57:35.607 debug1: SSH2_MSG_KEXINIT sent [preauth]

9428 2019-06-10 03:57:35.794 debug3: receive packet: type 20 [preauth]

9428 2019-06-10 03:57:35.794 debug1: SSH2_MSG_KEXINIT received [preauth]

9428 2019-06-10 03:57:35.795 debug2: local server KEXINIT proposal [preauth]

9428 2019-06-10 03:57:35.796 debug2: KEX algorithms: curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1 [preauth]

9428 2019-06-10 03:57:35.797 debug2: host key algorithms: ssh-rsa,rsa-sha2-512,rsa-sha2-256,ecdsa-sha2-nistp256,ssh-ed25519 [preauth]

9428 2019-06-10 03:57:35.798 debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com [preauth]

9428 2019-06-10 03:57:35.798 debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com [preauth]

9428 2019-06-10 03:57:35.798 debug2: MACs ctos: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1 [preauth]

9428 2019-06-10 03:57:35.798 debug2: MACs stoc: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1 [preauth]

9428 2019-06-10 03:57:35.798 debug2: compression ctos: none [preauth]

9428 2019-06-10 03:57:35.798 debug2: compression stoc: none [preauth]

9428 2019-06-10 03:57:35.799 debug2: languages ctos: [preauth]

9428 2019-06-10 03:57:35.799 debug2: languages stoc: [preauth]

9428 2019-06-10 03:57:35.799 debug2: first_kex_follows 0 [preauth]

9428 2019-06-10 03:57:35.799 debug2: reserved 0 [preauth]

9428 2019-06-10 03:57:35.799 debug2: peer client KEXINIT proposal [preauth]

9428 2019-06-10 03:57:35.799 debug2: KEX algorithms: curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,rsa2048-sha256,rsa1024-sha1,diffie-hellman-group1-sha1 [preauth]

9428 2019-06-10 03:57:35.799 debug2: host key algorithms: ssh-ed25519,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-rsa,ssh-dss [preauth]

9428 2019-06-10 03:57:35.799 debug2: ciphers ctos: aes256-ctr,aes256-cbc,rijndael-cbc@lysator.liu.se,aes192-ctr,aes192-cbc,aes128-ctr,aes128-cbc,chacha20-poly1305@openssh.com,blowfish-ctr,blowfish-cbc,3des-ctr,3des-cbc,arcfour256,arcfour128 [preauth]

9428 2019-06-10 03:57:35.800 debug2: ciphers stoc: aes256-ctr,aes256-cbc,rijndael-cbc@lysator.liu.se,aes192-ctr,aes192-cbc,aes128-ctr,aes128-cbc,chacha20-poly1305@openssh.com,blowfish-ctr,blowfish-cbc,3des-ctr,3des-cbc,arcfour256,arcfour128 [preauth]

9428 2019-06-10 03:57:35.800 debug2: MACs ctos: hmac-sha2-256,hmac-sha1,hmac-sha1-96,hmac-md5,hmac-sha2-256-etm@openssh.com,hmac-sha1-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-etm@openssh.com [preauth]

9428 2019-06-10 03:57:35.800 debug2: MACs stoc: hmac-sha2-256,hmac-sha1,hmac-sha1-96,hmac-md5,hmac-sha2-256-etm@openssh.com,hmac-sha1-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-etm@openssh.com [preauth]

9428 2019-06-10 03:57:35.800 debug2: compression ctos: none,zlib [preauth]

9428 2019-06-10 03:57:35.800 debug2: compression stoc: none,zlib [preauth]

9428 2019-06-10 03:57:35.800 debug2: languages ctos: [preauth]

9428 2019-06-10 03:57:35.800 debug2: languages stoc: [preauth]

9428 2019-06-10 03:57:35.800 debug2: first_kex_follows 0 [preauth]

9428 2019-06-10 03:57:35.800 debug2: reserved 0 [preauth]

9428 2019-06-10 03:57:35.801 debug1: kex: algorithm: curve25519-sha256@libssh.org [preauth]

9428 2019-06-10 03:57:35.801 debug1: kex: host key algorithm: ssh-ed25519 [preauth]

9428 2019-06-10 03:57:35.801 debug1: kex: client->server cipher: aes256-ctr MAC: hmac-sha2-256 compression: none [preauth]

9428 2019-06-10 03:57:35.801 debug1: kex: server->client cipher: aes256-ctr MAC: hmac-sha2-256 compression: none [preauth]

9428 2019-06-10 03:57:35.801 debug1: expecting SSH2_MSG_KEX_ECDH_INIT [preauth]

9428 2019-06-10 03:57:35.834 debug3: receive packet: type 30 [preauth]

9428 2019-06-10 03:57:35.843 debug3: mm_key_sign entering [preauth]

9428 2019-06-10 03:57:35.843 debug3: mm_request_send entering: type 6 [preauth]

9428 2019-06-10 03:57:35.843 debug3: mm_key_sign: waiting for MONITOR_ANS_SIGN [preauth]

9428 2019-06-10 03:57:35.843 debug3: mm_request_receive_expect entering: type 7 [preauth]

9428 2019-06-10 03:57:35.843 debug3: mm_request_receive entering [preauth]

9428 2019-06-10 03:57:35.843 debug3: mm_request_receive entering

9428 2019-06-10 03:57:35.843 debug3: monitor_read: checking request 6

9428 2019-06-10 03:57:35.843 debug3: mm_answer_sign

9428 2019-06-10 03:57:35.846 debug3: mm_answer_sign: hostkey proof signature 0000029369ED8600(83)

9428 2019-06-10 03:57:35.846 debug3: mm_request_send entering: type 7

9428 2019-06-10 03:57:35.846 debug2: monitor_read: 6 used once, disabling now

9428 2019-06-10 03:57:35.846 debug3: send packet: type 31 [preauth]

9428 2019-06-10 03:57:35.846 debug3: send packet: type 21 [preauth]

9428 2019-06-10 03:57:35.846 debug2: set_newkeys: mode 1 [preauth]

9428 2019-06-10 03:57:35.846 debug1: rekey after 4294967296 blocks [preauth]

9428 2019-06-10 03:57:35.846 debug1: SSH2_MSG_NEWKEYS sent [preauth]

9428 2019-06-10 03:57:35.846 debug1: expecting SSH2_MSG_NEWKEYS [preauth]

9428 2019-06-10 03:57:36.356 debug3: receive packet: type 21 [preauth]

9428 2019-06-10 03:57:36.356 debug1: SSH2_MSG_NEWKEYS received [preauth]

9428 2019-06-10 03:57:36.356 debug2: set_newkeys: mode 0 [preauth]

9428 2019-06-10 03:57:36.356 debug1: rekey after 4294967296 blocks [preauth]

9428 2019-06-10 03:57:36.356 debug1: KEX done [preauth]

9428 2019-06-10 03:57:36.399 debug3: receive packet: type 5 [preauth]

9428 2019-06-10 03:57:36.399 debug3: send packet: type 6 [preauth]

9428 2019-06-10 03:57:36.435 debug3: receive packet: type 50 [preauth]

9428 2019-06-10 03:57:36.435 debug1: userauth-request for user TestUser service ssh-connection method none [preauth]

9428 2019-06-10 03:57:36.435 debug1: attempt 0 failures 0 [preauth]

9428 2019-06-10 03:57:36.435 debug3: mm_getpwnamallow entering [preauth]

9428 2019-06-10 03:57:36.436 debug3: mm_request_send entering: type 8 [preauth]

9428 2019-06-10 03:57:36.436 debug3: mm_getpwnamallow: waiting for MONITOR_ANS_PWNAM [preauth]

9428 2019-06-10 03:57:36.436 debug3: mm_request_receive_expect entering: type 9 [preauth]

9428 2019-06-10 03:57:36.436 debug3: mm_request_receive entering [preauth]

9428 2019-06-10 03:57:36.436 debug3: mm_request_receive entering

9428 2019-06-10 03:57:36.436 debug3: monitor_read: checking request 8

9428 2019-06-10 03:57:36.436 debug3: mm_answer_pwnamallow

9428 2019-06-10 03:57:36.439 debug2: parse_server_config: config reprocess config len 287

9428 2019-06-10 03:57:36.439 debug3: checking match for 'Group administrators' user TestUser host 130.147.168.135 addr 130.147.168.135 laddr 161.85.17.107 lport 22

9428 2019-06-10 03:57:36.446 debug3: LsaLogonUser Succeeded (Impersonation: 0)

9428 2019-06-10 03:57:36.448 debug1: user TestUser matched group list administrators at line 84

9428 2019-06-10 03:57:36.448 debug3: match found

9428 2019-06-10 03:57:36.448 debug3: reprocess config:85 setting AuthorizedKeysFile PROGRAMDATA/ssh/administrators_authorized_keys

9428 2019-06-10 03:57:36.449 debug3: mm_answer_pwnamallow: sending MONITOR_ANS_PWNAM: 1

9428 2019-06-10 03:57:36.449 debug3: mm_request_send entering: type 9

9428 2019-06-10 03:57:36.450 debug2: monitor_read: 8 used once, disabling now

9428 2019-06-10 03:57:36.450 debug2: input_userauth_request: setting up authctxt for TestUser [preauth]

9428 2019-06-10 03:57:36.450 debug3: mm_inform_authserv entering [preauth]

9428 2019-06-10 03:57:36.450 debug3: mm_request_send entering: type 4 [preauth]

9428 2019-06-10 03:57:36.451 debug3: mm_request_receive entering

9428 2019-06-10 03:57:36.451 debug3: monitor_read: checking request 4

9428 2019-06-10 03:57:36.451 debug3: mm_answer_authserv: service=ssh-connection, style=

9428 2019-06-10 03:57:36.451 debug2: monitor_read: 4 used once, disabling now

9428 2019-06-10 03:57:36.451 debug2: input_userauth_request: try method none [preauth]

9428 2019-06-10 03:57:36.452 debug3: userauth_finish: failure partial=0 next methods="publickey,password,keyboard-interactive" [preauth]

9428 2019-06-10 03:57:36.452 debug3: send packet: type 51 [preauth]

9428 2019-06-10 03:57:36.453 debug3: receive packet: type 50 [preauth]

9428 2019-06-10 03:57:36.453 debug1: userauth-request for user TestUser service ssh-connection method publickey [preauth]

9428 2019-06-10 03:57:36.453 debug1: attempt 1 failures 0 [preauth]

9428 2019-06-10 03:57:36.454 debug2: input_userauth_request: try method publickey [preauth]

9428 2019-06-10 03:57:36.454 debug1: userauth_pubkey: test pkalg ssh-rsa pkblob RSA SHA256:ospJEFHH81sy96YBMFEySGGUokk1KZHV+AbgNTFRrjE [preauth]

9428 2019-06-10 03:57:36.455 debug3: mm_key_allowed entering [preauth]

9428 2019-06-10 03:57:36.455 debug3: mm_request_send entering: type 22 [preauth]

9428 2019-06-10 03:57:36.455 debug3: mm_request_receive entering

9428 2019-06-10 03:57:36.455 debug3: monitor_read: checking request 22

9428 2019-06-10 03:57:36.456 debug3: mm_answer_keyallowed entering

9428 2019-06-10 03:57:36.456 debug3: mm_answer_keyallowed: key_from_blob: 0000029369F0D8B0

9428 2019-06-10 03:57:36.456 debug1: trying public key file PROGRAMDATA/ssh/administrators_authorized_keys

9428 2019-06-10 03:57:36.456 debug3: Failed to open file:C:/ProgramData/ssh/administrators_authorized_keys error:2

9428 2019-06-10 03:57:36.456 debug1: Could not open authorized keys 'PROGRAMDATA/ssh/administrators_authorized_keys': No such file or directory

9428 2019-06-10 03:57:36.456 debug3: mm_answer_keyallowed: publickey authentication test: RSA key is not allowed

9428 2019-06-10 03:57:36.456 Failed publickey for TestUser from 130.147.168.135 port 64534 ssh2: RSA SHA256:ospJEFHH81sy96YBMFEySGGUokk1KZHV+AbgNTFRrjE

9428 2019-06-10 03:57:36.456 debug3: mm_request_send entering: type 23

9428 2019-06-10 03:57:36.457 debug3: mm_key_allowed: waiting for MONITOR_ANS_KEYALLOWED [preauth]

9428 2019-06-10 03:57:36.457 debug3: mm_request_receive_expect entering: type 23 [preauth]

9428 2019-06-10 03:57:36.457 debug3: mm_request_receive entering [preauth]

9428 2019-06-10 03:57:36.457 debug2: userauth_pubkey: authenticated 0 pkalg ssh-rsa [preauth]

9428 2019-06-10 03:57:36.457 debug3: userauth_finish: failure partial=0 next methods="publickey,password,keyboard-interactive" [preauth]

9428 2019-06-10 03:57:36.457 debug3: send packet: type 51 [preauth]

9428 2019-06-10 03:57:36.482 debug3: receive packet: type 50 [preauth]

9428 2019-06-10 03:57:36.482 debug1: userauth-request for user TestUser service ssh-connection method keyboard-interactive [preauth]

9428 2019-06-10 03:57:36.482 debug1: attempt 2 failures 1 [preauth]

9428 2019-06-10 03:57:36.482 debug2: input_userauth_request: try method keyboard-interactive [preauth]

9428 2019-06-10 03:57:36.482 debug1: keyboard-interactive devs [preauth]

9428 2019-06-10 03:57:36.483 debug1: auth2_challenge: user=TestUser devs= [preauth]

9428 2019-06-10 03:57:36.483 debug1: kbdint_alloc: devices '' [preauth]

9428 2019-06-10 03:57:36.483 debug2: auth2_challenge_start: devices [preauth]

9428 2019-06-10 03:57:36.483 debug3: userauth_finish: failure partial=0 next methods="publickey,password,keyboard-interactive" [preauth]

9428 2019-06-10 03:57:36.483 debug3: send packet: type 51 [preauth]

user1173240

Posted 2019-06-07T09:34:30.557

Reputation: 261

There exactly did you save the Authorized_Keys file to? + What does its contents look like? – Martin Prikryl – 2019-06-07T10:15:30.247

userauth_pubkey: disabled because of invalid user There's something wrong with the account on the server. There may be earlier log entries from sshd which indicate the actual problem. Please [edit] your question to include all of the sshd log entries from a connect attempt. – Kenster – 2019-06-07T12:30:40.790

@MartinPrikryl The Authorized_Keys file is saved in the .ssh folder within the user's directory. The same location is mentioned in the sshd_config file within Program Data. The user logged in is the same whose local directory the keys file is saved in. – user1173240 – 2019-06-10T03:48:35.257

"user's directory" is far from being an exact specification of a file location + You didn't answer my other question nor provided the information Kenster asked for. – Martin Prikryl – 2019-06-10T06:15:09.213

@MartinPrikryl Ah, I am sorry. The Authorized_Keys file is present in <System Drive>\Users\MyLoggedInAdministratorUser.ssh folder. Its contents are those which are copied from WinSCP PuTTy generated key - public key area. It begins with ssh-rsa followed by a bunch of alphanumeric letters, and ends with rsa-key-20190607 . I hope that is correct. I'll update the question to provide the additional information requested as soon as I have it. – user1173240 – 2019-06-10T07:19:08.347

@Kenster I have provided the sshd.exe logs from a connection attempt. – user1173240 – 2019-06-10T07:45:44.443

"get_passwd: Invalid account type: 3." -- The 3 means SidTypeDomain -- What format of username did you use? – Martin Prikryl – 2019-06-10T07:56:57.490

@MartinPrikryl This may sound silly, but as I had understood , with key based authentication, I wouldn't need to provide a username or password. So..for connecting, I had left the username blank, upon prompt in WinSCP. Even if I don't leave it blank, but provide a username of the fashion \<username> , it still says server refused our key, after providing the password, it connects fine. Is my understanding not correct, that if you've the private key specified, and the server has your private key, then user should be allowed to log in for SFTP transfer, without a username and password? – user1173240 – 2019-06-10T09:21:22.643

If I use a username, i.e, the same logged in user as in the server, I still get the message, server refused our key. I tried with <username>, \<username> and \\<username> – user1173240 – 2019-06-10T09:43:11.080

A private key replaces a password. But you still need a username. How else would the server know to which authorized_keys file to look into? --- Show us log file for <username>. – Martin Prikryl – 2019-06-10T10:18:53.273

@MartinPrikryl I will provide the log with a username, the same user which is currently logged on to the server. For clarification, is the user specification required only because of the location of the authorized_keys file, or is there another reason? I only ask, since, using the sshd-config file, I can move the authorized_config file to another location, maybe outside the context of a user? In this case, sshd would know where and which `authorized_keys file it is expected to refer? Of course, I am not sure it'll work that way... – user1173240 – 2019-06-10T10:56:54.050

1You always need to specify the username. Not only because of the authorized_keys. But simply, because when you login, you assume a role/permissions of some local user (local as of the server). – Martin Prikryl – 2019-06-10T11:31:49.017

@MartinPrikryl Thank you for your clarification. I assume the server user, whose username needs to be passed around, need not be an admin user...I have updated the logs with a user logon attempt. I see an error that it's unable to find a file called administrators_authorized_keys within ProgramData/ssh. – user1173240 – 2019-06-11T03:39:58.623

@MartinPrikryl I've added some more information in the question, based on some more attempts, specifically after commenting out administrators_authorized_keys section from sshd-config – user1173240 – 2019-06-11T04:24:41.800

@MartinPrikryl Thank you for your assistance in resolving this. – user1173240 – 2019-06-12T07:35:27.290

Answers

5

As of Windows 10 v1809, the default config (found in %ProgramData%/ssh/sshd_config) defines a separate AuthorizedKeysFile for administrator users:

Match Group administrators
       AuthorizedKeysFile __PROGRAMDATA__/ssh/administrators_authorized_keys

This means any user who is in the special Windows Administrators group (SID S-1-5-32-544) will not look at the %UserProfile%/.ssh/authorized_keys file but will rather look at %ProgramData%/ssh/administrators_authorized_keys.

You have a few options:

  • Use a non-administrator user, or
  • Comment out those two lines from the bottom of sshd_config, which will then revert back to the default per-user AuthorizedKeysFile, or
  • Add your keys to the (global!) administrators_authorized_keys file

My recommendation is to use a non-admin user if possible, or modify the config otherwise. A global key that is accepted for any account in the Administrators group sounds like unnecessary complexity.1


1 In a default config it is always possible to impersonate any other user from an admin user, since an admin user generally implies full root-level control in Windows. That might be their rationale for this default. But of course it makes configuration of a multi-user system rather confusing, where some (non-admin) users have their own authorized keys in a standard location while other (admin) users must share a single nonstandard authorized key list.

I believe there are no security benefits to such a configuration, apart from making it obvious that all admins can impersonate each other.

A future release may create user-specific folders under %ProgramData/ssh.

This is somewhat explored here: https://github.com/PowerShell/Win32-OpenSSH/issues/1324

Bob

Posted 2019-06-07T09:34:30.557

Reputation: 51 526

Thank you for your answer. I did comment out the lines from the sshd-config file, but sshd logs complain that it could not access the authorized_keys file because of permission, despite the fact that only the logged in user, which is the admin, has permission. I tried using Repair-AuthorizedKeyPermission -FilePath $home\.ssh\authorized_keys, which added NT Service user sshd to the list of users, apart from SYSTEM, and tried again, but this time, I got an error saying Bad Permission for user S-1-5-80,which is the NT service sshd that was added by Repair AuthorizedKeyPermission – user1173240 – 2019-06-11T04:10:58.240

1@user1173240 It works for me on a clean Win10 v1903 (preview) install. What did you do earlier where you said "I fixed file permissions as required, to only my user, i.e., the logged in user, for the key file."? The default, valid, permissions are fully inherited (authorized_keys inherits from .ssh which inherits from the user profile), which by default allows Full control to SYSTEM, Administrators, and the specific user. This is generally considered a safe config - there's generally no point disallowing access to SYSTEM et al. since they can always override it. – Bob – 2019-06-11T04:17:41.080

Several other guides have suggested that the authorized_keys file should ONLY have a single user access, and the owner of the file should be the user himself, otherwise it gives bad permission errors. I tried Repair-AuthorizationKeyFile on this key, but this didn't work either. SSHD complained of adding permission to user sshd added by the repair function itself. Keeping only the user, and SYSTEM as users, again gives the same issue, Permission denied. It's like catch 22. Not sure how to repair permissions now... – user1173240 – 2019-06-11T04:22:35.117

@user1173240 The easiest way to fix inherited permissions is to reset them on .ssh and clobber child permissions. In the advanced security editor, disable inheritance, save. Remove all entries, enable inheritance again, and tick "replace all child object permission entries with inheritable permission entries", and save again. That should reset .ssh and all its children. See: https://i.stack.imgur.com/IcOUu.gif

– Bob – 2019-06-11T04:29:13.823

@user1173240 I'd like to see a link to those guides if you happen to still have them - it reeks of cargo-cult security trying to apply the Linux security model to Windows. In Linux, root can always read/write every file (barring LSMs) - the Windows equivalent is SYSTEM and removing its access simply does not make sense (and, obviously, stops the sshd service from reading the file). It does nothing for security because SYSTEM can always take ownership and override the permissions anyway; it just doesn't do it implicitly so you get errors instead. – Bob – 2019-06-11T04:34:46.617

1The only things that shouldn't happen are making id_rsa (private key) world/group-accessible (this is default, so don't add Everyone and you're fine) or authorized_keys world/group-writable (again, this is default - in fact, default is stricter; in Linux making authorized_keys world-readable is usually considered fine, equivalent to adding Read to Everyone on Windows, with traverse on parent folders). Administrators group, which by default has access, is generally fine since they can usually elevate to SYSTEM anyway. – Bob – 2019-06-11T04:36:19.187

What you say makes sense. I'll try repairing permissions manually this way and check. As for the guides, there are several..https://techcommunity.microsoft.com/t5/ITOps-Talk-Blog/Installing-and-Configuring-OpenSSH-on-Windows-Server-2019/ba-p/309540, https://docs.microsoft.com/en-us/windows-server/administration/openssh/openssh_keymanagement, https://devblogs.microsoft.com/powershell/using-the-openssh-beta-in-windows-10-fall-creators-update-and-windows-server-1709/...there are several others which talk of using CLI to remove permissions, both on private as well as server public key. – user1173240 – 2019-06-11T04:57:41.900

@user1173240 Keep in mind that this file should not contain private keys, and if by "server public key" you mean the host keys, that's different from authorized keys. The Repair-AuthorizedKeyPermission cmdlet in its current incarnation requires "Full Access" for SYSTEM and optionally allows any level of access from the current user (and implicitly Administrators/SYSTEM groups, see L314). Which is default anyway.

– Bob – 2019-06-11T05:06:16.713

All these recommend using Repair-AuthorizedKeyPermission to set permissions,at least the first link I have given recognized that it adds sshd as NT-Service user and recommends removing it, that's what I faced, but says nothing about adding Administrators, which doesn't get added at all, if removed previously - probably removes it too. Some other answers suggest problems with the repair tool, some other answers on Github suggest the opposite - authorized_keys should only be accessible by the user and sshd, and should be owned by the user, not NT AUTHORITY/SYSTEM or BUILTIN\Administrators. – user1173240 – 2019-06-11T05:06:36.147

1

@user1173240 So, a previous version (which you may be running) incorrectly added sshd rather than SYSTEM, hence the advice to remove sshd. Keep in mind GitHub issues may be outdated. The current version allows/keeps any access/ownership from user/Administrators/SYSTEM and adds (if missing) Full Control to SYSTEM. Removing SYSTEM, evidently, breaks things. At this point resetting it to default inherited values is easiest, and should be safe.

– Bob – 2019-06-11T05:09:39.817

Yes, thank you. I'll try out the suggestion and advise accordingly. – user1173240 – 2019-06-11T05:12:08.403

OK, that worked. Permissions are safely inherited and SFTP is working with keys. Thank you for your help on this. – user1173240 – 2019-06-12T07:33:50.780

2

Try to put more details here, if anyone has installed a built-in openssh server in Windows 10 (build 1809 or later, or Server 2016), whether or not following Microsoft's documents: Installation, Configuration and Key management. Seems they're pretty old or sort of incomplete and need updating.

After installation of this service, start it, you should connect it from your localhost via ssh username@localhost, assuming your Windows login name is username. But we want key based authentications and we must fail only according to Microsoft documents listed above:

  1. We can't rely on Repair-AuthorizedKeyPermission to fix authorized_keys's permission, since we can't install OpenSSHUtils module for now. Reason here, seems the signature is outdated.
  2. As @Bob indicated, we have to comment something in sshd_config if we don't setup key pair for Administrators.

If you just want use a single user's key based authentication, we just have to do as follows (Administrator privilege is required, all based on default built-in openssh server installation):

  1. Since we can't install OpenSSHUtils module, we set the permissions manually. Check authorized_keys's ownership and permissions:
PS C:\>(get-acl .\users\username\.ssh\authorized_keys).owner
username
PS C:\>icacls .\users\username\.ssh\authorized_keys
ssh_host_dsa_key   BUILTIN\Administrators:(F)
                   username:(F) 
                   otheruser1:(IR)
                   otheruser2:(R)
  1. Set correct ownership and permissions for authorized_keys:
PS C:\>icacls .\users\username\.ssh\authorized_keys /inheritance:r
PS C:\>icacls .\users\username\.ssh\authorized_keys /remove otheruser2
  1. Search for and comment group matching policy in sshd_config:
#Match Group administrators
#       AuthorizedKeysFile __PROGRAMDATA__/ssh/administrators_authorized_keys
  1. (Optional) Enable key based authentication. Search for and change the text to:
PubkeyAuthentication yes
  1. (Optional) Disable password based authentication. Search for and change the text to:
PasswordAuthentication no
  1. Copy and paste the user's public key into authorized_keys who you want to connect as.
  2. Restart sshd service. Now you should connect to this host with key authentications.

Consult following links for more detailed contents (this answer comes from):

noyle

Posted 2019-06-07T09:34:30.557

Reputation: 21