Accessing network shares through Bitvise SSH Server
Bitvise SSH Server can be configured to provide users with access to network resources exposed by other computers reachable from the computer where the SSH server is installed.
Access to network resources can be configured in the following ways.
If you are using a Windows account, either domain or local, which can log on locally at the server, and has network shares already configured in Windows, you can make these shares available in an SSH session by enabling the setting Map remembered shares in Advanced settings. This setting can be enabled either in the specific account's settings entry, or in a group settings entry from which the account inherits settings.
Note that this feature may not work if you use domain accounts with public key authentication, and no password configured in the SSH server's Password cache. For more information, see the below section Network shares and public key authentication.
If your SSH users are logging in with Windows domain accounts; and if their domain accounts have the Windows security permissions necessary to access the network shares; then these network shares can be accessed through SFTP or SCP without the need to configure additional access credentials:
If the users have access to the server's entire filesystem (their root mount point is mapped to ""), they can access network shares from their SFTP client simply by entering the network path in the form "/computer/sharename".
If users aren't permitted to access the entire filesystem, you can add file shares they should have access to by configuring them as mount points. For example, you can add a mount point that defines SFTP virtual path "/sharename" and maps it to real path "\\computer\sharename".
- If your SSH users aren't logging in with domain accounts, or if they don't have Windows security permissions necessary to access the network shares on other computers, you need to explicitly configure the network shares in Bitvise SSH Server. You can do so as follows:
In Advanced settings, open the group or account settings entry for the account or group that should have access to the network share.
From the group or account settings entry, open Windows file shares, and click Add. Configure the network share, and the credentials necessary to access the share. You can also configure an optional drive letter to which the share should be mapped.
If the user has access to the server's entire filesystem, the user can now access the share through the drive letter. If the user is not permitted to access the entire filesystem, you can allow them to access the file share by adding a mount point that defines SFTP virtual path "/sharename" and maps it to real path "\\computer\sharename", or you can map it to the local drive letter you configured.
Network shares and public key authentication
Bitvise SSH Server supports public key login without the SSH server needing to know the user's password. The SSH server will create a password-less login session by default if the user authenticates using public key, and no password is configured for the user in the SSH server's Password cache.
When a password-less login session is created for a domain account, Windows will lack security credentials that might be necessary to access network shares under that account's identity. As a result, the Map remembered shares feature may not result in usable connections, and any explicitly configured Windows shares will not work unless they allow public access, or a username and password are explicitly configured to access them.
When accessing network shares in an SSH session that uses public key authentication, the following options are available:
Click the Manage password cache link on the Server tab of Bitvise SSH Server Control Panel, and use the password cache management interface to enter a password for the domain account with which you would like to use network shares.
The password will be reversibly encrypted in the Windows registry, protected with Windows security permissions so that it can be accessed only by administrators and processes with equivalent permissions. A user who does not have administrative access will not be able to retrieve the password, but an attacker with administrative access, or someone with direct hardware access to the computer, would be able to if they have the required skills.
Alternately, configure file shares explicitly using the Windows file shares feature (instead of Map remembered shares), and use the Windows file shares entry to explicitly set up the username and password needed to access the share.
Network shares and Kerberos authentication
In domain environments, clients can connect to Bitvise SSH Server using Kerberos authentication over GSSAPI. A logon session created in this way may or may not have implicit access to network shares, depending on whether delegation was permitted by the client when authenticating. Furthermore, Windows supports constrained delegation, which is a much more complex way of selectively granting access to network resources when authenticating using Kerberos.
When a client authenticates using Kerberos, the client will not be able to implicitly access a network share unless delegation is enabled, or constrained delegation is configured in Windows so that implicit access is possible.
If a client is using Kerberos authentication without delegation, but needs to access network shares, configure them explicitly using the Windows file shares feature, and use the Windows file shares entry to explicitly set up the username and password needed to access the share.
Network shares and virtual accounts
Virtual account logon sessions can run in a variety of security contexts, depending on the choice made for the virtual account or virtual group in Advanced SSH Server settings:
By default, virtual accounts use an automatically managed local Windows account managed by the SSH Server. Virtual accounts can also be configured to use a local account, or to execute in the security context of the SSH Server service (not recommended!).
In all of these situations, the security context is a local Windows account, which does not have access to network resources. Such a virtual account can access a network share in the following ways:
If the share requires authentication, credentials to access the network share need to be configured in the Windows file shares section of the virtual account or group settings entry.
Only if the share does not require authentication (not recommended), then a UNC path can be used directly (e.g. in Real root path in mount point configuration), without requiring an entry under Windows file shares.
Virtual accounts can also be configured to run in the security context of a domain account. In this case, the situation is the same as described under Network shares and public key authentication. Even if public key authentication is not used, the SSH Server will create a passwordless logon that won't have access to network shares, unless the password for the domain account is entered in the SSH Server's password cache. Therefore, you will either need to configure a password cache entry for the domain account, or use the Windows file shares setting. See Network shares and public key authentication.
Intermittent reliability problems
In SSH Server versions 8.xx and older; and in versions 9.xx and higher, if Windows session sharing is disabled in Advanced settings; each incoming connection from a client creates a separate Windows logon session. Each logon session makes separate connections to network shares. This is not a problem for file transfer clients that create a single long-lived connection for many transfers. However, problems arise with clients that initiate 10 or even 100 concurrent connections, as well as clients which make a new connection for each file, then disconnect.
The SSH Server can handle an indefinite number of such connections. However, network share servers frequently expect a small number of long-lived connections, and cannot handle a large number of short-lived connections. In such situations, the connection between Windows and the network share can sporadically fail. This causes file transfers to fail. The SSH Server's textual log files show errors such as "The RPC server is unavailable", or "The remote procedure call failed and did not execute", or "A specified logon session does not exist. It may already have been terminated."
Since SSH Server versions 9.xx, you can configure the feature Windows session sharing in Advanced settings, under Sessions. This will cause the SSH Server to cache Windows logon sessions for the period of time you configure, and to reuse the same logon session for multiple connections from the same client. This allows the SSH Server to maintain few and long-lived connections to network shares, even for clients that frequently connect and reconnect. This can substantially reduce the occurrence of intermittent connectivity problems between Windows and the network share server.
If Windows session sharing is already enabled, but you are still seeing network share problems, try configuring a longer Windows session keep-alive time. This is configured in Advanced settings, under Sessions.
The default value is 600 seconds, which is 10 minutes. If the user connects less frequently than every 10 minutes, this will cause the user's connection to create a new Windows logon session, with new network share connections. These new network share connections can fail.
If the user connects every 1 hour, you can change the Windows session keep-alive time setting to e.g. 7200 seconds (2 hours). This way, the user's existing Windows logon session will still be available when the user reconnects, and the network connection that was already established will likely work.