Securing Bitvise SSH Server

After initial installation, Bitvise SSH Server will refuse login attempts until settings are changed to permit login for one or more users. The SSH Server can be configured to accept logins from Windows accounts (local or domain accounts created in Windows), as well as virtual accounts (created in the SSH Server).

In Easy settings, under Windows accounts, you can enable the setting Allow login to any Windows account. If you enable this, the SSH Server will permit any user who knows a valid Windows username and password to log in and use the following SSH services:

  • SFTP and SCP file transfer, allowing the user to access all files and folders that can be accessed by the Windows account they used to log in.

  • Access to a Command Prompt via terminal console, allowing the user to execute all programs that can be executed by the Windows account they used to log in.

  • Routing TCP connections through the SSH server, either from the client to the internet, or from the internet and to the client.

Securing Bitvise SSH Server involves:

  1. Configuring the SSH server to allow access only to a restricted subset of Windows accounts configured on the system, or only to virtual accounts configured in the SSH Server itself.

  2. Identifying which of the above features you want to limit or disable, and doing so.

  3. Making sure that strong authentication is in use for those accounts that can log in.

In order to avoid frustration, do not start locking down SSH server settings prematurely. Make sure that you can establish a connection first. Make sure that you and your users can use the SSH features that you want to use.

To avoid security issues, you can conduct such testing and preliminary setup with a closed firewall. Install an SSH client such as Bitvise SSH Client on the same machine where Bitvise SSH Server is installed, and use that client to connect to the SSH server to test the connection. After you are satisfied that the features you require work correctly, start securing SSH server settings. Once your settings are locked down to provide only the types of access you require, configure the SSH Server to accept connections from the internet.

Restricting access to chosen accounts

If you are using Easy settings, disable the checkbox Allow login to any Windows account on the Windows accounts tab.

If you are using Advanced settings, go to the Everyone group under Windows groups, and disable the Login allowed checkbox. This prohibits SSH login to everyone except the users you configure.

In order to allow a Windows account to log in, you now need to merely add an SSH server account settings entry under Windows accounts, and configure the following fields:

  • Windows account domain. Leave this empty if you're adding a local Windows account.

  • Windows account name. The name of the Windows account you are adding. It must be an existing account already created in Windows.

  • Login allowed. Set this to Yes. This permits this particular user to log into the SSH server, overriding the fact that login is disabled in group settings.

For virtual users, similarly, all you need to do is add a virtual account entry, defining a username and password. For virtual users, you don't need to disable the group default for Login allowed, because there are no virtual users other than those that you configure, in the first place.

Disabling features you don't want

If you intend to use Bitvise SSH Server for file transfer, you will want to disable the other SSH features that you don't want your clients to use.

If you are using Easy settings, use them to configure access types for each account you add.

If you are using Advanced settings, the easiest way to disable features for all users is to do so at the group level. At this point, you may want to consult Configuring groups and accounts for an overview of how Bitvise SSH Server treats Windows- and virtual accounts and groups.

In the most common and straightforward case, you will have a single Windows group for Everyone in SSH Server settings. This Windows group controls settings defaults for all Windows accounts that might log in through the SSH server.

Open this group and configure the following settings:

  • Shell access type. Found under Terminal and exec requests. Setting this to No shell access prevents users from executing arbitrary commands. You can also configure this to BvShell, which will provide the user with a limited terminal shell that respects the directories you configure for the user.

  • Permit C2S port forwarding. This prevents your users from accessing other network services over SSH.

  • Permit S2C port forwarding. This prevents your users from providing access to their own network services over SSH.

If you are using Bitvise SSH Server for more than only file transfer, you may want to leave some of these features enabled. In particular, if you are using SSH for tunneling, do not disable port forwarding. If you are using SSH for remote program execution or a remote console, do not disable shell access. Or disable these settings for the Everyone group, but enable them for the particular users that need these features.

If you will be using virtual accounts, apply the same restrictions to your virtual groups. (By default, there is a single virtual group named Virtual Users.)

Limiting directory access

By default, Bitvise SSH Server permits each user to access any and all parts of the filesystem that Windows filesystem permissions allow them access to. Frequently, you want to limit users to be able to access only a particular directory. Note, however, that it is only secure to impose such restrictions if you have also followed instructions above and disabled access to port forwarding and shell access (except BvShell).

Filesystem access is controlled:

  • In Easy settings, under the Virtual filesystem layout section of each account settings entry.
  • In Advanced settings, under the File transfer section of each group and account settings entry.

If you are using Easy settings, make sure the Virtual filesystem layout settings are configured securely for each user.

If you are using Advanced settings:

Open File transfer > Mount points for the Everyone group, edit the default mount point ("/"), and set the Real root path to point to an innocuous, empty directory. Or, if all your users should have access to the same folder, you can configure this to point to that directory.

In per-account settings, you can configure a different set of mount points for each user. Under Virtual filesystem layout settings for the user, disable the Use default layout checkbox. Then configure the Real root path for the default mount point ("/") to specify the directory which you want this user to access.

You can configure multiple mount points in this way, permitting the user to access a selected number of server directories. You can also use mount point permission settings to allow the user to only read, but not write to, files in a particular directory.

Ensuring strong authentication

Password authentication can be secure, but only if the passwords are complex. Unless you want the general public to log into a particular account, you need to ensure that all accounts for which you are permitting SSH login - be they Windows accounts or virtual - are configured with complex passwords. Bitvise SSH Server does impose delays and IP blocking to prevent aspiring attackers from successfully guessing a password, but this will not help if your passwords are as simple as "1234" or "password1".

A reasonably complex password would consist of at least 15 random characters from an alphabet of a-z, A-Z, and 0-9. If the chosen password is truly random, this provides the equivalent of about 90 bits of security. This is not as good as a 128-bit symmetric key, but is secure if the only way the attacker can guess a password is by trying to log in via SSH.

If you also want to protect against an attacker who has access to a cryptographic digest of your password, such as by having a copy of your authentication database, or by having physical read access to your system drive, then you need at least 22 characters from the same alphabet (a-z, A-Z, and 0-9) for security equivalent to a 128-bit symmetric key.

Expanding the password alphabet to include non-alphanumeric symbols may not be as great an idea as commonly supposed. Even if 28 symbols are included, the number of characters needed for 128-bit security is still 20. The 10% savings in password length are outweighed by the hassle of entering the symbols, and even more so by problems with programs that interpret such symbols incorrectly.

It is crucial, however, that you do not create your passwords by hand. If you do so, they will not be random. Use a password management utility to securely store your passwords in an encrypted database, and to randomly generate passwords of the desired length.

Alternately, you can configure your SSH client and server to use public-key authentication. For more information, consult the public key section of the Bitvise SSH Server Usage FAQ.

Avoiding password guessing

Any SSH server that is accessible from the internet on the default SSH port (22) will attract password guessing attempts from random attackers. This is because SSH is widely used to provide administrative access to computers and appliances and is therefore often a high value target.

When installed with default settings, Bitvise SSH Server will take several steps to thwart unauthorized attackers.

One way is by imposing a delay between login attempts. The default delay is 3 seconds. Without any other countermeasures, this 3 second delay would ensure that even an account with a weak password, e.g. 6 letters chosen randomly from an alphabet of 26, would on average take years of back-to-back attempts to guess. (Note that passwords this short are very weak and are highly disrecommended.)

Another way Bitvise SSH Server tries to thwart attackers is through automatic blocking of IP addresses that have recently initiated multiple failed login attempts. In default settings, the SSH Server will block for 1 hour any IP address that initiates more than 20 failed login attempts in 5 minutes.

If you wish to see fewer password guessing attempts, an effective mitigation is to configure the SSH Server to accept connections on a port other than 22. This would not be very effective against a determined attacker, but will avoid random hackers looking for low-hanging fruit. Any random port number between 1024 and 49151 is suitable. The main drawback is that any legitimate client that tries to connect to your server will then need to be configured with the port number in addition to the host name. Some Internet Service Providers may also block connections on non-default ports.

If all of your legitimate connections come from Bitvise SSH Client, you can enable SSH protocol obfuscation in the SSH Server in Advanced settings, under Bindings and UPnP. If you enable obfuscation, only Bitvise SSH Client will be able to connect, and then only if configured with the correct obfuscation keyword.

You can also block connections from specific geographic regions outright. If you never expect to receive legitimate connections from specific regions or countries, you can block them in Advanced settings > Access control > Client address rules. If you block all connections except specific countries, remember to also add IP address allow rules for connections not associated with a country (e.g. from the LAN).

Verifying host keys

Properly verified host keys are essential to the security of the SSH protocol. Many clients exist which do not verify a host key. This happens especially with clients which originally support different protocols, and add SSH as yet another one to support. Such clients are not secure to use.

If the client does not verify the server's host key, it renders the connection vulnerable to a man-in-the-middle attack. This means that anyone who is in a network position between the client and the server - including an ISP, or an attacker that gained control of a network gateway - can modify the connection in such a way as to observe, modify, or inject any and all sensitive information without being noticed.

A host key is verified by a client as follows:

  • The client might be configured with the full public key, or several public keys, corresponding to host keys used by the server. When the client connects, it verifies that the server is using one of these host keys.

  • The client might be configured with one or more host key fingerprints it should expect from the server. A host key fingerprint is a cryptographic digest of the public key portion of the host key. The fingerprint is calculated using a hash function such as SHA-256, SHA-1, or MD5. Due to weaknesses in SHA-1 and MD5, the type of fingerprint which is now most recommended is SHA-256.

  • The client might not be configured with a host key, or might expect a different host key than is received from the server. In this case, a secure client must either prevent the connection, or require the user to verify the fingerprint of the received host key.

For more information about how public keys are used in SSH, for both server and client authentication, please see Public keys in SSH.