Issue
When I try to connect using Windows ssh to Windows OpenSSH server using a private key, ssh still ask for password.
- I have installed OpenSSH by adding OpenSSH Server Windows additional capabilites.
- I started manually the OpenSSH SSH Server Windows service using Windows service management console.
- Then I created a public/private key pair using ssh-keygen -t ed255519
- I have copied the public key in
clientsshaccount.sshdirectory with:
PS C:\Users\user> ssh [email protected] mkdir C:\Users\clientssh\.ssh\
The authenticity of host '127.0.0.1 (127.0.0.1)' can't be established.
ECDSA key fingerprint is SHA256:FD9uvvMTBBDMF3jkzZTMEk7iUImY/a7oZRe+wwusCN4.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '127.0.0.1' (ECDSA) to the list of known hosts.
[email protected]'s password:
PS C:\Users\user> scp .ssh\id_ed25519.pub [email protected]:C:\Users\clientssh\.ssh\authorized_keys
[email protected]'s password:
id_ed25519.pub 100% 103 51.5KB/s 00:00
- And then when I try to connect to
clientsshaccount I am asked the password of the private key which shows that ssh has found it, that it succeeded to uncrypt it (no requested again) but then the key seems to be ignored because I am also requested theclientsshpassword.
PS C:\Users\user> ssh -v [email protected] dir .ssh
OpenSSH_for_Windows_8.1p1, LibreSSL 3.0.2
debug1: Connecting to 127.0.0.1 [127.0.0.1] port 22.
debug1: Connection established.
debug1: identity file C:\\Users\\user/.ssh/id_rsa type -1
debug1: identity file C:\\Users\\user/.ssh/id_rsa-cert type -1
debug1: identity file C:\\Users\\user/.ssh/id_dsa type -1
debug1: identity file C:\\Users\\user/.ssh/id_dsa-cert type -1
debug1: identity file C:\\Users\\user/.ssh/id_ecdsa type -1
debug1: identity file C:\\Users\\user/.ssh/id_ecdsa-cert type -1
debug1: identity file C:\\Users\\user/.ssh/id_ed25519 type -1
debug1: identity file C:\\Users\\user/.ssh/id_ed25519-cert type -1
debug1: identity file C:\\Users\\user/.ssh/id_xmss type -1
debug1: identity file C:\\Users\\user/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_for_Windows_8.1
debug1: Remote protocol version 2.0, remote software version OpenSSH_for_Windows_8.1
debug1: match: OpenSSH_for_Windows_8.1 pat OpenSSH* compat 0x04000000
debug1: Authenticating to 127.0.0.1:22 as 'clientssh'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: [email protected] MAC: <implicit> compression: none
debug1: kex: client->server cipher: [email protected] MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:FD9uvvMTBBDMF3jkzZTMEk7iUImY/a7oZRe+wwusCN4
debug1: Host '127.0.0.1' is known and matches the ECDSA host key.
debug1: Found key in C:\\Users\\user/.ssh/known_hosts:1
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey in after 134217728 blocks
debug1: pubkey_prepare: ssh_get_authentication_socket: No such file or directory
debug1: Will attempt key: C:\\Users\\user/.ssh/id_rsa
debug1: Will attempt key: C:\\Users\\user/.ssh/id_dsa
debug1: Will attempt key: C:\\Users\\user/.ssh/id_ecdsa
debug1: Will attempt key: C:\\Users\\user/.ssh/id_ed25519
debug1: Will attempt key: C:\\Users\\user/.ssh/id_xmss
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Trying private key: C:\\Users\\user/.ssh/id_rsa
debug1: Trying private key: C:\\Users\\user/.ssh/id_dsa
debug1: Trying private key: C:\\Users\\user/.ssh/id_ecdsa
debug1: Trying private key: C:\\Users\\user/.ssh/id_ed25519
debug1: read_passphrase: can't open /dev/tty: No such file or directory
Enter passphrase for key 'C:\Users\user/.ssh/id_ed25519':
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Trying private key: C:\\Users\\user/.ssh/id_xmss
debug1: Next authentication method: keyboard-interactive
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: password
debug1: read_passphrase: can't open /dev/tty: No such file or directory
[email protected]'s password:
debug1: Authentication succeeded (password).
Authenticated to 127.0.0.1 ([127.0.0.1]:22).
debug1: channel 0: new [client-session]
debug1: Requesting [email protected]
debug1: Entering interactive session.
debug1: pledge: network
debug1: client_input_global_request: rtype [email protected] want_reply 0
debug1: Sending command: dir .ssh
Le volume dans le lecteur C n'a pas de nom.
Le numéro de série du volume est FA33-B148
Répertoire de C:\Users\clientssh\.ssh
22/08/2022 16:38 <DIR> .
22/08/2022 16:38 <DIR> ..
22/08/2022 16:38 103 authorized_keys
1 fichier(s) 103 octets
2 Rep(s) 54860242944 octets libres
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: channel 0: free: client-session, nchannels 1
Transferred: sent 2136, received 3084 bytes, in 0.1 seconds
note: I fixed few invalid code page characters in above capture.
I read the other topics close to this one but either they are not applicable because Linux oriented or because there is no real solution. The only thing I get from them is the idea to use -v on ssh. Though this does not helped me a lot...
Solution
I finally found Windows OpenSSH troubleshooting documentation that is located on GitHub (not on traditional Microsoft site!): https://github.com/PowerShell/Win32-OpenSSH/wiki/Troubleshooting-Steps
As explained in that documentation, I added the DEBUG3 log level to OpenSSH server configuration file (lower debug levels do not reveal the issue). And I found that the access to authorization file in clientssh account was authorized for user account.
16004 2022-08-24 10:01:54.598 debug1: trying public key file C:\\Users\\clientssh\\.ssh/authorized_keys
16004 2022-08-24 10:01:54.599 debug3: Bad permissions. Try removing permissions for user: DESKTOP-N2I2AHF\\user (S-1-5-21-2546763314-2673200902-885207948-1001) on file C:/Users/clientssh/.ssh/authorized_keys.
16004 2022-08-24 10:01:54.599 Authentication refused.
This was surprising because I copied the file using ssh.
But I finally understood how the access rights have been corrupted: I had verified with the user account that the authorized file had been correctly copied. This was possible because user account has administrative privileges. And it appears that when you ask to access to a directory you normally have no access rights, instead of impersonating administrator to get the rights, the Explorer modifies the directory access rights to give you permanent access to the directory!
Removing user access to clientssh account allows OpenSSH to work properly.
Answered By - PCh Answer Checked By - Mary Flores (WPSolving Volunteer)