SSH to Linux server with Kerberos does not work

zzbuzzard commented 8 months ago

Prerequisites

[X] Write a descriptive title.
[X] Make sure you are able to repro it on the latest version
[X] Search the existing issues.

Steps to reproduce

I am able to SSH in to a server [user]@[domain] which uses Kerberos using both PuTTY and WSL on my Windows 10 machine. However, mysteriously, using the exact same procedure I am unable to log in using OpenSSH.

PS C:\Users\Z> kinit [user]@[principal]
Password for [user]@[principal]:
New ticket is stored in cache file C:\Users\Z\krb5cc_Z

This appears to run successfully. I then run ssh -K, and fail to authenticate.

PS C:\Users\Z> ssh -K [user]@[domain]
[user]@[domain]: Permission denied (publickey,gssapi-with-mic).

Running these same commands in WSL on this machine succeeds, so I do have access this domain. Furthermore, I am able to log in via PuTTY using plink and MIT Kerberos (though if I understand correctly, I cannot use MIT Kerberos with OpenSSH).

klist output after kinit:

PS C:\Users\Z> klist

Credentials cache: C:\Users\Z\krb5cc_Z

Default principal: [principal], 1 entry found.

[1]  Service Principal:  krbtgt/[principal]@[principal]
     Valid starting:     Nov 03, 2023 21:38:28
     Expires:            Nov 04, 2023 07:38:28

I've been totally stuck on this for many hours now and would appreciate any help. Thank you!

Full output using -v

``` PS C:\Users\Z> ssh -K -v [user]@[domain] OpenSSH_for_Windows_8.1p1, LibreSSL 3.0.2 debug1: Reading configuration data C:\\Users\\Z/.ssh/config debug1: Connecting to [domain] [128.232.69.28] port 22. debug1: Connection established. debug1: identity file C:\\Users\\Z/.ssh/id_rsa type 0 debug1: identity file C:\\Users\\Z/.ssh/id_rsa-cert type -1 debug1: identity file C:\\Users\\Z/.ssh/id_dsa type -1 debug1: identity file C:\\Users\\Z/.ssh/id_dsa-cert type -1 debug1: identity file C:\\Users\\Z/.ssh/id_ecdsa type -1 debug1: identity file C:\\Users\\Z/.ssh/id_ecdsa-cert type -1 debug1: identity file C:\\Users\\Z/.ssh/id_ed25519 type -1 debug1: identity file C:\\Users\\Z/.ssh/id_ed25519-cert type -1 debug1: identity file C:\\Users\\Z/.ssh/id_xmss type -1 debug1: identity file C:\\Users\\Z/.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_8.9p1 Ubuntu-3ubuntu0.4 debug1: match: OpenSSH_8.9p1 Ubuntu-3ubuntu0.4 pat OpenSSH* compat 0x04000000 debug1: Authenticating to [domain]:22 as '[user]' 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: chacha20-poly1305@openssh.com MAC: compression: none debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: compression: none debug1: expecting SSH2_MSG_KEX_ECDH_REPLY debug1: Server host key: ecdsa-sha2-nistp256 SHA256:hsRnCjvHDSaxajVWqyWIdhN7fgW2cOvgQNLpek3DmK0 debug1: Host '[domain]' is known and matches the ECDSA host key. debug1: Found key in C:\\Users\\Z/.ssh/known_hosts:3 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\\Z/.ssh/id_rsa RSA SHA256:kwv0A5Gvvou871mPaE3I8ZxD35ucYrFxLzc7OEYBwYM debug1: Will attempt key: C:\\Users\\Z/.ssh/id_dsa debug1: Will attempt key: C:\\Users\\Z/.ssh/id_ecdsa debug1: Will attempt key: C:\\Users\\Z/.ssh/id_ed25519 debug1: Will attempt key: C:\\Users\\Z/.ssh/id_xmss debug1: SSH2_MSG_EXT_INFO received debug1: kex_input_ext_info: server-sig-algs= debug1: kex_input_ext_info: publickey-hostbound@openssh.com (unrecognised) debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,gssapi-with-mic debug1: Next authentication method: gssapi-with-mic debug1: GSS_S_FAILURE debug1: Next authentication method: publickey debug1: Offering public key: C:\\Users\\Z/.ssh/id_rsa RSA SHA256:kwv0A5Gvvou871mPaE3I8ZxD35ucYrFxLzc7OEYBwYM debug1: Authentications that can continue: publickey,gssapi-with-mic debug1: Trying private key: C:\\Users\\Z/.ssh/id_dsa debug1: Trying private key: C:\\Users\\Z/.ssh/id_ecdsa debug1: Trying private key: C:\\Users\\Z/.ssh/id_ed25519 debug1: Trying private key: C:\\Users\\Z/.ssh/id_xmss debug1: No more authentication methods to try. [user]@[domain]: Permission denied (publickey,gssapi-with-mic). ```

Expected behavior

Log in successfully

Actual behavior

`Permission denied (publickey,gssapi-with-mic).`

Error details

No response

Environment data

Name                           Value
----                           -----
PSVersion                      5.1.19041.3570
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.19041.3570
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1

Version

OpenSSH_for_Windows_8.1p1, LibreSSL 3.0.2

Visuals

No response

maertendMSFT commented 7 months ago

@zzbuzzard, have you tried this using the latest release?

zzbuzzard commented 7 months ago

Hi, sorry I didn't do this initially - I found it difficult to find instructions for updating. Have managed it now though, and unfortunately have the same issue.

PS C:\Users\Z> ssh -V
OpenSSH_for_Windows_9.4p1, LibreSSL 3.7.3
PS C:\Users\Z> ssh -K [user]@[domain]
[user]@[domain]: Permission denied (publickey,gssapi-with-mic).
PS C:\Users\Z> plink -ssh [user]@[domain]
Using username "[user]".
Access granted. Press Return to begin session.

mgkuhn commented 5 months ago

Windows 10 does not come with a kinit command or anything equivalent (sadly)! You, therefore, appear to use the kinit command of some independent Kerberos implementation (e.g. MIT Kerberos for Windows), i.e., something other than Microsoft's built-in SSPI, and OpenSSH for Windows wouldn't know anything about how to use its tickets.

To obtain a Kerberos ticket on Windows 10 for its built-in SSPI implementation, there are mainly three routes:

If your machine is domain-joined, you should automatically get a Kerberos ticket for the domain when you log in
You can also add username@REALM and Kerberos password for getting a ticket as a “Windows Credential” via the Credential Manager GUI in Settings
You can use the cmdkey.exe command to do the same from the command line

Note that cmdkey is not the same as kinit: kinit uses the password entered very briefly to decrypt the ticket-granting-ticket it receives, and then immediately forgets the password, whereas cmdkey saves the password, such that SSPI can use it later to obtain a ticket-granting-ticket whenever one is needed. That's quite different, security-wise.

PuTTY, on the other hand can talk to either SSPI or MIT Kerberos for Windows, so unlike OpenSSH for Windows, it can also be used with MIT's kinit command.

Note that while Windows does not have a kinit command, it does have a klist command. However, you appear to be using a non-Microsoft klist command, presumably because it appears earlier in your PATH?

zzbuzzard commented 5 months ago

Thank you v helpful!

PowerShell / Win32-OpenSSH