openssh bugs - Jan 2016 - [Bug 2533] New: do not check if HostKeyAgent is available on ssdh startup

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

            Bug ID: 2533
           Summary: do not check if HostKeyAgent is available on ssdh
                    startup
           Product: Portable OpenSSH
           Version: 7.1p1
          Hardware: All
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: sshd
          Assignee: unassigned-bugs at mindrot.org
          Reporter: igor at mir2.org

Currently with the HostKeyAgent option sshd checks on startup if it can
connect to the agent socket,
https://github.com/openssh/openssh-portable/blob/ebacd377769ac07d1bf3c75169644336056b7060/sshd.c#L1773

This introduces an artificial dependency between the agent process and
sshd and require the agent running when sshd starts. Moreover, as this
check do not verify if the the agent has the keys for the server, the
usability as a health check of such query is rather low.

It would be nice to either remove this check completely or at least
provide an option to disable it. This way the agent socket will be
queried only when receiving a new client connection completely
decoupling sshd from the agent process.

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

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

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |WONTFIX
                 CC|                            |djm at mindrot.org
             Status|NEW                         |RESOLVED

--- Comment #1 from Damien Miller <djm at mindrot.org> ---
Sorry, we don't consider this an artificial dependency. sshd being able
to access its keys is a requirement. We'd consider patches to improve
the check, but not to remove it.

-- 
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=2533

Igor Bukanov <igor at mir2.org> changed:

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

--- Comment #2 from Igor Bukanov <igor at mir2.org> ---
(In reply to Damien Miller from comment #1)
> sshd being able to access its keys is a requirement.
Even checking that the key is really loaded into the agent does not
provide any guarantee that sshd can access the key later. They key can
be removed at any moment by the agent or the agent may disappear. Or
consider that the agent may be running on another machine with its
socket forwarded to sshd when the link to the agent may be interrupted.

Moreover, as the check introduces artificial dependency between sshd
and the agent, it makes it harder to run the agent in a separated
container on Linux for extra security. The present check requires to
ensure ordering between containers which is even in 2020 is not exactly
solved problem.

So given that the check does not ensure the key availability while it
makes securing the system more complex, I am asking to re-consider
WONTFIX.

-- 
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=2533

Damien Miller <djm at mindrot.org> changed:

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

--- Comment #3 from Damien Miller <djm at mindrot.org> ---
It's not an artificial dependency. sshd needs those keys or it won't
work. 

The check is useful, it tells the administrator that their
configuration is bad at a time when they have some chance of seeing the
error rather than later when users try to ssh in and it fails
inexplicably.

This being inexpedient for your use case doesn't make this test
invalid, rather it is demonstrating that your proposed environment has
bugs that need fixing.

-- 
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=2533

Damien Miller <djm at mindrot.org> changed:

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

--- Comment #4 from Damien Miller <djm at mindrot.org> ---
closing resolved bugs as of 8.6p1 release

-- 
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.