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)
In addition, the account must be a member of the local Administrators group on the computer where the SSH Server is to run.
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.
When the SSH Server runs as an account other than Local System, then regardless of privileges granted, it is not possible to schedule tasks in Advanced settings > Tasks and actions to run in the Local Service or Network Service security context. To use these security contexts, the SSH Server must run as Local System.
Password storage and hashing
When you connect to the SSH Server using Windows accounts:
By default, the SSH Server does not store Windows account passwords.
If you log in using password authentication, the SSH Server hands the provided password to the Windows LogonUser function to check it. Passwords are not stored unless the SSH Server is configured to cache them using Advanced settings > Access control > Password cache auto-save behavior.
If you log in using public key authentication, then by default, the SSH Server uses Windows APIs to obtain information about the Windows account. The SSH Server then constructs a logon session which does not contain any password credentials. A limitation of this logon mechanism is that the session cannot access network resources or files encrypted using EFS.
Administrators who use Windows accounts with public key authentication, and who want the accounts to be able to access network resources, can consider an option to store Windows account passwords in the SSH Server's password cache. In this case:
The administrator can add a password to the SSH Server's password cache manually using the Manage password cache interface in the SSH Server Control Panel.
The administrator can configure the SSH Server to automatically cache passwords in Advanced settings > Access control > Password cache auto-save behavior.
The password cache is stored in the SSH Server's registry key. This registry key is secured using Windows registry permissions so that only administrators can access it. The passwords are encoded reversibly with an encryption key that is the same on all computers.
When you connect to the SSH Server using virtual accounts:
Virtual account passwords are hashed irreversibly in a manner resistant to brute force attacks on the hashed value. The virtual account password hashes are stored as part of SSH Server settings.
The algorithm used to hash virtual account passwords is denis bider's BusyBeaver, as implemented here:
AtBusyBeaver.h
AtBusyBeaver.cppThe algorithm is described by denis bider here. It is guaranteed to be at least as strong as HMAC-SHA512. Its actual strength is orders of magnitude greater, and is comparable with state-of-the-art password hashing algorithms.
When you export SSH Server settings in textual format, the exported settings will contain irreversible password hashes for virtual accounts. These hashes can be used to guess passwords by brute force. The BusyBeaver algorithm ensures that such attacks are infeasible for complex passwords.
Simple passwords can still be guessed. Even the strongest password hashing does not help if the password is "password1234" or if it is reused from another system.
Before SSH Server version 6.41, the irreversible hash was weaker, using a simple HMAC-SHA1. If your settings contain virtual account passwords that have not been changed since before version 6.41, such passwords will still use HMAC-SHA1. To use the new hash algorithm, you must reset such passwords.
When you configure a password for a Windows file share or for a proxy profile in SSH Server settings:
Such passwords are encrypted reversibly as part of SSH Server settings.
The encryption key is uniquely generated for the Windows instance on which the SSH Server is installed. The encryption key is secured using Windows registry permissions so that only administrators can access it.
The encryption algorithm is AES-256 in CTR mode with an HMAC-SHA512 integrity check.
When you export SSH Server settings in textual format, the exported settings will contain the reversibly encrypted passwords. These cannot be decrypted except with the encryption key, which is unique and only accessible to the machine administrators.