0

I'm trying to set up SSH to connect to my host using a private key instead of a password, but the Windows SSH client is failing to connect to my host:

PS C:\Users\user> ssh some_user@some_host.com
some_user@some_host.com: Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).

My ssh config file that is located at C:\Users\user\.ssh\config with such configuration:

Host some_host.com
   HostName some_host.com
   IdentityFile C:\Users\user\.ssh\my_private_key_ed25519
   PreferredAuthentications publickey
   PubKeyAuthentication yes
   IdentitiesOnly yes

On the host side, the public key was added to the authorized_keys file. What could be wrong?

upd: here is the output with the -v option:

PS C:\Users\user> ssh -v some_user@some_host.com
OpenSSH_for_Windows_8.6p1, LibreSSL 3.4.3
debug1: Reading configuration data C:\\Users\\user/.ssh/config
debug1: C:\\Users\\user/.ssh/config line 14: Applying options for some_host.com
debug1: Authenticator provider $SSH_SK_PROVIDER did not resolve; disabling
debug1: Connecting to some_host.com [80.66.64.207] port 22.
debug1: Connection established.
debug1: identity file C:\\Users\\user\\.ssh\\my_private_key_ed25519 type 3
debug1: identity file C:\\Users\\user\\.ssh\\my_private_key_ed25519-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_for_Windows_8.6
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.4
debug1: compat_banner: match: OpenSSH_7.4 pat OpenSSH_7.0*,OpenSSH_7.1*,OpenSSH_7.2*,OpenSSH_7.3*,OpenSSH_7.4*,OpenSSH_7.5*,OpenSSH_7.6*,OpenSSH_7.7* compat 0x04000002
debug1: Authenticating to some_host.com:22 as 'some_user'
debug1: load_hostkeys: fopen C:\\Users\\user/.ssh/known_hosts2: No such file or directory
debug1: load_hostkeys: fopen __PROGRAMDATA__\\ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen __PROGRAMDATA__\\ssh/ssh_known_hosts2: No such file or directory
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ssh-ed25519
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: SSH2_MSG_KEX_ECDH_REPLY received
debug1: Server host key: ssh-ed25519 SHA256:adJ3k37I71nepzjc16nAIKz1Z7pen+P1oON1VQu/ZhU
debug1: load_hostkeys: fopen C:\\Users\\user/.ssh/known_hosts2: No such file or directory
debug1: load_hostkeys: fopen __PROGRAMDATA__\\ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen __PROGRAMDATA__\\ssh/ssh_known_hosts2: No such file or directory
debug1: Host 'some_host.com' is known and matches the ED25519 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\\my_private_key_ed25519 ED25519 SHA256:BD7aQc7aF+rVUKOhYfd/f8ra0RKTTswtnttv1wZfz8Q explicit
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<rsa-sha2-256,rsa-sha2-512>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: publickey
debug1: Offering public key: C:\\Users\\user\\.ssh\\my_private_key_ed25519 ED25519 SHA256:BD7aQc7aF+rVUKOhYfd/f8ra0RKTTswtnttv1wZfz8Q explicit
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: No more authentication methods to try.
some_user@some_host.com: Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).
Improve this question
10
  • Provide the verbose logs for both the client and the server.
    – Ramhound
    Commented Dec 22, 2023 at 12:05
  • Please try running ssh with the "-v" flag to print debug output, then edit your question to include the output. This will show what keys ssh tried to use.
    – Kenster
    Commented Dec 22, 2023 at 13:45
  • 1
    It can only be a handful of things - if there's no issue with the private key on the client (such as the ACLs previously mentioned), verify public key is correct in the server's authorized_keys files, and if so, clear it from the file, then echo it to the file via a terminal, and verify its permissions are correct. Also check the server's SSH config to verify everything is correct there regarding public key authorization and algorithm used. (FYI: ChaCha20-Poly1305 or CBC with Encrypt-then-MAC are not secure due to the Terrapin Attack; CVE-2023-48795, CVE-2023-46445, CVE-2023-46446)
    – JW0914
    Commented Dec 27, 2023 at 11:42
  • 1
    According to the ssh debug output, ssh offered my_private_key_ed25519 to the server and the server didn't accept it. Check the server logs for ssh to see if it logged the reason why. If the remote server is unix, ssh logs will normally go to /var/log/syslog or one of the other files in that directory.
    – Kenster
    Commented Dec 27, 2023 at 13:36
  • 1
    If checking the server logs doesn't pan out, run "ls -la" in the .ssh directory on the server, then edit your question to include the output.
    – Kenster
    Commented Dec 27, 2023 at 13:37

1 Answer 1

Reset to default
0

It seems that the public key was incorrectly imported into the server. Solved by removing the ~/.ssh dir and loading the public key using ssh-copy-id on the client machine:

$ ssh-copy-id -i ~/.ssh/my_private_key_ed25519 some_user@some_host.com

But Windows Power Shell doesn't have the ssh-copy-id command so I used Git Bash instead.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .