Bug 2533

Summary: do not check if HostKeyAgent is available on ssdh startup
Product: Portable OpenSSH Reporter: Igor Bukanov <igor>
Component: sshdAssignee: Assigned to nobody <unassigned-bugs>
Status: CLOSED WONTFIX    
Severity: enhancement CC: djm
Priority: P5    
Version: 7.1p1   
Hardware: All   
OS: All   

Description Igor Bukanov 2016-01-28 18:03:39 AEDT 
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.
Comment 1 Damien Miller 2020-01-25 23:21:44 AEDT 
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.
Comment 2 Igor Bukanov 2020-01-28 02:08:40 AEDT 
(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.
Comment 3 Damien Miller 2020-01-28 13:32:54 AEDT 
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.
Comment 4 Damien Miller 2021-04-23 15:08:49 AEST 
closing resolved bugs as of 8.6p1 release