Configuring Bitvise SSH Server with virtual accounts

Virtual accounts are created in SSH Server settings, and exist only in the SSH Server. They are the go-to account type for granting limited access, such as for:

  • Accounts accessing the SSH Server for file transfer only.
  • Accounts accessing the server for tunneling only.
  • Accounts accessing the server for Git access only.

Security context

The main SSH Server service runs as Local System. It must run as Local System to provide login to Windows accounts. However, this also allows support for virtual accounts to run in a variety of security contexts.

By default, the SSH Server creates and manages a local Windows account, BvSsh_VirtualUsers, to provide a security context for virtual accounts. When a virtual account logs into the SSH Server:

  • The SSH session thread that serves the connection runs in the security context of BvSsh_VirtualUsers.
  • Any child process started by the SSH session runs in the security context of BvSsh_VirtualUsers.

Child processes include the SSH Server's SFTP subsystem; and any terminal shell or exec requests started by the user. When logging in with a virtual account, all such processes are started in the security context of the Windows account that provides the virtual user security context, and run subject to its Windows permissions.

Recommendations:

  • Do not try to change the password for BvSsh_VirtualUsers. It is set to a complex random value by the SSH Server, and is reset periodically during its operation.

  • Do not delete or disable the BvSsh_VirtualUsers account. If no virtual accounts are configured, it is disabled automatically.

  • Do ensure that BvSsh_VirtualUsers has Windows filesystem permissions needed to access files and directories that you would like virtual users to access.

Changing the security context for virtual accounts

It is normally not necessary to change the security context for virtual accounts. However, one situation where it can be useful is when virtual accounts need to access network resources. If a network share requires a Windows domain user's credentials to access, virtual accounts can be granted this access implicitly, by configuring a domain account as their security context.

The security context for virtual accounts can be changed in Advanced SSH Server settings:

This shows configuration of security context in a virtual group settings entry, as a default for multiple virtual accounts. The setting can also be configured in a virtual account settings entry, individually for that account.

After configuring a Windows account as a security context for virtual accounts, add the password for this Windows account to the SSH Server's password cache:

If you forget this step, virtual users will still be able to log in, but the SSH Server will not be able to create a logon session for this Windows account that has access to network resources, and implicit access to such resources will fail.

Windows profile loading

If you plan to use Bitvise SSH Server heavily, whether with Windows or virtual accounts, note:

  • There are several SSH Server settings which may cause a user's Windows profile to be loaded as part of SSH session login.

  • Loading a profile for a Windows domain account may take a long time, delaying SSH login.

  • Most versions of Windows; including current desktop and server versions; contain an apparent OS issue which causes Windows to run out of kernel memory after a large number of profiles have been loaded.

  • When Windows has run out of memory, new profiles cannot be loaded, and SSH sessions fail to work. Windows must be restarted to restore functionality.

  • From time to time, a Windows profile can become corrupted. It is then necessary to re-create the profile to restore functionality.

To avoid this issue, do not enable settings which may cause a Windows profile to be loaded. These settings are discussed in our SSH Server Usage FAQ, Q260.

For sessions that access terminal shell or run exec requests, it is not possible to disable Windows profile loading. Terminal shell and exec requests run third-party software which may require the Windows profile to function.

This affects mainly installations that may load hundreds or thousands of Windows profiles per day. Installations with a two-digit daily number of sessions that may load profiles are unlikely to notice issues.