ssh-server-config

http://www.ssh.com/manuals/server-admin/62/ssh-server-config.html

hostkey

This element defines the location of the private host key and optionally the location of the public key and/or certificate. The elements inside the element must be given in the right order (private key before public).

Inside one hostkey element either the public key or the certificate can be given, not both.

Giving the public key in the configuration file is not mandatory. It will be derived from the private key if it is not found otherwise. However, specifying the public key will decrease the start-up time for the software, as deriving the public key is a fairly slow operation.

private

The private element gives the path to the private key file as a value of the file attribute.

The key file should be located on a local drive. Network or mapped drives should not be used, as the server program may not have proper access rights for them. The default is hostkey, in the /etc/ssh2 directory on Unix and in the "<INSTALLDIR>\Tectia Server" directory on Windows.

On Unix, the private key file should be readable and writable only by root. The private key directory should be writable only by root.

On Windows, the key file and directory should have full permissions for the Administrators group and the SYSTEM account and no other permissions.

public

This element gives the path to the public key file as a value of the file attribute.

The key file should be located on a local drive. Network or mapped drives should not be used, as the server program may not have proper access rights for them.

Alternatively, the public key can be specified as a base64-encoded ASCII element.

x509-certificate

This element gives the path to the X.509 user certificate file as a value of the file attribute.

Alternatively, the certificate can be specified as a base64-encoded ASCII element.

externalkey

This element defines an external host key. The type must be given as an attribute. The currently supported types are none, software, entrust, mscapi, pkcs11, and pkcs12. Entrust is supported on Windows, only. The init-info for the external key can also be given.

Sample hostkey elements are shown below:

<hostkey>      
  <private file="/etc/ssh2/hostkey_dsa" />
  <public file="/etc/ssh2/hostkey_dsa.pub" />
</hostkey>

<hostkey>      
  <private file="/etc/ssh2/hostcert_rsa" />
  <x509-certificate file="/etc/ssh2/hostcert_rsa.crt" />
</hostkey>

<hostkey>      
  <externalkey type="entrust" 
               init-info="profile-file(/etc/ssh2/hostcertprofile.epf)" />
</hostkey>

For PKCS#12, the <hostkey> settings are as follows:

<hostkey>      
  <externalkey type="software" 
               init-info="key_file(/etc/ssh2/server-cert.p12)
                          key_passphrase_file(/etc/ssh2/my-passphrase)" />
</hostkey>

In the PKCS#12 sample output, the hostkey setting reads the PKCS#12 file server-cert.p12 and if it needs a passphrase to open it, it will read the my-passphrase file and use the contents as the passphrase. The file can also contain additional certificates but they are ignored in Tectia Server.

In the init-info string, the following keywords are supported:

• directory(<directory_name>) - defines the directory to be polled for the keys. All files in the named directory are added to sshexternalkey. Note however, that this option lacks control over the actual server key and certificate.

• polling_interval_ms(<time_ms>) - defines the polling interval for the option above.

• key_files(<key_spec>) - defines that multiple comma-separated files are read. Loose grouping between files is expected so that public key, private key and certificate are assumed to be parts of the same key. Supported in Tectia Server.

• key_file(<file_name>) - defines that one key file is read. The same as key_files with one parameter.

• key_passphrase(<passphrase>) - if a private key or certificate container is password-protected, the command tries to open it with the supplied passphrase first. In case the passphrase is not valid, the authentication callback is called normally. In the server, that means a failure to open the file as the server does not have an interactive prompt.

• key_passphrase_file(<filename>) - defines that instead of giving the passphrase in the configuration file directly, it can be written to a separate file. This option is useful if server configuration file needs to be more widely readable. The private key and passphrase can still be with root access only.