Quickstart Guide

CoreSSH Server offers an intuitive setup process, 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 immediately, no initial configuration is required. Default settings are already in place. 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 Admin Console, the system tray controls, or the Windows Service Manager itself. To connect via SFTP, open an SSH client and enter the server's IP address and port number (default: 22). Provide valid credentials and you are ready to transfer files securely.

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 via SSH, CoreSSH delegates the authentication to the Windows system or domain controller, which verifies the credentials.

Supported Authentication Methods:

• Password (Network Logon or Interactive Logon)
• Public Key (File-Based or Certificate Store-Based

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.

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 the Access Admin Console link in the Admin Console tab (desktop application) or use the system tray menu Open button. This directs the user to the login page, where the admin password is required to sign in.

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:

Command Line

Use the /resetpassword flag followed by the new password to reset the Admin Console password. Please refer to the Command Line section for more details.

System Tray Menu

The system tray menu includes a Reset Password... option. Selecting this option will prompt the user to enter and confirm a new password. Clicking OK updates the password.

Admin Console Configuration

The Admin Console can be configured using either the desktop application or the system tray menu. Both methods allow administrators to manage Admin Console settings, including enabling/disabling the feature, modifying the server interface, changing the listening port, and configuring TLS options for secure connections.

Desktop Application

The Admin Console tab in the desktop application provides full access to Admin Console settings.

System Tray Menu

The HTTP Server... option in the system tray menu offers quick access to configure the same settings without opening the Desktop application.

Admin Console Options

• 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

1. Navigate to the Settings tab.
2. Enable Write Log to a File and specify a local file.
3. Increase the Log Mode.
4. Click the Save Changes button.
5. Reproduce the issue.
6. 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

All settings are stored in the registry in the HKEY_LOCAL_MACHINE hive. Please see Settings for more information. Anyone who can write to the registry or is a member of the Administrators group has full control over the server.

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 different types of Users as discussed on the User Accounts page. When an NT User Account is defined in the CoreSSH Server, we leverage the Windows operating system for SSH logins. Our logic will retrieve a security context for the user in order to verify the user's identity and to perform file access from that security context.

By contrast, with virtual user accounts our server will perform the authentication. File access will be performed without impersonation. Filesystem operations are performed using the security context of the process user.

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.

For virtual user accounts, the password is hashed in a manner resistent to brute force attacks and stored in the registry in the Users key. A virtual user identity is considered authorized when the hash is verified. We compute the hash of the password when logon is performed to the password hash stored in the registry when the user was created.

Resource Access

When an SFTP channel is requested, we receive SFTP packets and then process operations such as read, write, rename, delete, etc. The packet processing logic simply will use the Windows Identity (if the user is an NT User Account) for resource access or the current process identity (if the user is a virtual user account). In both cases, we will enable Windows permissions checking in the current thread.

In Shell sessions, a separate worker process will be created to isolate the operation from the rest of the server. The worker process is created using the token returned from the call to the LogonUser API, so the Windows User's privileges will apply to the whole process. When CoreSSH Server receives a command in a shell session, it sends the command to the worker process via its standard input stream. Shell support is disabled for virtual user accounts.

Application Identity

CoreSSH Server runs as Local System, but can run as a different account identity if you specify in the Log on As setting in the Service properties page. The SSH session will run as Local System until the user is authenticated. Once the user is authenticated, SFTP session will switch to the security context of the users who are actually logging in, or in the case of virtual user accounts, as the process identity. The Shell session will be launched as a separate process entirely in the user's security context.

Passwords and Hashing

When you connect to the server using NT User Accounts we do not store account passwords or password material. For virtual user accounts, when the account is initially created we will compute a hash of the password using the password derivation function PBKDF2 and store the base64-encoded value in the registry. We use the HMACSHA512 hash algorithm with 10000 iterations. This password hash will be stored in the Password registry key in Users key. Note that simple passwords can still be guessed. Even the strongest password hashing does not help if the password is easy to guess or reused from other systems.

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.

Automatic Setup

CoreSSH Server supports a streamlined installation through automated or programmatic methods. You can use the options provided in the installer to allow for scripted installations. Below are the key installation options and commands for configuring your setup.

Installation and License Activation

To install CoreSSH Server silently, use the /S flag for a non-interactive installation. You will also need to provide your product key using the /SNO option. If a previous version of the SFTP Server or PowerShell Server is detected in the system registry, their settings will be automatically imported. setup.exe /S /SNO=XISUB-RA1SU-XXXXX-XXXXX-XXXXX

This command installs CoreSSH Server without any user interaction and activates it with the provided product key. All previous configuration settings will be transferred from the registry, if applicable.

NOTE: Silent installation should only be used if you are confident in the settings and have a valid product key for activation.

Specifying the Web Administration Password

To set the Web Administration password during installation, use the /adminpassword option. Replace password with your desired password. setup.exe /S /SNO=XISUB-RA1SU-XXXXX-XXXXX-XXXXX /adminpassword:password

This command sets the password for accessing the Admin Console.

Alternate Installation Directory

If you need to install CoreSSH Server to a directory other than the default, you can specify a custom installation path using the /PATH option. setup.exe /S /SNO=XISUB-RA1SU-XXXXX-XXXXX-XXXXX /PATH=C:\Your\Path

This command installs CoreSSH Server in the directory you specify. Replace C:\Your\Path with the desired installation directory.

NOTE: For further customization or troubleshooting, refer to the detailed documentation. You can also contact support for assistance with more advanced configurations or issues.

Configuration File

There are two main ways to configure the server: by interacting with the user interface or by grouping settings into a file.

Windows Registry

Configuring CoreSSH Server was designed to be simple. All settings are stored and loaded from the registry and you have control over the current configuration by updating settings one at a time or grouping multiple settings into a file to be updated using the native Windows mechanisms such as Regedit.exe or REG.exe.

*.INI Configuration File

The filename extension *.ini is commonly used for configuration files in a simple key-value format. CoreSSH Server supports reading an INI file and writing the settings to the registry. This approach allows administrators to manage settings in a portable text-based format, which can be edited manually and imported programmatically.

Command Line

The CoreSSH server may be started,stopped and configured from the command line by specifying the command line parameters supported. For instance:

• 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 WinForm UI: CoreSSHServer.exe /exit

Additional command line parameters:

• 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

Each of these parameters performs a specific task related to the configuration, management, or operation of the CoreSSH Server.

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"

Backup

The CoreSSH Server offers convenient ways to migrate application settings from one system to another. Please note that this migration pertains exclusively to your client settings and does not involve transferring the contents of the virtual drive.

Exporting Settings

To export your settings, follow these steps:

1. Navigate to the Other tab within the application.
2. Click the Export link to initiate the settings export process.
3. Specify the location and filename where settings will be saved. By default, the settings will be stored in INI file format.

Importing Settings

To import settings from an existing file, follow these steps:

1. Navigate to the Other tab within the application.
2. click Import link to start the import process.
3. Specify the filename of the .ini file you want to load your settings from.

Importing Users from FileZilla

To import users from a FileZilla export file, follow these steps:

1. Navigate to the Users tab within the application.
2. Click the Import from FileZilla link to begin the import process.
3. The system will automatically detect the presence of the FileZilla Server.xml or users.xml configuration file if it exists on the system.
4. Confirm the import. The users will be automatically added to the server, and their settings will be transferred.

Note on Sensitive Information

Sensitive fields such as passwords will be decrypted as part of the export process and stored in plaintext in the .ini file.

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\:
  • API Keys
  • Authorized Keys
  • Host Keys
  • Users

The following values can be configured within the root HKEY_LOCAL_MACHINE\SOFTWARE\CoreSSH\CoreSSHServer\24 registry key:

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.

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:

Users

The following values can be configured independently for each user, at HKEY_LOCAL_MACHINE\SOFTWARE\CoreSSH\CoreSSHServer\24\Users: