openssh bugs - Apr 2020 - [Bug 3155] New: openssh support hostkey encrypt

https://bugzilla.mindrot.org/show_bug.cgi?id=3155

            Bug ID: 3155
           Summary: openssh support hostkey encrypt
           Product: Portable OpenSSH
           Version: 8.2p1
          Hardware: ARM64
                OS: Linux
            Status: NEW
          Severity: security
          Priority: P5
         Component: ssh-keygen
          Assignee: unassigned-bugs at mindrot.org
          Reporter: kircherlike at outlook.com

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?

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3155

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |djm at mindrot.org

--- Comment #1 from Damien Miller <djm at mindrot.org> ---
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.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3155

--- Comment #2 from kircher <kircherlike at outlook.com> ---
(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.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3155

Darren Tucker <dtucker at dtucker.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dtucker at dtucker.net

--- Comment #3 from Darren Tucker <dtucker at dtucker.net> ---
(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).

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3155

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |WONTFIX
             Status|NEW                         |RESOLVED

--- Comment #4 from Damien Miller <djm at mindrot.org> ---
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.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3155

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #5 from Damien Miller <djm at mindrot.org> ---
close bugs that were resolved in OpenSSH 8.5 release cycle

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.