Securing Bitvise SSH Server

At default settings, Bitvise 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. Identifying which of the above features you want to limit or disable, and doing so.

  2. 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 Bitvise SSH Server itself.

  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, open the SSH port in your firewall and permit outside connections.

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. 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 disable the following settings:

  • Permit terminal shell. This prevents your users from accessing the command interpreter.

  • Permit exec requests. This prevents your users from executing arbitrary programs via SSH.

  • 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, do not disable exec requests. If you are using it for the terminal console, do not disable the terminal shell. 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'.)

Restricting access to chosen accounts

The first step in this process is to go to the 'Everyone' group under Windows groups in Bitvise SSH Server Advanced settings, 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.

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, exec requests, and the terminal shell.

Filesystem access is controlled under the Virtual filesystem layout section of per-account and per-group SSH server settings. To have a safe default, open 'Virtual filesystem layout' 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 the Read-only mount checkbox 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.