Running Bitvise SSH Client as a Windows Service

It is possible to run a Windows program as a system service. The advantage of services is that they can be started at boot time independently of any logon session, and will continue to run as users log on and off of the machine.

Frequently users would like to run Bitvise SSH Client as a service so that its port forwarding features would come into effect as soon as the machine boots and remain active regardless of users logging on and off of the machine.

Bitvise SSH Client itself does not run as a service, but it can be encapsulated inside a program that enables this. A few such programs we're aware of are:

Stnlc and the Log Utility

Bitvise SSH Client includes not only the graphical client, but a number of command line clients which can perform the same tasks. The command line client stnlc exposes static port forwarding, dynamic port forwarding, and FTP bridge functionality. For information about command line parameters supported by stnlc, run it as follows:

  C:\>stnlc -?

or as follows:

  C:\>stnlc -? | more

If you wish to set up Bitvise SSH Client to provide port forwarding or the FTP bridge as a service, we recommend using stnlc in combination with the log utility. In this case, the full command to execute might be as follows:

  log -tcxo "C:\Client Logs\Stnlc" stnlc -unat -profile=...

This will capture the client's output and store it in files in the specified location. The captured output will be useful in the event that you need to perform any diagnostics (which is likely!).

The -unat parameter tells stnlc to run unattended. Without this parameter, it will display an interactive prompt and exit if it's run by a program that closes the standard input.

Host Key Verification

The most common issue when using Bitvise SSH Client non-interactively occurs when the client is run under a different Windows account than was previously used interactively, and the client has no way to verify the server's host key.

Verification of the server's host key is essential to the security of the SSH session, so this step cannot be skipped. There are a number of ways in which the SSH Client can be told what host keys the server might use that the Client can accept:

  • When you connect to the server interactively using the graphical SSH Client, and manually verify the server's host key, the SSH Client will store the host key in the Windows registry, but only for the currently logged on Windows user. All aspects of the SSH Client will then be able to connect to that server and trust that host key, as long as they are run in a Windows logon session belonging to the same Windows user.
     
  • A host key can also be stored in a Bitvise SSH Client profile, and will then be trusted for the server connected to with that profile, regardless of the Windows logon session in which the connection occurs. If you have a host key that is trusted in the Windows registry, and you want to copy it to a profile:
     
    1. Open the profile using the graphical Bitvise SSH Client.
    2. Open the Host key manager interface from the Login tab of the SSH Client.
    3. Find the host key, right click it, and select Copy to profile.
     
  • A host key or its fingerprint can be passed to any instance of the SSH Client - graphical or command line - using the following command line parameters:
     
    • -hostKeyFile=...: Specifies a file in which one or more host keys are stored.
    • -hostKeyFp=...: Specifies a SHA-256, Bubble-Babble, or MD5 fingerprint of a host key to trust.

If the server has multiple host keys, make sure that the unattended client has access to information about all of the host keys that the server might present. Otherwise, if the unattended client negotiates a different host key algorithm than the graphical client, host key verification may fail because the server will be presenting a different host key.

Public Key Authentication

Like with host key verification, when the SSH Client is run unattended under a different Windows account than when the Client is used interactively, it cannot access authentication keypairs that are stored in a different Windows user's registry.

There are a number of ways an authentication keypair can be passed to the SSH Client when it's running under a different account:

  • In the graphical SSH Client that has access to the keypair, use the Client key manager to export the full keypair into a file. Then, log into the other Windows account, run the graphical SSH Client, and use the Client key manager to import the keypair. This will allow you to use the keypair under that account using the -pk=... parameter.

  • Instead of importing the keypair using the other Windows account, you can also pass it directly to a command line SSH client using the -keypairFile=... parameter. For example:

    sftpc user@host:port -hostKeyFile=... -keypairFile=... cd /dir; put *.txt

  • A client authentication keypair can also be stored in a Bitvise SSH Client profile. To prepare a profile so that it will contain a keypair, open the graphical SSH Client that has access to the keypair. Configure host settings and use Save profile as to save the profile. Then, use the Client key manager, right click on the keypair, and select Copy to profile. If you do the same for the host key, using instructions in the previous section, you can then use the profile as follows:

    sftpc -profile=C:\Path\Profile.bscp cd /dir; put *.txt

    This assumes you configured Login > Authentication > Initial method to publickey, and the Client key setting to e.g. Profile 1 or Auto. As an alternative, you can use e.g. -pk=p1 on the command line to use the public key in location Profile 1.