VSCode Remote between two AAD-joined Windows PCs is not very seamless

[dfields-msft]

"OpenSSH for Windows" version OpenSSH_for_Windows_8.1p1

Server OperatingSystem Windows 10 20H2

Client OperatingSystem Windows 10 2004 Insider Preview (20214.1001)

What is failing My scenario is using VSCode Remote to connect between my laptop (client) and PC (server) so that I can use the full power of the PC to build, etc. while running the VSCode editor locally on the laptop. Both PCs are running Windows and are AAD-joined. There are a few "speed-bumps" that make configuring this difficult and clunky:

1. I can only authenticate with keyboard-interactive - neither publickey nor gssapi-with-mic work properly, which means I am typing my password repeatedly. (This may be separately tracked by #1543.)
2. Once I'm logged in, VSCode Remote is able to get up and running, but git commands fail to find my credentials since the shell is running in session 0 (non-interactive). (See also #996 which is related.) My hope is that once GSSAPI authentication works in this scenario, the resulting session will have full access to my credentials and resolve this, but I'm not sure whether it will actually work that way...
3. The remote shell is always running with elevated privileges, which feels unsafe; if I were doing my development workflow locally, I wouldn't need to be elevated and I'd prefer to be able to connect as a non-elevated user for VSCode Remote purposes.

As for the specifics of attempting to log in with GSSAPI, I enabled this on the server by adding GSSAuthentication yes to sshd_config and restarting the service. Then I connected from the client using ssh -K, but this just fails with GSS_S_FAILURE in the verbose logs, and moves on to interactive keyboard login.

[dfields-msft]

I was able to work around the git credential limitation by using a PAT with git config --global http.extraHeaders as described in these instructions: https://docs.microsoft.com/en-us/azure/devops/organizations/accounts/use-personal-access-tokens-to-authenticate?view=azure-devops&tabs=preview-page#use-a-pat

However, I'd really prefer to avoid storing my PAT in the environment, and be able to use my logon credentials instead.

[mgkuhn]

One common reason for GSSAPI authentication not working under Active Directory is a mismatch between the provided and the allowed Encryption Types in Active Directory. Windows users usually don't notice if their Kerberos setup is broken, as Windows very quietly falls back to the far less secure NTLM authentication protocol. OpenSSH does not support NTLM authentication, so that's when users usually discover that their Kerberos setup was broken all the time.

What encryption type does klist show for your Kerberos ticket? AES? What encryption types are allowed for your user and the computers their respective MsDS-SupportedEncryptionTypes LDAP attributes in AD? AES?

Sadly, it is 2020, and Active Directory still does not enable Kerberos AES encryption types everywhere by default (presumably because of all those many mission-critical Windows 2000/XP machines still out there that only speak RC4 :-( ).

Another common reason for Kerberos not working is DNS problems, i.e. if a client not being able to find the realm and the associated KDC from the FQDN, or the FQDN not being provided, or not available via a reverse-DNS lookup.

Once you got interactive GSSAPI authentication/delegation to work with ssh -K, you then want to switch from using option -K to adding the equivalent options

GSSAPIAuthentication yes
GSSAPIDelegateCredentials yes

to your .ssh/config, because applications such as git and various IDE's that use ssh under the hood will not call it with -K.

[dfields-msft]

I'm a n00b on most of this... I was able to confirm that klist shows the encryption type for all of my tickets as AES-256-CTS-HMAC-SHA1-96. However, I have no idea how to query the MsDS-SupportedEncryptionTypes attribute and my limited attempts to figure this out through web searches fell short. Does it make a difference that the server in this case is AAD-joined, not AD-joined? [Edit: I did manage to query this property on a couple AD-joined machines using ldp.exe and they included the same AES method in their list. Still can't figure out how to do this for AAD-joined machines or my user account, but my guess is that they support AES too since it was enabled for the old-school AD configurations.]

The configuration is a bit odd, and DNS issues could definitely be contributing... The client and server machines are both AAD-joined, and are connected to the same local subnet on my home network. For some reason, I can't resolve the server name at all from the client machine, even when the VPN connection is active, and have to connect by IP instead. Maybe that's a part of the problem?

[mgkuhn]

I have no expertise at all with AAD (assuming the first A is something to do with Azure). But from years of experience with fixing Kerberos issues, I do recommend making sure that the server's name resolves and reverse resolves well in DNS. Kerberos needs a host name that it can map to a server principal name (SPN). E.g., Kerberos usually does not work for logging into a server addressed just via just its numerical IP address. Both client and server need to agree on what the server's SPN is. Switching on logging helps. On Linux use KRB5_TRACE=/dev/stdout for logging https://web.mit.edu/kerberos/krb5-devel/doc/admin/troubleshoot.html . On Windows the equivalent is presumably some registry setting, e.g. https://docs.microsoft.com/en-us/troubleshoot/windows-server/identity/enable-kerberos-event-logging

[dfields-msft]

@mgkuhn my home network configuration has changed, and forward name lookup is working now. I'm not certain how to verify that reverse-lookup is also working, do you have a suggestion?

I tried enabling Windows Kerberos logging per the link you referenced, but I didn't see anything in the logs at all when I try to connect (looking in Event Viewer under Windows Logs/System). I'm still just getting GSS_S_FAILURE.

[KritR]

Unfortunately I'm facing the same issue at the moment.