For command line based remote access on Windows there is PowerShell remoting. As long as the computer is part of the domain Kerberos is used to securely authenticate against the remote system. It uses WinRM as a means to connect to the target. By default only users with admin permissions on the remote system can authenticate against the default PowerShell remoting endpoint. You can add more endpoints that grant other users access. I recommend using GPOs to standardize the firewall and WinRM configuration across your environment.
Please note that the remote authentication is treated as a network login which restricts your session to the remote system. If you try to access other systems from there you will encounter the so called double hop problem that can be solved via delegation but needs to be implemented properly.
PowerShell provides the Enter-PSSession
cmdlet to connect to a remote system interactively and New-PSSession
to create a connection object that can be used with the -PSSession
parameter of a lot of cmdlets and it also supports one-to-many connections for bulk operations.
PowerShell remoting is different from a regular SSH connection - instead of maintaining a persistent connection to the remote system, PS remoting takes your command, runs it on the remote system and serializes its output before it's deserialized locally on the source machine. That means text editors like vim cannot be run via WinRM based PS remoting and methods on PS objects are lost. In newer versions of PowerShell, connection negotiation and data transport is also supported with SSH instead of WinRM, but requires additional configuration.