search

unreality / nCryptAgent

An SSH agent for hardware backed keys on Windows
Apache License 2.0
42 stars 4 forks source link

Unable to use agent with OpenSSH on Windows 10 #9

Open youk opened 1 year ago

youk commented 1 year ago

Authentication doesn't work for me when using OpenSSH. The running nCryptAgent seems to be ignored. Nothing in nCryptAgent.log. Works with PuTTY though.

Is there any way to debug this?

config.json:

"namedpipe": true

Windows 10 22H2 OpenSSH_for_Windows_9.2p1

unreality commented 1 year ago

Have you made sure the OpenSSH Authentication Agent in Services is stopped and relaunched nCryptAgent? I cannot remember whether an error is thrown if the named pipe already exists, so it may be failing silently if thats the case,,

youk commented 1 year ago

It's stopped, yes. Otherwise there's an error message in the log:

Error result from listener Run(): open \\.\pipe\openssh-ssh-agent: Access is denied.
AbsoluteWisp commented 1 year ago

Wanted to pop in to get notifications on this. Same story here:

Edit: Forgot to mention, just like OP, PuTTY works for me

unreality commented 1 year ago

When you run ssh-add -l does it give a connection error, or an empty list?

youk commented 1 year ago

On my system, the fingerprint of the key added to nCryptAgent is shown.

unreality commented 1 year ago

If ssh-add is listing the nCryptAgent keys, im unsure why SSH itself is failing to enumerate and try them for authentication. Perhaps try connecting again with ssh -vvvv to get up to debug3 level and see if there are any hints?

AbsoluteWisp commented 1 year ago

I did some testing on my own (now that I got reminded that ssh-add -l exists) and I found an unrelated issue that might also be relevant.
When I create a key (tried RSA 2048 and ECDSA 256, both act the same), everything works fine. ssh-add -l shows it, and I can authenticate with it, with both PuTTY and the OpenSSH client.
However, after a restart of the agent (RMB->Exit on the tray icon and starting it back up again) all keys show up as "Missing". The "Public Key Location" field is blank, and the "Errors" field has this message:

NCryptOpenKey for container "C:\\Users\\Adam W�jcik\\AppData\\Local\\Microsoft\\Crypto\\PCPKSP\\3e04953c8be2157363dfbee0bda261ec10c012df\\1e9f96ccaaf251743bbdf936dab8f646afe517e8.PCPKEY" returned NTE_BAD_KEYSET: The operation completed successfully.

(One of the characters in my username shows up weird as it's a diacritic. I double checked on a fully ASCII user Ghostling and the same error occured, so it's only a visual error)

In this state, the key is still listed under ssh-add -l but authentication no longer works:

PS C:\Users\Adam Wójcik> ssh-add -l
256 SHA256:lGBm/tYUm8JP3UwiDprZ29D0vuw4gyaBa7dfQfF6QWM ec (ECDSA)
PS C:\Users\Adam Wójcik> ssh github.com
sign_and_send_pubkey: signing failed for ECDSA "ec" from agent: agent refused operation
git@github.com: Permission denied (publickey).
PS C:\Users\Adam Wójcik>

Checking manually I can confirm that the problematic PCPKEY file is still there.

I am not sure what caused this behaviour to be different from the error I was encountering earlier, where the SSH client didn't acknowledge the agent at all. I am unable to replicate that original problem at all now.

youk commented 1 year ago

@unreality The cause turned out to be the 384-bit ECDSA key which was created in nCryptAgent. For some reason it doesn't play well with OpenSSH server on Linux. I tried nCryptAgent with ECDSA-256 and RSA-2048 keys – both work fine. I also verified that ECDSA-384 key works in the same setup without nCryptAgent (ssh-keygen -t ecdsa -b 384).

The relevant part of OpenSSH client log when using ECDSA-384 key in nCryptAgent:

debug3: ssh_get_authentication_socket_path: path '\\\\.\\pipe\\openssh-ssh-agent'
debug2: get_agent_identities: ssh_agent_bind_hostkey: agent refused operation
debug1: get_agent_identities: agent returned 1 keys
debug1: Will attempt key: TEST ECDSA SHA256:<key_fingerprint> agent
debug1: Will attempt key: <user_profile>/.ssh/id_rsa
debug1: Will attempt key: <user_profile>/.ssh/id_ecdsa
debug1: Will attempt key: <user_profile>/.ssh/id_ecdsa_sk
debug1: Will attempt key: <user_profile>/.ssh/id_ed25519
debug1: Will attempt key: <user_profile>/.ssh/id_ed25519_sk
debug1: Will attempt key: <user_profile>/.ssh/id_xmss
debug1: Will attempt key: <user_profile>/.ssh/id_dsa
debug2: pubkey_prepare: done
debug3: send packet: type 5
debug3: receive packet: type 7
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>
debug3: receive packet: type 6
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug3: send packet: type 50
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
unreality commented 1 year ago

@youk thanks for the investigation, i'll try to find some time to look into ECDSA-384 and see whats going on