Opening Bitvise SSH Server to access from the internet

This section of Getting Started assumes that:

• You have recently installed Bitvise SSH Server.
• You have learned about how the SSH Server is used with Windows accounts and virtual accounts.
• You have configured Windows or virtual accounts the way you want; perhaps for Git access, or for file transfer.
• You have verified your settings work using an SSH client, which you have previously installed on the same computer.

Verify account restrictions

Before you open your SSH Server to access from the internet:

• Verify that your settings do not grant access to accounts you don't want to log in.
• Verify that the accounts with login rights cannot access aspects of SSH you do not want them to access.
  
  • Accounts meant for file transfer should in most cases not be able to access port forwarding, or an open-ended terminal shell.
  • Accounts meant for port forwarding should in most cases be restricted in destinations they can reach.
  • Accounts meant for Git access should in most cases not be able to use file transfer or port forwarding.

We recommend making these checks using an SSH Client running on the same computer where the SSH Server is running.

Client vs. server port numbers

The following shows listening sockets on an idle server. The SSH Server is running, and has been configured to accept connections on port 47506:

Notice the two entries for port 47506:

• The listening socket on interface 0.0.0.0, port 47506. The address 0.0.0.0 indicates the SSH Server will accept connections on this socket coming from any IPv4 address.
• The listening socket on interface [::], port 47506. The address [::] indicates the SSH Server will accept connections on this socket coming from any IPv6 address.

Now, consider this output, which shows an active connection:

Notice:

• The established connection is identified by two IP address + port number pairs.
• There is the server's address and port combination. In this case, the address is 192.168.2.105, and the port 47506.
• There is the client's address and port combination. In this case, the address is 192.168.2.126, and the port 51344.

When we discuss ports for internet connections, it is almost always the server-side port we have in mind. In this case, this is port 47506. If the SSH Server were configured to listen on the default SSH port, this would be port 22. This is the port that the SSH client connects to. This needs to be a static (non-changing) port number that's known to the client.

There is another port in this screenshot, port 51344. This is the client-side port from which the SSH client is connecting. For almost all purposes, this port number is irrelevant and ignored. It may be recorded, but the exact value is irrelevant to servers, firewalls, and routers.

The only reason for the client-side port number's existence is to identify the specific TCP connection. If this number did not exist, there would not be a way to distinguish multiple connections to the same server, from the same client.

The client-side port number is almost always an arbitrary port number, chosen for the connection by the client's OS.

Ports to open

In most cases, the SSH Server requires only one port to be open in the incoming direction. This is the port number you configured for the SSH Server to accept connections.

• For file transfer, terminal shell, and remote command execution, the one port where the SSH Server listens is the only port that needs to be open.
• For client-to-server port forwarding, it is still usually not necessary to open any additional ports. For outbound connections, firewalls permit arbitrary destinations by default.
• For server-to-client (reverse) port forwarding, additional ports need to be opened only if tunneled connections will be initiated from computers other than the computer on which the SSH Server is running.

The Windows Firewall

We do not recommend disabling the Windows Firewall. The Windows Firewall is crucial to the security of your Windows installation, and should be enabled. We do not recommend disabling it even for testing.

We do not recommend third party products to replace the Windows Firewall. However, using such a third-party replacement is the only circumstance where disabling the Windows Firewall would be expected.

The SSH Server can be configured to automatically manage the Windows Firewall. In Easy settings:

• If the SSH Server is configured to automatically manage the Windows Firewall, it will have a dependency on the Windows Firewall service. The SSH Server service will not start until the Windows Firewall service starts. Starting the SSH Server will also start the Windows Firewall service.
• If the SSH Server is configured not to manage the Windows Firewall, it will not have a dependency on the Windows Firewall. The SSH Server service will start without the Windows Firewall service.

Router

In a home or small office environment, you are likely to be connected to the internet using a router that supports UPnP. In this case, you can instruct the SSH Server to automatically configure the router so that the SSH Server can receive connections from across the internet:

In an organizational environment, UPnP is unlikely to be available. In this case, contact your network administrator to configure any routers and/or firewalls needed to make your SSH Server accessible from the internet.

Advanced Settings

In Advanced SSH Server Settings, it is possible to:

• Configure the SSH Server to accept connections on multiple ports.
• Configure listening settings for IPv4 and IPv6 separately.
• Configure the SSH Server to listen on a specific interface (instead of all interfaces).
• Configure the SSH Server to use obfuscation on a specific port or interface.

We recommend configuring listening ports in Advanced settings only if your desired listening configuration is not supported in Easy settings.

Obfuscation

When obfuscation is enabled on an SSH Server's listening port:

• It is not be possible for clients to connect to that port unless they also support obfuscation, and are configured with the same obfuscation keyword.
• It is more difficult for observers of the SSH session to identify that the protocol being used is SSH.
• Drive-by password guessing is greatly discouraged, because the obfuscation keyword has to be guessed first.

The obfuscation protocol implemented by Bitvise SSH Server and Client is obfuscated-openssh. This is notcompatible with other obfuscation protocols, such as obfs4.