When a user establishes an SSH session, and authentication succeeds, the server executes applications (typically a shell process such as cmd.exe) in the user's security context. The server needs to execute with LOCALSYSTEM privileges to access resources required for user authentication and impersonation.

Allowing an anonymous user to directly communicate with code that runs with the same permissions as the operating system itself is the primary reason remote exploits exist.

Privilege separation has been pioneered by the Unix community with the release of OpenSSH 3.2. The main goal of this technology is to prevent anonymous clients from exchanging information with highly privileged software. This is achieved by serving a client with the help of two server-side processes: one that runs with SYSTEM privileges, and another which has practically no privileges (ie. GUEST privileges). The latter process is automatically spawned by the privileged parent. The unprivileged child processes all network data and handles communications with potentially untrusted clients. It relies on the parent process to perform tasks that need privileges, and communicates these requests through a well defined and very simple interface. This way both sides must agree that the client has authenticated before it is granted further access, and even if the unprivileged child is compromised, the intruder cannot gain access to, let alone modify, valuable information.

OpenSSH runs the unprivileged process in the context of a special user account. When you enable SSH Privilege Separation in RemotelyAnywhere, this user is automatically created and its access rights are minimized on the file system and the registry. This usually requires several minutes, especially on large file systems. This special user has very limited rights: only "execute" permissions in the System32 directory, and "read" rights to a minimum set of registry entries. These permissions are required by Windows to execute any and all software. All other access rights are explicitly denied for the special user account.

The Privilege Separation User is created under the name _RA_SSH_COMPUTERNAME. It is maintained by RemotelyAnywhere and you should not modify the account, its group memberships or any other related security settings. This user is created with GUEST privileges, its password is set to a cryptographically random string that is as long as system policies allow. The user account is disabled by default. When RemotelyAnywhere accepts an SSH connection, it changes the user's password, enables the account, logs the user in, stores it's access token handle, resets the password again - and finally disables the user account until it is needed again.

When you install a new hard drive in your computer, Windows grants full access to the "everyone" group to the new harddisk and all of its contents. On such occasions you should use the "Check rights" feature on the SSH Configuration page to set the correct access permissions on your system.

Local or domain security policies might restrict local logins. RemotelyAnywhere attempts to explicitly grant the Privilege Separation User local login privileges in the local security policy - however, if domain policies override the local security policy, the _RA_SSH_COMPUTERNAME user might not be allowed to log in. In this case, Privilege Separation should be disabled or the domain security policy should be changed to be less restrictive.