Security architecture in Bitvise SSH Server
Bitvise SSH Server acts as an extension of the Windows operating system to support SSH login. As such, it needs to act in ways the OS would act to organize security contexts for logon sessions. This means the main SSH Server process is designed to run as Local System; however, the logon sessions themselves run in security contexts of users who are actually logging in.
When a user logs into the SSH Server, for example to use SFTP or open a terminal session:
- The SSH session will run as Local System until the user is authenticated.
- When the user is authenticated, the thread with the SSH session will switch to that user's security context. If the code implementing the SSH session were to misbehave, it's possible to switch back to the Local System security context from within the thread.
- The SFTP server or terminal session is launched as a separate process entirely in the user's security context. If the code implementing the SFTP server or the terminal shell were to misbehave, it cannot switch to the Local System security context.
Security context for virtual accounts
Virtual accounts configured in SSH Server settings do not exist as Windows accounts, but must still run in a Windows security context. On computers that are not domain controllers, the SSH Server will automatically create and manage a local Windows account for this purpose. On a default, unnamed SSH Server instance, this account is named BvSsh_VirtualUsers. This account is not created during installation, but by the SSH Server after it is started, and only if virtual accounts exist that would use it.
On a named SSH Server installation, the name of this account will be different, but will start with BvSsh_.... For example, if you installed an SSH Server instance named "MyInstance", the account might be named BvSsh_MyInstance. You can use Windows local user management tools (Windows Control Panel > Administrative Tools > Computer Management) to discover the account name. You can also find the name of the account in the SSH Server's textual log files, such as in the log message I_AUTO_ACCOUNT_ENABLED.
Unless a virtual account or virtual group is explicitly configured to use a different security context in Advanced SSH Server settings, the SSH Server will use BvSsh_VirtualUsers (or the equivalent) by default. If a virtual account running in this default context needs to access filesystem resources, Windows filesystem permissions need to be granted to this account.
When the SSH Server is installed on a domain controller, it cannot create a default account to provide a security context for virtual accounts because Windows domain controllers do not support local Windows accounts. In this case, if the domain administrator wishes to use virtual accounts in the SSH Server, they must first create a domain account to provide a security context for virtual account logon sessions. This domain account must be configured as the security context for virtual accounts in Advanced SSH Server settings.
If virtual accounts should be able to access network resources using the credentials of an account that has been configured as a custom security context for virtual users, the password for this account should be added to the SSH Server's password cache using the Manage password cache interface, accessible via the Server tab in the SSH Server Control Panel. This will allow the SSH Server to create a logon session with credentials to access network resources in the name of this account.
Running the SSH Server under a different service account
Bitvise SSH Server is designed to run as Local System, but can run as a different account if you grant it privileges that effectively make it as powerful as Local System. These privileges are:
- Act as part of operating system (SeTcbPrivilege)
- Replace a process level token (SeAssignPrimaryTokenPrivilege)
- Adjust memory quotas for a process (SeIncreaseQuotaPrivilege)
Changing the SSH Server to run in a domain account security context will not grant your SSH users access to domain resources, because the users run in their own security context. If you need users to access network shares, see the page Accessing network shares to configure this in the SSH Server.