Configuring groups and accounts in Bitvise SSH Server

Unless configured differently during initial setup, Bitvise SSH Server will accept password, NTLM or Kerberos-based login to any Windows account that has Windows permissions log into the machine where the SSH server is running.

When a Windows account user logs in, Bitvise SSH Server will impersonate the security context of that Windows account throughout the user's SSH session. Under default settings, the server will allow any successfully logged on user to take any action that the user is permitted by Windows and file system permissions. Such actions include accessing the terminal shell, running a program, uploading and downloading files, or connecting to another machine using SSH port forwarding.

Most administrators will find it desirable to configure Bitvise SSH Server in a way that restricts users' access further. The groups and accounts sections of Bitvise SSH Server's Advanced settings provide the means for this configurability. The groups and accounts in SSH server settings are an additional layer of security, imposed by the SSH server on top of the Windows permission system. Bitvise SSH Server settings do not replace Windows permissions, but provide complementary settings which Windows does not provide on its own.

Additionally, virtual groups and virtual account settings provide the means to add users in Bitvise SSH Server without having to create separate Windows groups, or having to create and maintain a Windows account for every user.

Windows groups and accounts

By default, the Bitvise SSH Server configuration for Windows groups and accounts is very straightforward. It consists of a single 'Everyone' group. In a default configuration, the SSH server settings for the Everyone group apply to all Windows accounts that log in via SSH.

When a user tries to log into Bitvise SSH Server with a Windows account, the server determines the settings for that account in the following manner:

  • Account settings. The SSH server searches the entries in 'Windows accounts' to find a match for the account that's logging in. If a match is found, the settings in the account entry are superimposed on the settings found for the account's group. If the 'Specify group' option is enabled, it is used to choose the account's group settings entry.

  • Group settings. If the SSH server was able to find a match for a Windows account settings entry in SSH server settings, and if this entry uses the 'Specify group' setting, then Bitvise SSH Server will use the configured group settings entry, under the following conditions: that the specified Windows group settings entry exists in the first place; and that the Windows account is actually a member of that group.

    If any of these conditions is not met, Bitvise SSH Server looks up the local and domain groups of which the account is a member:

    • If none of the user's groups have an SSH server group settings entry, the Everyone group settings entry will be used.

    • If only one of the user's groups has an SSH server group settings entry, that group settings entry will be used, as long as it appears above the Everyone group.

    • If more than one of the user's groups have an SSH server group settings entry, then the user's "primary group" setting in Active Directory will control which group settings entry is used.

    • If more than one of the user's groups have an SSH server group settings entry, but the user is not a domain user, or the "primary group" setting does not resolve the group, then the SSH server will choose the group settings entry that appears first in SSH server settings.

This means that:

  • Bitvise SSH Server account settings can be configured individually by adding individual account entries in 'Windows accounts'.

  • SSH server account settings can be configured en masse, without having to add or maintain individual account entries, by configuring Bitvise SSH Server settings for a number of Windows groups. When there is no individual account settings entry, the SSH server will use appropriate group settings according to the rules described above.

    When configuring settings for multiple Windows accounts through groups, automatic expansion of environment variables in string configuration fields may be helpful. Bitvise SSH Server will substitute environment variables in string fields such as Initial terminal shell directory, Virtual home directory, and others.

Virtual groups and accounts

For administrators who want to avoid setting up a separate Windows account for every SSH user, Bitvise SSH Server provides the means to create virtual accounts. Virtual accounts behave like Windows accounts, except for the following differences:

  • Scope.

    Windows accounts. A Windows account is created in Windows, and can be used to log into Bitvise SSH Server whether or not there is a corresponding Windows account entry. A Windows account exists outside of the SSH server as a Windows security principal.

    Virtual accounts. A virtual account is created by adding an entry to 'Virtual accounts' in Bitvise SSH Server settings. A virtual account exists only inside the SSH server, but there is no awareness of virtual accounts in applications that an SSH session launches. Instead, those external applications are aware of a Windows account that is configured to back the virtual account. The backing Windows account provides an impersonation context on the level of the operating system.

  • Groups.

    Windows groups. The mapping between Windows account entries and Windows group entries in Bitvise SSH Server settings can be complex. It depends on the Windows account's actual Windows group memberships, Active Directory primary group settings, the 'Specify group' setting in the SSH account settings entry, etc.

    Virtual groups.The mapping between a virtual account and its corresponding virtual group is straightforward. The virtual account entry always directly specifies a single corresponding virtual group.

  • Password.

    Windows accounts. The password of a Windows account is maintained by Windows. It is possible to change it either using the Windows Control Panel or Computer Management, or through Bitvise SSH Server during SSH user authentication, or using the included bvPwd command line utility.

    Virtual accounts. The password of a virtual account is maintained in Bitvise SSH Server Settings. It is configured by the administrator, but can also be changed by the user of the virtual account using an SSH client that supports password change during authentication.

  • Backing Windows account. A virtual account still requires configuring a backing Windows account to provide the operating system-level impersonation context. Bitvise SSH Server will impersonate this backing Windows account when the virtual account is logged into. A single backing account can be used for any number of virtual users, and the backing account can be defined either for individual virtual accounts or for whole virtual groups.

    Since version 5.50, it is no longer necessary to store the backing Windows account's password in the SSH server's password cache. However, a logon session created this way will need to use explicit authentication to access network resources.

    When installed on machines that are not domain controllers, Bitvise SSH Server creates and manages a local Windows account. This account is used if no 'Windows account name' is configured for a virtual user. The Windows account is named 'BvSsh_VirtualUsers' on default (unnamed) SSH server installations, but can be named differently if you installed Bitvise SSH Server as a named instance. Run 'net user' from a Command Prompt to discover the name of this account. Domain controllers do not have local accounts, so this feature is not available on domain controllers.

In other respects, a virtual account is just like a Windows account. Virtual account settings are superimposed on the corresponding virtual group settings just like with Windows group and account settings entries. All the SSH server settings for virtual accounts that look the same as for Windows accounts behave the same way.