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