Use SSH on Windows, they said…

[admin]

Started as a skunkworks type side project at Microsoft, SSH wormed its way into being an integrated Windows feature both on server and client. The PowerShell team has been evangelizing SSH remoting across all platforms for quite a while now, now more or less openly declaring WinRM remoting „legacy“. But is it all bright and shiny?

„Deny Logon“ policies do not affect SSH

You’re reading correctly. Here we have a machine named PSCONF-MS01 for which a GPO named „Keep Bob Out“ denies a domain user named Bob any sort of interactive, remote-interactive, service or batch logon:

Yet, since PSCONF-MS01 has OpenSSH Server activated and Password Authentication enabled, we can SSH in from another machine:

immediately leading to

Unsurprisingly, this also works with PowerShell 7 and SSH Remoting:

But is it an actual session?​

With credentials exposure and so on? Oh yes, it most certainly is:

The logon type 8 gives us a hint to what is going on here. 8 stands for „Network logon with cleartext credentials“, which is why none of the prepackaged logon types in the group policy applies here. We basically use SSH encryption layer to send cleartext creds to the SSH daemon in a more or less secure manner, and the daemon attempts using them for establishing a logon session. Here’s the accompanying 4648 to the above 4624:

What about WinRM Remoting?​

It depends on what you’re really asking Since WinRM is an integral part of Windows and not a bolted-on port of a UNIX daemon, it handles impersonation more gracefully and creates a logon session of Type 3 (Network logon) without exposing credentials – but at the price, as you probably know, of the next hop not being authenticated unless you configure Kerberos delegation and ensure that Kerberos actually ends up being used (e.g. by not using IP addresses to connect but rather FQDNs).

The logon restrictions set by the above Group Policy will still be bypassed, but since WinRM-based remoting has JEA built in, a user needs to be a local administrator or at least a member of the local Remote Management Users group to access the WinRM endpoint in the first place so can’t be just a random connection attempt.

But what about key-based SSH auth?​

This may come as a surprise, it certainly did to me. Using a private key file with SSH creates a Type 3 logon session which, while also bypassing „Deny Logon“, will not disclose cleartext creds – again, at the price of not being capable of a second hop.

Sounds dramatic. Why is it bad, again?​

In my work, I usually concentrate on protecting privileged credentials from hijacked computers so my typical threat model for this would be a domain admin inadvertently connecting to a compromised system by using SSH remoting with password authentication and leaving their cleartext credentials exposed there. This being bad enough already, my esteemed colleague and security researcher Для просмотра ссылки Войди или Зарегистрируйся pointed out that, if an unprivileged user were to connect to a Domain Controller using SSH, they could be able to initiate a „Remote Potato“ type attack which would lead to compromising credentials of legitimate Tier 0 admins logging on to that box.