We noticed that the sshd.c file contained such a code snippet: ... for (i = 0; i < options.num_host_key_files; i++) { int ll = options.host_key_file_userprovided[i] ? SYSLOG_LEVEL_ERROR : SYSLOG_LEVEL_DEBUG1; if (options.host_key_files[i] == NULL) continue; if ((r = sshkey_load_private(options.host_key_files[i], "", &key, NULL)) != 0 && r != SSH_ERR_SYSTEM_ERROR) do_log2(ll, "Unable to load host key \"%s\": %s", options.host_key_files[i], ssh_err(r)); ... By default, an empty string is used as the password for reading the hostkey. When the hostkey is stolen, the third party can disguise as the server to obtain some information about the SSH client. We want to protect it by encrypting the hostkey. Can we use a non-empty string to encrypt the hostkey?
First, you might be interested in ssh'd support for ssh-agent. This allows you to do what you want without modifying sshd. Basically you need to load your hostkeys in to a ssh-agent and tell sshd to use it via the HostKeyAgent directive. In answer to your question: in theory yes, but there are two problems. 1) where would the passphrase come from? It would need to be supplied each time sshd is started (e.g. at reboot) 2) There is some subtlety around sshd's self-reexecution behaviour. You'd need to ensure that the passphrase is available at re-exec time too.
(In reply to Damien Miller from comment #1) > First, you might be interested in ssh'd support for ssh-agent. This > allows you to do what you want without modifying sshd. Basically you > need to load your hostkeys in to a ssh-agent and tell sshd to use it > via the HostKeyAgent directive. > > In answer to your question: in theory yes, but there are two > problems. > > 1) where would the passphrase come from? It would need to be > supplied each time sshd is started (e.g. at reboot) > > 2) There is some subtlety around sshd's self-reexecution behaviour. > You'd need to ensure that the passphrase is available at re-exec > time too. ssh-agent is a good command, but it binds the hostkey lifecycle to the ssh-agent process in consideration of its use to manage the hostkey. This means that if I don't want to keep a hostkey on the disk for a long time with an empty password, it will change once ssh-agent restarts. For the two questions you asked： 1)We can read the content of /dev/random (for example, 20 readable characters) as a passphrase when each hostkey is generated. This passphrase will be stored in our private database. Each time the client initiates an SSH login, the server reads the passphrase from the database to decrypt the hostkey with the sshkey_load_private function. This process does not need to be perceived by the client. For the client, it does not need to know whether the server's hostkey is encrypted. 2)Similarly, the method of reading the passphrase from the database can also be used when sshd is executed again.
(In reply to kircher from comment #2) [...] > 1)We can read the content of /dev/random (for example, 20 readable > characters) as a passphrase when each hostkey is generated. This > passphrase will be stored in our private database. The host key is only readable by root. Anywhere you could store the passphrase would also be readable by root, so you're not actually buying anything in terms of security. Plus if the database is on another host you'll be adding a bunch of extra points of failure. If you want to protect the host keys against root then you need to do it in hardware, eg by using a pkcs11 hardware token (which is done via ssh-agent).
Sorry, but I don't want to add support for promoting key passphrases to sshd. It is already possible to use password-protected private keys in sshd via ssh-agent as described, so I recommend that you try that.
close bugs that were resolved in OpenSSH 8.5 release cycle