...
Windows has two different ways to generate a SID for a remote user request or sessionlog someone on, either locally or as the Server end of a network request.
If a Userid and Password password is presented along with the request, then the server can use them to login. If it is a Domain Userid it can login to the YALE AD. If it is a Local User then it can verify the password on the local machine and then save the password for NTLM access to services on the local network.
However, sometimes a program will be able to verify a user without using a password. It might use a Certificate, or a public key (SSH), or some biometric thing. In this case it cannot login to the YALE Domain and it has no password to store for NTLM.
However, if it has been permitted (by Group Policy configuration on the computer) to make the request, it can ask Windows to start a process that “impersonates” the SID of the account. This gives the user’s request or session access to local files and services on the local machine that the SID is allowed to use. However, a process running through impersonation has no access to any file or service on any other computer on the network.
If you SSH to an account on another machine and authenticate with a password, then the password is stored and can be used to access network services. If you SSH with your public key, then there is no password and the session uses impersonation and only has implied access to what is permitted to this user on this computer. Of course, you can store a public key or password credential on the machine and code that knows how to find it could start a new network connection.
Powershell Remoting
Some Powershell commands operate on other computers.
If the command has a -Computer parameter and an optional -Credential then it uses WSMan. In a home environment where all the computers are members of a Workgroup and are connected to the same network, then you can probably Enable-PSRemoting (you are given a checkbox to do this when installing Powershell 7) and use NTLM authentication. Then you can execute commands across computers where you have a userid with the same password on two or more machines.
Powershell 7 is also migrating toward an SSH based version of remoting, where you specify -Hostname and -Username instead of Computer and Credential. This works across Windows and Linux systems and will use your SSH public key.
Both the WSMan and SSH versions require some additional configuration and have certain limitations. For example, WSMan can be used by a Powershell 7 client, but it runs old Windows Powershell 5 on the server. To get Powershell SSH remoting to work, you need to edit the SSH configuration on the server.
Windows SSH
Microsoft has an Open Source project to develop OpenSSH for Windows.
SSH creates a session and runs commands on Windows or Linux system on the network. It does not support Microsoft technologies like NTLM or WSMan. To authenticate you either provide a userid and password valid on the other system or else you provide a userid and store a private key file in the .ssh subdirectory of you home directory on the client system and a public key file on the server computer.
Although SSH itself supports commands, there are utilities that use the same connection to transfer files, and VS Code can create a split development environment where the standard VS Code user interface is presented on the client machine, but all files and operations take place on the server machine elsewhere in the network.
The SSH client is installed by default, but the SSH server has to be selected as an Optional Feature of Windows. The server is usually installed by default on Linux systemsit can be saved and used in NTLM (for a local account) or it can be presented to the AD to obtain a Kerberos login credential (for an AD account). Either way this login now has the ability to access both local (on this machine) and network (remote servers) resources as this user.
However, there are an increasing number of ways to login without the local computer seeing a password: ssh with a public key, biometrics, user certificate, Microsoft cloud account, etc. If someone can prove that he is SNARK\bellman or YALE\bellman without actually providing the password, then the local computer operating system can create a session under the SID of that account, but without the ability to use NTLM or Kerberos to access services or data on other computers. This is called “impersonation”.
Even if a session on the computer is created through impersonation and the system has not automatically stored a network credential, the user can still send a password or key to the remote session and allow it to access network services through commands or interfaces that provide userid and password as parameters.
So while Linux users normally prefer to ssh to another computer using public key authentication, you can alternately use a version of the ssh command that passes a userid and password. Public key means impersonation and you will not have access to network resources on the remote system. Userid/password means a complete login and you will have access to all the resources you would have with a traditional Windows login.
Also note that if you ssh to a computer as “bellman” and the Home directory of the “bellman” user on that machine has its own .ssh subdirectory with the bellman secret key, it can use that key as a credential to do a subsequent passthrough ssh to another machine.