Considering shipping ssh-keysign non-setuid

[Jochen Bern]

Am 15.05.26 um 20:17 schrieb Marc Haber:
> I think that all points are made

I don't, and would like to ask two more specific questions:

1. The purpose being that "the host" on the client side, using "the 
host's" secret data, confirms that the challenge was passed to it 
through a local login of user X, is it wise to have it done through an 
executable started by said user (and accessing the secrets by setuid 
root / setgid ssh_keys), rather than a daemon (a la identd) running 
entirely in the context of "the host"?

Especially seeing this comment:

>         /* XXX This really needs to read sshd_config for the paths */
>         key_fd[i++] = open(_PATH_HOST_ECDSA_KEY_FILE, O_RDONLY);
>         key_fd[i++] = open(_PATH_HOST_ED25519_KEY_FILE, O_RDONLY);
>         key_fd[i++] = open(_PATH_HOST_XMSS_KEY_FILE, O_RDONLY);
>         key_fd[i++] = open(_PATH_HOST_RSA_KEY_FILE, O_RDONLY);

which would certainly be resolved if said daemon were, or could reuse 
the initialization code of, sshd.

(... hmmm, does that mean that renaming the files with the host keypairs 
and updating sshd_config accordingly would be a working mitigation for 
the ssh-keysign part of CVE-2026-46333? And if vendors' usual startup 
mechanisms for sshd then promptly create new keypairs under the default 
filenames, we'd have a free honeypot ... ?)

Also, ease of letting the sysadmin enable or disable *one* central 
daemon if so desired.

2. For a more long-term perspective: Would it be feasible (for the 
security requirements of real-world deployments of this feature) to 
relax the condition "user X is logged in on host A *right now*, and 
connecting from that *exact* host" to something like "connecting user 
was recently (couple minutes?) logged in as user X on host A"?

Because if that's OK, the mechanism could be changed to host A handing 
local users short-lived *SSH certificates* certifying that fact, and 
it'd be mostly using the much more recent codebase for those in one fell 
swoop.

Kind regards,
-- 
Jochen Bern
Systemingenieur
Binect GmbH
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4336 bytes
Desc: Kryptografische S/MIME-Signatur
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20260518/0aa2f4b7/attachment-0001.p7s>