Prerequisites
CoreSSH Server is supported on Windows 7 and Server 2008 R2 and newer, and Apple Silicon or Intel Macs using version macOS 11.5 (Big Sur) or newer. In order for the application to function properly, the following prerequisites must be met on the target machine.
- .NET: The application requires that .NET 6 or higher is installed to the system. Please refer to the Microsoft documentation for instructions to install .NET on your version of macOS/Linux. In most cases, this can be achieved using the following commands.
- For RedHat/CentOS derivative distributions: sudo yum install dotnet-runtime-6.0
- For Debian/Ubuntu derivative distributions: sudo apt-get install dotnet-runtime-6.0
Quickstart Guide
CoreSSH Server offers an intuitive setup process on both Windows and macOS, allowing you to start secure file transfers within minutes. Follow these steps to configure and connect to your server quickly.
Setting Up CoreSSH Server
CoreSSH Server is ready to use out-of-the-box with no additional configuration required. You may optionally configure Network settings or set a base directory for SFTP access in the Default Root Directory setting. After making any changes, click Save Settings to apply them.
Creating a User
Navigate to the Users page in the Admin Console and click New User.... Enter the username, password, and default directory. For more information on types of users see the User Accounts topic. For information on best practices see the Security topic.
Starting the Server
CoreSSH Server starts automatically upon installation. You can control the status using the system tray app (Windows) or menu bar app (macOS) for quick access to common controls and status.
Use any SFTP or SSH client to connect to the server once it's running.
For Example:
sftp myuser@localhost
Troubleshooting Connectivity
If you encounter issues reaching the server, consider the following:
- Check the network configuration to ensure that the server machine is accessible from the client machine (e.g. ping).
- Ensure firewalls or antivirus settings are not blocking the connection and a TCP connection can be established (e.g. telnet).
- Confirm that the user account being used for authentication has been properly configured in the Users section.
Next Steps
Once connected, you can securely transfer files using the SFTP client. For information on logging, see the Logging topic. For other advanced features please see the corresponding topic. That's it! Your CoreSSH Server is now ready to use for secure file transfers.
User Accounts
CoreSSH Server supports two types of accounts. Virtual Users and Windows Users or Groups. You can configure the server to use either Virtual Users (managed within CoreSSH) or NT User Accounts (from the local Windows system or an Active Directory domain).
Virtual Users
Users are defined directly within the CoreSSH Server application. The application is responsible for allowing the creation, renaming, and deletion of these users. During SSH authentication the application will verify the identity of these users using predefined credentials.
Supported Authentication Methods:
- Password
- Public Key
- Multi-factor (Password + Public Key)
Windows Users and Groups
CoreSSH can be configured to authenticate users against the local Windows system or an Active Directory domain. When an Windows user or group member logs in, CoreSSH delegates the authentication to the Windows system or domain controller, which validates the credentials.
Supported Authentication Methods:
- Password (Network Logon or Interactive Logon)
- Public Key (File-Based or Certificate Store-Based)
macOS/Linux Users
CoreSSH can be configured to authenticate users against the local system. When an macOS user or group member logs in, CoreSSH delegates the authentication to the system PAM module, which validates the credentials.
Supported Authentication Methods:
- Password
Monitoring
CoreSSH Server provides tools to oversee and manage active connections in real-time, allowing administrators to track activity, view detailed connection information, and take immediate action when needed.
Admin Console
The Admin Console offers a user-friendly interface for monitoring and managing sessions on the Status page. View the live list of connected users, IP addresses, and session duration. Each active session can be disconnected directly from this interface by clicking the Disconnect button.
REST API Session Management
For advanced automation or integration with external systems, the CoreSSH Server also supports session management through a REST API. The API provides the /api/sessions endpoint, which supports both GET and POST operations to manage sessions.
Logging
The Logging settings allow you to control how the server logs its activities and tracks trace information. The options described below provide flexibility in how logs are written, stored, and rotated, allowing you to manage server log files effectively. Alternatively you can configure logging using the Registry Settings. Below is an overview of each setting.
Log Mode
Specifies the level of detail to log in the Log window. The available levels are detailed below for convenience. The Verbose setting will enable a large amount of logging and it is recommended to revert to a lower log mode setting when you are done using it.
- Off - Nothing is logged.
- Error - Only errors are logged.
- Warning - and warnings are logged.
- Info (default) - Errors, warnings and informational messages are logged.
- Verbose - All messages, including those useful for debugging and troubleshooting are logged.
Log SSH Packets
When this option is enabled and Log Mode is set to Verbose, the raw SSH packets will be included in the log. The packet contents will contain file content but will not contain sensitive information such as passwords.
- 0 - Disabled (default)
- 1 - Enabled
Rotate Log File Interval
Specifies an interval based on a number of days. After the specified number of days have elapsed, the log will be rotated meaning the log will be written to a different file. When a log is rotated the old log will be renamed to the format "logname-yyyy-MM-dd".
Delete Log File Interval
This setting only applies when using the RotateLogDays setting is greater than 0. Specifies an age limit in a number of days. After the specified number of days have elapsed, any log files older than the age limit will be deleted.
Encryption at Rest
The Encryption tab provides an optional way to encrypt files at rest. When the Enable Encryption At Rest checkbox is checked, the files on the server will remain encrypted on disk and will be transparently encrypted and decrypted as necessary. Users who authenticate to CoreSSH Server and download a file will obtain decrypted data but all file data will remain encrypted on the server.
Enabling Encryption
To enable encryption at rest, specify and confirm the encryption password. The password itself is encrypted by the system and saved in the registry (see Settings for details).
The first time encryption is enabled and Save Changes is pressed, all files present in the server root directory, a user-specific root directory, or a sub-directory therein will be encrypted. Depending on the number and size of files this may take some time.
After the initial encryption completes, it is expected that files will only be added to the server's filesystem using the SFTP protocol. Plain files created directly on disk alongside encrypted files will not automatically be encrypted and will not be available to users.
Changing The Password
To change the password, visit the Encryption tab and use the Change... button to change the password. You will be prompted to enter your current password, followed by the new password and a confirmation of the new password. When Save Changes is pressed, the operation will begin. This operation is faster than encrypting or decrypting files, but may still take some time depending on the number of files present.
Disabling Encryption
To disable data encryption, uncheck the Enable Encryption At Rest checkbox on the Encryption tab. After unchecking, you will be prompted to enter the current password in order to proceed. Once the password is verified, click Save Changes to begin the decryption process. When Save Changes is pressed, the encrypted files will be decrypted. Depending on the number and size of files, this operation may take some time.
Encryption Format Notes
Files are encrypted using standard disk encryption techniques leveraging the XTS-AES 256-bit block cipher algorithm. The encrypted files on disk will have an .aesf file extension. This file format is the same format as used by AES Drive. Please see The AES Drive documentation for details.
Supported Protocols
CoreSSH Server supports various protocols to facilitate data transfer and ensure compatibility with various types of clients. Please see the Settings page for additional information on configuring these settings.
| Name | Description |
| SFTP | Allows any standard SFTP client using SFTP v3 protocol using and modern authentication methods. |
| SCP | Allows file transfer using the secure copy protocol. Support for any command line SCP client. |
| PowerShell | Windows only. Allows remote management from any standard SSH 2.0 client with a Windows PowerShell Host entry point. |
| SExec | Allows remote command execution option (Sexec/SSH Exec) found in most SSH clients. |
| SShell | Allows remote management from any standard SSH 2.0 client using a default shell. |
Additional Information
Below are a few more details about each of the above protocols and corresponding links where you can learn more.
- For SFTP and SCP, the RootDirectory setting of the Users Key governs what will be visible to logged in clients.
- For remote management protocols, the session will be started in the %UserProfile% directory.
- Connections have been tested with a variety of clients including PuTTY, FileZilla, OpenSSH, iPhone, Android, Linux/Unix, as well as our own SSH client solutions.
- By default, the VT100+ emulation support will be enabled for any clients identifying themselves as vt* terminals or as xterm.
Admin Console
The Admin Console allows administrators to manage and configure server settings directly from a web browser. The admin password required for login is set during installation, either through the setup wizard or a silent install.
Accessing the Admin Console
To open the Admin Console, click Open button in the tray app. The tray app can be found in the system tray on Windows or in the menu bar on macOS. This will launch the browser to the login page.
Setting the Admin Password
During installation, CoreSSH creates a pseudo account to facilitate management via the Admin Console. The setup prompts the user to define an admin password, which grants access to manage the server securely. These credentials are required for signing in and configuring server settings.
Resetting the Admin Password
If the admin needs to reset the Admin Console password, there are two methods available:
This command-line flag allows resetting the Admin Console password. Please refer to the Command Line section for more details.
/resetpassword:<newPassword>
This button in the system tray app (Windows) or menu bar app (macOS) will prompt the user to enter and confirm a new password.
Reset Password...
Admin Console Configuration
The Admin Console... button in the tray app offers quick access to configure settings for the HTTP listener interface and admin console.
- Server Interface: The network interface on which the HTTP server will listen for connections. By default, this is set to 127.0.0.1.
- Server Port: The local port on which the interface will accept incoming connections. By default, the HTTP server will use port 8123.
- Enable TLS: If checked, the HTTP connections will be encrypted. A TLS certificate path must be specified, or a new one can be generated.
- TLS Certificate: The path of the TLS certificate on the local machine.
Additional Information
The Admin Console functions as a REST client, communicating with a built-in HTTP server to interact with the CoreSSH configuration and actions. The HTTP server provides an interface through which the Admin Console sends requests and receives responses, allowing users to configure and manage the CoreSSH server.
Troubleshooting
If you are having problems with CoreSSH Server, our support team is here to help. Visit https://www.nsoftware.com/support/submit.aspx to submit a ticket. Please be as detailed as possible about your issue. It is also helpful if you generate and send a log file to support@nsoftware.com.
How to Generate a Log File
- Navigate to the Settings tab.
- Enable Write Log to a File and specify a local file.
- Increase the Log Mode.
- Click the Save Changes button.
- Reproduce the issue.
- Click the Stop button.
Note that the length of time it takes for any operation is increased when Debug logging is enabled. The amount of data logged with this option enabled is substantial. We recommend enabling these settings for debugging purposes only.
Security
This section explains how the application operates and makes recommendations to ensure your server operates securely and reliably.
Overview
Anyone who can write to the HKEY_LOCAL_MACHINE hive of the registry, by default members of the BUILTIN Administrators group have full control over the server. On macOS and Linux, anyone who can modify the configuration file has full control over the server. For details on how CoreSSH Server stores settings see the Configuration File topic.
Similarly, anyone who is granted access through the REST API by cookie authentication or API Key authentication is considered a trusted within the security architecture of CoreSSH to make changes to CoreSSH Server configuration.
Logon Information
CoreSSH Server supports two types of user accounts: system-based users and virtual users. System users are authenticated using the underlying operating system's native mechanisms, and their file and shell access is performed using that user's permissions.
Virtual users are managed entirely within CoreSSH Server and do not correspond to any accounts on the host system. Their access is authenticated by validating credentials against securely stored hashes, and all actions are carried out using the identity of the CoreSSH process. Shell access is not available for virtual users.
Additional Details
For NT User Accounts, the credentials provided in the authentication request are used to try to retrieve an impersonation token using the Windows LogonUser API with the flags LOGON32_LOGON_NETWORK and LOGON32_PROVIDER_DEFAULT by default. If the call is successful, then we next ensure that the user is a memberOf a group specified in the CoreSSH configuration settings (or is an individual Windows User specified in the Users page). After that the user is considered authorized.
On macOS and Linux, system users are authenticated via PAM (Pluggable Authentication Modules) using a native helper library that performs account management checks for account validity (e.g., expiration, lockout, etc.). The PAM service name used by default is login, which means CoreSSH relies on the system's /etc/pam.d/login configuration.
Authentication for virtual users is handled internally by comparing the submitted password, after applying a PBKDF2-based derivation, against a stored hash. These hashes are persisted either in the Windows registry or in the configuration file depending on the platform. No impersonation is performed for virtual users; all file system access and command execution occur using the identity of the CoreSSH Server process.
Resource Access
When an SFTP channel is requested, the server processes incoming packets to perform operations such as read, write, rename, and delete. On Windows, SFTP operations are handled within the current process in an impersonation thread. On macOS and Linux, the server starts a separate worker process that runs under the identity of the authenticated Linux user. For virtual users on these platforms, SFTP operations run under the main process identity without impersonation and shell access is not available.
In shell sessions across all platforms, a separate worker process is created to isolate execution from the main server. On Windows, this worker process is launched using the Windows user token, applying their privileges to the entire process. On macOS and Linux, the worker process is similarly launched as the authenticated Linux user, leveraging PAM for authentication. This means that shell commands are executed in a dedicated process fully operating under that user's identity.
Application Identity
On Windows, the service runs as Local System by default, but this can be changed via the Log on As setting in the Service properties page.
On macOS and Linux, the service runs as root, configured via a LaunchDaemon on macOS or equivalent service mechanism on Linux.
The tray/menu bar UI does not enforce a specific identity and will prompt the user to elevate using platform-specific mechanisms when required.
Passwords and Hashing
When you connect to the server using system accounts (e.g., NT User Accounts on Windows or PAM-authenticated users on macOS/Linux), we do not store account passwords or password material. These accounts are verified at runtime using operating system APIs such as LogonUser (Windows) or pam_authenticate (macOS/Linux).
For virtual user accounts, when the account is initially created, we compute a hash of the password using the password derivation function PBKDF2. We use the HMACSHA512 hash algorithm with 10000 iterations, and store the resulting base64-encoded value along with the salt.
This hash is stored in the Password value in the registry on Windows or configuration file on macOS/Linux. Please see Users for more information. Note that even the strongest password hashing provides limited protection if weak or reused passwords are chosen. Strong, unique passwords should always be encouraged.
Public Key Authentication
The keys should be in SSH public key format according to RFC 4253. For example:
ssh-rsa AAAAB3NzaC1yc2EA...rPFBe7Pnc= rsa-key-20110822
CoreSSH Server has no way to match the public keys stored in the certificate store with actual Windows local/domain users. Make sure that the selected certificate store does not contain certificates for individuals who should not be allowed access to the server.
Cipher Suites
CoreSSH Server supports configuring cipher suites to control encryption, key exchange, MAC, and public key algorithms used for secure communication and server identification. Administrators can specify preferred algorithms as needed to enhance security or enhance compatibility. This can be found in the SSH Protocol settings in the Admin Console.
SSH Encryption Algorithms
Defines the encryption algorithms used to secure data during transmission. This should be set to an ordered list of algorithms with the preferred algorithms toward the beginning of the list. The format should be a comma-separated string.
aes256-ctr,aes192-ctr,aes128-ctr
SSH Key Exchange Algorithms
Specifies the algorithms used for securely exchanging encryption keys. This should be set to an ordered list of algorithms with the preferred algorithms toward the beginning of the list. The format should be a comma-separated string.
curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521
SSH MAC Algorithms
Defines the algorithms for negotiating message authentication during key exchange. This should be set to an ordered list of algorithms with the preferred algorithms toward the beginning of the list. The format should be a comma-separated string.
hmac-sha2-256,hmac-sha2-512
IP Whitelisting
CoreSSH Server supports configuring access control by specifying allowed and blocked IP addresses or subnets. This allows you to restrict unauthorized access to the server and define which clients can connect. For more information about the example formatting, please see the Configuration File topic. This can be found in the Protection settings in the Admin Console.
Allowed Clients
Defines a whitelist of IP addresses or subnets that are permitted to connect to the server. This should be set to a comma-separated list of IP addresses. The special value of * will be interpreted
10.0.1.*,10.0.2.225
Blocked Clients
Specifies a blacklist of IP addresses or subnets that are denied access to the server. This should be set to a comma-separated list of IP addresses.
121.31.51.74,65.2.33.32
Flood Protection
CoreSSH Server supports automatic blocking of IP addresses after excessive failed login attempts to prevent brute-force attacks. Administrators can configure the maximum failed attempts and block duration to enhance security and mitigate unauthorized access. This can be found in the Protection settings in the Admin Console.
Enable Automatic Blocking
Blocks an IP address after a specified number of failed login attempts in the Maximum Authentication Attempts setting.
Block Duration
Specifies how long an IP address remains blocked after failed login attempts.
Other Measures
Maximum Authentication Attempts
Limits the number of failed login attempts allowed per session to prevent brute-force attacks.
Idle Session Timeout
Terminates inactive sessions after a specified duration to reduce the risk of unauthorized access.
Disable Compression
Disables data compression to prevent vulnerabilities related to compression-based attacks.
Advanced
The following settings allow for a more fine-tuned setup of CoreSSH Server.
Configuration File
CoreSSH Server supports configuration files across platforms with a few notable differences in how they are used.
Windows Configuration File
When CoreSSH Server is running on Windows, configuration files can be used as portable containers to migrate settings from one machine to another. This is accomplished using the Tray App buttons Help > Import Settings... and Help > Export Settings....
The application uses the registry as the central control point. Configuration file support on Windows allows importing settings from an INI-format file into the registry, or exporting settings from the registry into an INI-format file.
macOS and Linux Configuration File
When CoreSSH Server is running on macOS or Linux, configuration files serve as the central control point, and the application stores and uses settings directly from the file. By default, this file uses the INI-format and is located in the installation directory:
/Library/Application Support/CoreSSH Server/service/CoreSSHServer.conf
Command Line
CoreSSH Server supports a range of command line arguments on Windows, macOS, and Linux for managing service operations, modifying settings, and automating configuration tasks.
Windows Command Line Arguments
- To start CoreSSH Server: CoreSSHServer.exe /start
- To stop CoreSSH Server: CoreSSHServer.exe /stop
- To restart CoreSSH Server: CoreSSHServer.exe /restart
- To exit CoreSSH Server Tray App: CoreSSHServer.exe /exit
- To register the CoreSSH Server service process: CoreSSHServer.exe /registerservice
- To unregister the CoreSSH Server service process: CoreSSHServer.exe /unregisterservice
- To modify the server's registry settings: CoreSSHServer.exe /modifyreg:
- To modify and save the server's configuration settings: CoreSSHServer.exe /savesettings:TraceLevel=4
- To import settings from a configuration file: CoreSSHServer.exe /importsettings:"C:\path\to\file.ini"
- To reset the web admin password: CoreSSHServer.exe /resetpassword:newPass
macOS and Linux Command Line Arguments
- To start CoreSSH Server: CoreSSHServer.exe /servicestart
- To stop CoreSSH Server: CoreSSHServer.exe /servicestop
- To register the CoreSSH Server service process: CoreSSHServer.exe /registerservice
- To unregister the CoreSSH Server service process: CoreSSHServer.exe /unregisterservice
Host Key Notes
The CoreSSH Server supports the management of multiple host keys by default, with the ability to view, update, and generate new host keys through the Admin Console or REST API.
Host Keys
Host keys are presented by the server during SSH negotiation. SSH clients store host keys for the servers they have connected to. It allows the client to ensure the server is indeed the one it wanted to connect. CoreSSH Server generates three default host keys during installation, each corresponding to a different cryptographic algorithm. These can be found in the Host Keys section of the Admin Console.
- RSA: Supported key sizes: 2048-bit, 3072-bit (default), and 4096-bit.
- ECDSA: Supported key sizes: 256-bit (default), 384-bit, and 521-bit.
- Ed25519: Supported key size: Fixed 256-bit.
Host Keys Configuration
The settings for each host key are stored separately in the Windows registry under the path HKEY_LOCAL_MACHINE\SOFTWARE\CoreSSH\CoreSSHServer\24\HostKeys\{algorithm}. Please see Host Keys for more information.
Host Key Management in the REST API
The CoreSSH REST API provides several operations for managing host keys:
- GET /api/hostkeys: Retrieves all host key settings.
- POST /api/hostkeys/{algorithm}: Allows users to enable, disable, or generate a new host key.
API Key Notes
API keys can be used within API requests by including an x-coressh-api-key header in the HTTP request, with the value set to an appropriate User's API Key. API keys are unique, randomly generated identifiers that users authenticate with to access the API.
The web admin can issue requests to create a new API key and distinguish it by providing a keyName. This value is 32 characters long and includes a randomly generated 24-byte array, base64URL envard and prefixed by the keyName.
Warning: The raw value of the API key will be shown only once. Make sure to copy the value when creating the key and store it in a secure location.
When the admin creates an API key, the raw API key value is shown only once. The admin should copy it and provide it to a specific user. This user will then need to present the raw API key in the x-coressh-api-key header for all REST API requests.
The API keys are stored under the registry path HKEY_LOCAL_MACHINE\SOFTWARE\CoreSSH\CoreSSHServer\24\APIKeys. Each API key has its own individual subkey within this path. The name of the subkey is determined by the key name provided by the web admin when the API key is created. It contains a string type setting APIKey, and the value will be the hash derived using PBKDF2 with a random 24-byte salt.
The supported operations are: GET, POST, and DELETE. The parameters needed are: keyName (a description provided by users) and APIKey.
API key operations can ONLY be performed by the web admin. These operations cannot be performed by a user possessing another API key.
- GET: Performing a GET request at the /api/apikeys endpoint will return only the full list of keyName values of API keys currently created, and nothing else.
- POST: This operation can be used to create a new API key. The request body will contain the keyName (which should be distinct from other keys). When the request is successful, a random 32-byte alphanumeric key will be generated, and the response will include the keyName and the raw API key (shown only once). In the registry, a new subkey will be created with the provided keyName and the hash value will be stored.
- DELETE: This operation can be performed at the /api/apikeys/{keyName} endpoint, and it will delete the corresponding key if it exists.
When a user presents an API key for authorization, we check if its hash matches the stored key in the registry under the provided keyName. If it doesn't match, we respond with 401 Unauthorized.
API key holders do not know the admin's password and, therefore, do not have the same level of access as the web admin. They can authenticate with their API key and perform all operations except manipulating other API keys and accessing the /api/apikeys endpoint. Specifically, they are not allowed to create, delete, or list API keys, as these operations are allowed only to the web admin at the /api/apikeys endpoint.
API key users must present the raw key value in the header, prefixed by the keyName value. We then calculate its hash and compare it to the stored keys in the registry. The keyName is a subkey (subfolder) in the registry that contains the API key setting.
Example cURL Requests:
curl -X POST http://127.0.0.1:8123/api/server/start -H "x-coressh-api-key: test:UyP0R6hLA22pVo-Q5-oqatC89JB98h8g" -d ""
curl -X POST http://127.0.0.1:8123/api/settings -H "x-coressh-api-key: test:UyP0R6hLA22pVo-Q5-oqatC89JB98h8g" -H "Content-Type: application/json" -d "{\"TraceLevel\": 4}"
curl -X GET http://127.0.0.1:8123/api/settings -H "x-coressh-api-key: test:UyP0R6hLA22pVo-Q5-oqatC89JB98h8g"
curl -X DELETE http://127.0.0.1:8123/api/users/test -H "x-coressh-api-key: test:UyP0R6hLA22pVo-Q5-oqatC89JB98h8g"
Settings
Configuration settings are stored in the Windows registry in HKEY_LOCAL_MACHINE\SOFTWARE\CoreSSH\CoreSSHServer\24. This registry key holds settings that are available for CoreSSH Server globally. Additional registry keys are available to store API keys, SSH host keys, authorized keys or user-specific configuration.
The tree structure of these registry keys is described below:
- HKEY_LOCAL_MACHINE\SOFTWARE\CoreSSH\CoreSSHServer\24\:
The following values can be configured within the root HKEY_LOCAL_MACHINE\SOFTWARE\CoreSSH\CoreSSHServer\24 registry key:
| Name | Type | Description | ||||||||||||||||||||||||||||||||||
| AllowedClients | String | This setting defines a comma-separated list of host names or IPv4 addresses that are permitted to access the SSH Server. When a client attempts to connect, the client's address is checked against the list defined here. If there is no match, the connection request is immediately rejected. The default value is * and all connections are accepted. | ||||||||||||||||||||||||||||||||||
| AllowedAdminClients | String | This setting defines a comma-separated list of host names or IPv4 addresses that are permitted to access the HTTP Server. When a client attempts to connect, the client's address is checked against the list defined here. If there is no match, the connection request is immediately rejected. The default value is * and all connections are accepted. | ||||||||||||||||||||||||||||||||||
| AuthMaxAttempts | DWORD | Specifies the maximum number of authentication retries per connection allowed from a client with invalid login credentials. By default, this value is set to 3. | ||||||||||||||||||||||||||||||||||
| AutoBlockDuration | DWORD | Specifies how long a client is blocked for once they have reached the AutoBlockMaxAuthAttempts. The default value is 300 seconds. Setting AutoBlockDuration to 0 will disable automatic blocking. | ||||||||||||||||||||||||||||||||||
| AutoBlockMaxAuthAttempts | DWORD | Specifies the maximum number of connection retries allowed from a client with invalid login credentials. Once this number is reached, the client's IP address is added to a list of blocked clients for a specified duration. If this value is set, AutoBlockDuration must be set to a value greater than zero. The default value is 3. | ||||||||||||||||||||||||||||||||||
| BlockedClients | String | Defines a list of clients that are not allowed to connect to the SSH Server. This is a comma-separated list of IP addresses that will not be allowed to connect. Note that this list will not survive a server restart. | ||||||||||||||||||||||||||||||||||
| BlockedAdminClients | String | Defines a list of clients that are not allowed to connect to the HTTP Server. This is a comma-separated list of IP addresses that will not be allowed to connect. Note that this list will not survive a server restart. | ||||||||||||||||||||||||||||||||||
| DataEncryptionPassword | String | The DPAPI encrypted data encryption password, base64 encoded. | ||||||||||||||||||||||||||||||||||
| DataEncryptionSalt | String | The hex encoded 16 byte data encryption salt.
Warning: This value is created automatically and should not be modified or deleted from the registry. | ||||||||||||||||||||||||||||||||||
| DeleteLogDays | DWORD | The number of days after which old log files will be deleted. This is only applicable when RotateLogDays is set to a positive value. | ||||||||||||||||||||||||||||||||||
| EnableCompression | DWORD | Can be used to enable use of the zlib compression algorithm on SSH connections.
| ||||||||||||||||||||||||||||||||||
| EnableImpersonation | DWORD | Can be used to disable impersonation of the username used in the connection.
| ||||||||||||||||||||||||||||||||||
| EnablePowershell | DWORD | Can be used to enable Powershell support.
| ||||||||||||||||||||||||||||||||||
| EnableSessionManagement | DWORD | Can be used to enable sessions management.
| ||||||||||||||||||||||||||||||||||
| EnableSCP | DWORD | Can be used to enable SCP support.
| ||||||||||||||||||||||||||||||||||
| EnableSexec | DWORD | Can be used to disable SExec connections
| ||||||||||||||||||||||||||||||||||
| EnableSFTP | DWORD | Can be used to enable SFTP support.
| ||||||||||||||||||||||||||||||||||
| EnableShell | DWORD | Can be used to disable Shell connections.
| ||||||||||||||||||||||||||||||||||
| EnableSSHReverseTunnel | DWORD | Can be used to enable SSH Reverse Tunnel support.
| ||||||||||||||||||||||||||||||||||
| EnableSSHServerOnStartup | DWORD | Can be used to control whether the SSH listener will start automatically on machine boot.
| ||||||||||||||||||||||||||||||||||
| EnableSSHTunnel | DWORD | Can be used to enable SSH Tunnel support.
| ||||||||||||||||||||||||||||||||||
| FirewallType | DWORD | The type of firewall for the SSH Tunnel to connect through. Applicable values include the following:
| ||||||||||||||||||||||||||||||||||
| FirewallHost | String | The name of IP address of the firewall that the SSH Tunnel will connect through. | ||||||||||||||||||||||||||||||||||
| FirewallPort | DWORD | The TCP port for the FirewallHost. | ||||||||||||||||||||||||||||||||||
| FirewallUser | String | A user name if authentication is to be used when connecting through a firewall. | ||||||||||||||||||||||||||||||||||
| FirewallPassword | String | Password to be used if authentication is to be used when connecting through a firewall. | ||||||||||||||||||||||||||||||||||
| IdleSessionTimeout | DWORD | The number of minutes after which an idle connection should be terminated. By default, idle sessions will be disconnected after 20 minutes. | ||||||||||||||||||||||||||||||||||
| KerberosSPN | String | The Service Principal Name for the Kerberos Domain Controller. If the Service Principal Name cannot be automatically determined, it should be set here. This will usually be in the form "host/fqdn.of.sshhost[@REALM]" where REALM is the fully qualified (DNS) name of the Kerberos realm (or Windows Active Directory domain name). | ||||||||||||||||||||||||||||||||||
| LocalHost | String | The local IP address of the interface to which the server will bind. By default the server will listen on the default interface for the system. | ||||||||||||||||||||||||||||||||||
| LogEnabled | DWORD | Enables or disables logging to a file.
| ||||||||||||||||||||||||||||||||||
| LogLevel | DWORD | Controls the trace level of the logging from the application. Possible values are:
NOTE: The former registry setting TraceLevel can also be used for the same purpose. | ||||||||||||||||||||||||||||||||||
| LogSSHPackets | DWORD | Specifies whether or not raw SSH packets are included in the log.
| ||||||||||||||||||||||||||||||||||
| LogToFile | String | The full path to the log file. | ||||||||||||||||||||||||||||||||||
| MatchSSHPublicKeyToUsername | DWORD | Windows users only. Controls whether public keys in the file specified by SSHPublicKeyFileName setting are tied to a specific user name. Possible values are:
This setting can be used to validate that the correct public key was used to grant access to a particular user. If this setting is enabled the server will check the comment of the public key to verify it matches the username provided during authentication. This check is not case sensitive. To specify a username to be associated with a specific key, include the username in place of the comments in the public key. For instance: Unmodified public key: ssh-rsa AAAAB3NzaC1yc2EA...rPFBe7Pnc= rsa-key-20110822 Public key modified to be associated with a specific username: ssh-rsa AAAAB3NzaC1yc2EA...rPFBe7Pnc= DOMAIN\Username | ||||||||||||||||||||||||||||||||||
| MaxConnections | DWORD | Specifies the maximum number of connections that are allowed. By default the number of allowed connections is determined by the license that is installed. This setting may be specified to further restrict the number of connections. The server will restrict the number of connections to whichever is the lesser value between this setting and the number of allowed connections for the license. | ||||||||||||||||||||||||||||||||||
| MaxNumRowsInLog | DWORD | Controls how many lines will be shown in the Status window in the Service tab of the CoreSSH Server User Interface. If this value is exceeded, the oldest lines will be removed as new lines are added. The default value is 1000. | ||||||||||||||||||||||||||||||||||
| PasswordAuthEnabled | DWORD | May be set to disable password authentication.
| ||||||||||||||||||||||||||||||||||
| PreserveFileTime | DWORD | Determines if filetime preservation is supported. If a client requests filetime preservation (typically
by setting a "-p" parameter) this setting controls whether or not it is respected.
| ||||||||||||||||||||||||||||||||||
| PromptForRegPermissions | DWORD | When the server is running under an account that does not have write permissions to the registry location
where these settings are stored the user will be prompted to change the permissions. If this value is set to
0 the user will not be prompted again. Possible values are:
| ||||||||||||||||||||||||||||||||||
| RotateLogDays | DWORD | The number of days after which the log file will be rotated. Old log files will be renamed to the format "logname-yyyy-MM-dd". When set to a positive value DeleteLogDays is applicable. | ||||||||||||||||||||||||||||||||||
| RunProfiles | DWORD | Controls whether the server will run profile scripts. Possible values are:
| ||||||||||||||||||||||||||||||||||
| ResolveOwnerAndGroup | DWORD | Specify whether "Owner" and "Group" should be resolved during file listing or not. Having ResolveOwnerAndGroup turned on may result in slower file listing. Possible values are:
| ||||||||||||||||||||||||||||||||||
| ServerSSHVersionString | String | This setting specifies the version string value that is sent to all connecting clients. This may be set to specify server specific information. When setting a custom value, it must contain "SSH-2.0-" as this is a standard format that specifies the supported SSH version. The default value is SSH-2.0-CoreSSH Server 2024 - www.coressh.com. | ||||||||||||||||||||||||||||||||||
| SFTPHomeDirMap | String | Windows users only. A map defining user-specific SFTP home directories. This setting allows for a user to be assigned a specific default directory. The value should be a semicolon-separated list of username and home directory pairs in the format:
DOMAIN\user1=C:\user1;DOMAIN\user2=C:\user2
The user value must include the domain or machine name as appropriate (DOMAIN\user1 or MACHINE\user1).
If the directory specified does not exist the user will be placed into the default SFTPRootDir.
NOTE: If mappings are present in this setting and a user without a mapping tries to authenticate to the server, access will be denied. | ||||||||||||||||||||||||||||||||||
| SFTPRootDir | String | The absolute path of the root directory for SFTP users. By default the "windir" environment variable
will be used to determine the root directory (typically "C:\").
The special value "$user" may be included in the path which will be resolved to the username of the authenticated user (without Domain or Machine information). When "$user" is included in the path if the directory does not exist it will be automatically created. | ||||||||||||||||||||||||||||||||||
| ShowHiddenFiles | DWORD | Whether hidden files and folders are displayed during directory listings.
| ||||||||||||||||||||||||||||||||||
| SSHEncryptionAlgorithms | String | Specifies a name-list of the allowed SSH encryption algorithms. This list should be ordered based on preference and comma-delimited, with the first algorithm in the list being the most preferred. To disable an encryption algorithm, remove it from this list. Note: The algorithm which is actually selected during key exchange is the first algorithm to appear in the client's list that the server supports.
Valid values are:
aes256-ctr, aes192-ctr, aes128-ctr, 3des-ctr, aes256-gcm@openssh.com, aes128-gcm@openssh.com, chacha20-poly1305@openssh.com | ||||||||||||||||||||||||||||||||||
| SSHKeyExchangeAlgorithms | String | Specifies the Key Exchange algorithms presented during the SSH handshake. Algorithms not on this list will be disabled on the server. The list should be ordered based on preference and comma-delimited, with the first algorithm in the list being the most preferred.
Valid values are:
curve25519-sha256,curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 | ||||||||||||||||||||||||||||||||||
| SSHKeyRenegotiationThreshold | DWORD | This property allows the threshold to be specified, in the number of bytes, for the SSH Key Renegotiation. The default value for this property is set to 1073741824(1 GB) .
For example, to set the threshold to 500MB use the value 524288000. | ||||||||||||||||||||||||||||||||||
| SSHMacAlgorithms | String | Specifies the SSH MAC algorithms presented during the SSH handshake. Algorithms not on this list will be disabled on the server. The list should be ordered based on preference and comma-delimited, with the first algorithm in the list being the most preferred.
Valid values are:
| ||||||||||||||||||||||||||||||||||
| SSHPort | DWORD | The TCP port the server will listen in for connections. The default value is 22. | ||||||||||||||||||||||||||||||||||
| SSHPublicKeyEnabled | DWORD | Windows users only. Controls if file based public key authentication is enabled or not. When enabled, the server will grant access to users based on the public keys in the file specified by the SSHPublicKeyFileName setting.
| ||||||||||||||||||||||||||||||||||
| SSHPublicKeyFileName | String | Windows users only. Specifies the location on disk of the file containing authorized public keys. The server will grant access to users that authenticate with a private key associated with one of the public keys in this file.
The authorized keys file should contain a list of public keys in SSH public key format separated by newlines. Empty lines and lines starting with a # are ignored as comments. Additionally, you can control the IP addresses from which the key may be used by using the "from" keyword in the authorized keys file. Example:
Only accept connections using the specified public key from 192.168.1.12:
Only accept connections using the specified public key for the IP Address range 192.168.1.30 - 192.168.1.39:
Only accept connections using the specified public key for the IP Address range 192.168.1.100 - 192.168.1.199:
Only accept connections using the specified public key for the IP Address range 192.168.0.12 - 192.168.255.12 (must end in .12):
Only accept connections using the specified public key for the IP Address range 192.168.1.0 - 192.168.1.255 EXCEPT 192.168.1.12:
As demonstrated above, the special characters "?", "!", and "*" may be used to specify an IP address pattern that is to be matched. The value data in this registry setting may contain the %USERNAME% macro, which the server will substitute with the name of the user when they attempt to authenticate. This allows you to load an authorized keys file stored separately for each user. Only IPv4 addresses are currently supported. Hostname matching and IPv6 address matching are currently not supported. | ||||||||||||||||||||||||||||||||||
| SSHUseStrictKeyExchange | DWORD | This setting controls whether strict key exchange (strict kex) is enabled to mitigate the Terrapin attack. When enabled, the application will indicate support for strict key exchange by automatically including the pseudo-algorithm kex-strict-c-v00@openssh.com for client applications and kex-strict-s-v00@openssh.com for server applications in the list of supported key exchange algorithms.
Since both client and server must implement strict key exchange to effectively mitigate the Terrapin attack, the application provides options to further control the behavior in different scenarios. The default value is 1. Possible values for this setting are:
| ||||||||||||||||||||||||||||||||||
| SvcLogFile | String | If present, the trace information generated by the server will be written to the specified file. | ||||||||||||||||||||||||||||||||||
| UseFIPSCompliantAPI | DWORD | Determines if only FIPS compliant algorithms and API calls are made during SSH or SSL sessions. This is false by default. Possible values:
| ||||||||||||||||||||||||||||||||||
| UseIPv6 | DWORD | Controls whether IPv4 or IPv6 is used when listening. Connecting clients will need to connect using the appropriate
IP version. Possible values are:
| ||||||||||||||||||||||||||||||||||
| UserAuthBanner | String | Sets the User Authentication Banner, which is displayed to the client before they provide authentication, for example before a password prompt. This can also be set in the interface using the "Login Banner" field. The default value is CoreSSH Server (www.coressh.com). | ||||||||||||||||||||||||||||||||||
| WireEncoding | String | Controls the encoding used by the server on the wire for text sent and received by the server. By default, the server will use ISO-8859-1 (Latin-1) encoding. |
API Keys
The API keys are stored under the registry path HKEY_LOCAL_MACHINE\SOFTWARE\CoreSSH\CoreSSHServer\24\APIKeys\{keyName}. Each created API key has its own subkey, identified by the key name provided by the web admin upon creation.
Example registry structure:
- HKEY_LOCAL_MACHINE\SOFTWARE\CoreSSH\CoreSSHServer\24\APIKeys\
- testKey
- backupKey
- externalKey
The following key setting is available for API keys in CoreSSH Server. This setting controls the configuration and management of API keys, and it is also used during the authorization of the provided key.
| Name | Type | Description |
| APIKey | String | The hashed value of the API key, generated from the raw API key input. The hash is derived using PBKDF2 (Password-Based Key Derivation Function 2) with a random 24-byte salt to ensure security. |
Authorized Keys
CoreSSH Server may be configured to authorize users against known public keys. When a client performs public key authentication, it presents a signature created with the private key. The server will try to verify the signature is valid using each of the known public keys until it finds a match.
To add an approved public key, you may either specify it directly in the New User... form or add it to the registry. Possession of a private key which corresponds to an allowed public key serves as authentication.
Known public keys can be added to the Windows Registry at the following location. If the key does not exist go ahead and create it.
HKEY_LOCAL_MACHINE\SOFTWARE\CoreSSH\CoreSSHServer\24\AuthorizedKeys
Create a new String value and set the value data to the public key in SSH public key format as specified by RFC 4253 (also known as OpenSSH public key format). Briefly, an OpenSSH public key consists of three parts all on a single line:
- The key type
- A chunk of PEM-encoded data
- A comment
Example:
ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQ...w== rsa-key-20191008
The name of the String value is not used, but it is recommended to set this to the name of the user that the public key corresponds to for organizational purposes.
Host Keys
CoreSSH Server supports multiple host keys, which are stored under the registry path HKEY_LOCAL_MACHINE\SOFTWARE\CoreSSH\CoreSSHServer\24\HostKeys\{algorithm}. Within this registry path, subkeys for each cryptographic algorithm (RSA, ECDSA, Ed25519) are stored.
Example registry structure:
- HKEY_LOCAL_MACHINE\SOFTWARE\CoreSSH\CoreSSHServer\24\HostKeys\
- ECDSA
- Ed25519
- RSA
The following key settings are available to host keys in CoreSSH Server. These settings control the configuration and management of host keys for each supported algorithm:
| Name | Type | Description |
| Enabled | DWORD | Specifies whether the host key is enabled.
|
| SSHCertStore | String | If SSHCertStoreType is either 0 or 1, the SSHCertStore value defines the specific store where the certificate can be found. Example values: My, Root, Trust, CA, TrustedPublisher, Disallowed, AuthRoot, TrustedPeople.
When SSHCertStoreType is set to a file type (6 - PEMKeyFile), this property must be set to a fully qualified path to the file. When SSHCertStoreType is set to a blob type (7 - PEMKeyBlob), the SSHCertStore value must be set to the Base64 encoded representation of the binary contents of a PEM key file. |
| SSHCertStorePassword | String | The password for the specified certificate store. The password is encrypted using DPAPI local machine scope and Base64 encoded. If you are importing from an existing key or certificate file, you can set this value to the raw password to correctly load the key. |
| SSHCertStoreType | DWORD | Indicates where to find the SSH certificate. Can be one of the following values:
|
| SSHCertSubject | String | Subject of the SSH certificate used by the server. Example: CN=NEWTON.
NOTE: Using the special value * picks a random certificate in the certificate store. |
Users
The following values can be configured independently for each user, at HKEY_LOCAL_MACHINE\SOFTWARE\CoreSSH\CoreSSHServer\24\Users:
| Name | Type | Description |
| AuthenticationType | DWORD | Specifies the type of authentication required to connect to the server.
|
| DisplayName | String | Contains a readable name for the client shown on the Users tab. |
| Enabled | DWORD | Whether the server will authorize the user or not. When enabled, the server will authorize the user.
|
| EnableGSSAPI | DWORD | Windows users only. Whether the server will allow the GSSAPI authentication mode for the user.
|
| EnablePublicKey | DWORD | Windows users only. Whether the server will allow Windows store based public key authentication for the user. When enabled, the StoreName and StoreType configuration settings will contain the location the server will look for client certificates.
|
| EnablePassword | DWORD | Windows users only. Whether the server will allow password authentication via Windows Authentication mechanisms.
|
| LogonType | DWORD | Windows users only. Controls the type of logon performed by the application when attempting to authenticate users. Network is more secure, but access to remote network resources is prohibited. Interactive logon allows access to remote network resources.
|
| Mechanisms | DWORD | Windows users only. Specifies the authentication mechansism to be used.
|
| Password | String | Virtual users only.Contains the password hash for the client. The password hash is computed using PBKDF2 and is base64-encoded and stored using the following format. E.g. PBKDF2:L4GHIfCW... |
| ReadOnly | DWORD | Specifies that this user may only read files and directories. Any attempt to create, update or delete files or folders will be denied.
|
| RootDirectory | String | Specifies the default directory of the client after starting a channel. In addition, it tells the server to overwrite the global root directory for this user. As a result, the client is jailed to this location because client perceives its working directory as the root of the entire server.
Note: If UseDefaultDirectory is enabled, the value stored in this setting is ignored. |
| StoreName | String | Windows users only. Tells the server to look for client certificates in the specified store. Predefined system certificate store names include My, Root, Trust, CA, and more. |
| StoreType | DWORD | Windows users only. Tells the server to look for client certificates in the Machine or User stores.
|
| UseDefaultDirectory | DWORD | Controls the default directory behavior for the client. When enabled, the server will use the default location for this user.
|
| UserName | String | Contains the client name. |