bitvise ssh client default local directory

These settings are discussed in our SSH Server Usage FAQ, Q260.įor sessions that access terminal shell or run exec requests, it is not possible to disable Windows profile loading. To avoid this issue, do not enable settings which may cause a Windows profile to be loaded. It is then necessary to re-create the profile to restore functionality. Windows must be restarted to restore functionality.įrom time to time, a Windows profile can become corrupted. When Windows has run out of memory, new profiles cannot be loaded, and SSH sessions fail to work.

Most versions of Windows including current desktop and server versions contain an apparent OS issue which causes Windows to run out of kernel memory after a large number of profiles have been loaded. Loading a profile for a Windows domain account may take a long time, delaying SSH login. There are several SSH Server settings which may cause a user's Windows profile to be loaded as part of SSH session login. If you plan to use Bitvise SSH Server heavily, whether with Windows or virtual accounts, note: If you forget this step, virtual users will still be able to log in, but the SSH Server will not be able to create a logon session for this Windows account that has access to network resources, and implicit access to such resources will fail. The setting can also be configured in a virtual account settings entry, individually for that account.Īfter configuring a Windows account as a security context for virtual accounts, add the password for this Windows account to the SSH Server's password cache:

This shows configuration of security context in a virtual group settings entry, as a default for multiple virtual accounts. The security context for virtual accounts can be changed in Advanced SSH Server settings: If a network share requires a Windows domain user's credentials to access, virtual accounts can be granted this access implicitly, by configuring a domain account as their security context. However, one situation where it can be useful is when virtual accounts need to access network resources. It is normally not necessary to change the security context for virtual accounts. If no virtual accounts are configured, it is disabled automatically.ĭo ensure that BvSsh_VirtualUsers has Windows filesystem permissions needed to access files and directories that you would like virtual users to access.Ĭhanging the security context for virtual accounts It is set to a complex random value by the SSH Server, and is reset periodically during its operation.ĭo not delete or disable the BvSsh_VirtualUsers account. When logging in with a virtual account, all such processes are started in the security context of the Windows account that provides the virtual user security context, and run subject to its Windows permissions.ĭo not try to change the password for BvSsh_VirtualUsers. Any child process started by the SSH session runs in the security context of BvSsh_VirtualUsers.Ĭhild processes include the SSH Server's SFTP subsystem and any terminal shell or exec requests started by the user.The SSH session thread that serves the connection runs in the security context of BvSsh_VirtualUsers.When a virtual account logs into the SSH Server: However, this also allows support for virtual accounts to run in a variety of security contexts.īy default, the SSH Server creates and manages a local Windows account, BvSsh_VirtualUsers, to provide a security context for virtual accounts. It must run as Local System to provide login to Windows accounts. The main SSH Server service runs as Local System. Accounts accessing the server for Git access only.Accounts accessing the server for tunneling only.Accounts accessing the SSH Server for file transfer only.They are the go-to account type for granting limited access, such as for: Virtual accounts are created in SSH Server settings, and exist only in the SSH Server. Configuring Bitvise SSH Server with virtual accounts

Bitvise ssh client default local directory