On 05/09/2025 11:44, Jan Schermer wrote:
I’m sorry, I was mostly thinking out loud.
I understand (mostly) how it technically works, but it seems a bit weird to invoke a SUID binary over client’s connection backwards.
It's not backwards, it's forwards.
Host A connects to host B. Host A invokes the suid binary to sign the
message which proves that it is host A, and sends this message to host B
as part of the authentication.
The reason it has to be a suid binary, is because the authentication
message also includes the username. If host A's private key were
world-readable, then any user "foo" could sign a message allowing them
to login as user "bar" (or "root" or whatever). Plus, of course, the
private key could be stolen and abused elsewhere.
When I started working as a sysadmin everyone was already using pubkeys, so I never worked in an environment that used hostbased auth, rsh, I’ve never even seen NIS and stuff like that used, thatis just so far back that I didn’t encounter it.
Then you were lucky - and you should probably just forget that it exists :-)
It’s just that the whole concept looks more like “more trustworthy identd”, which would make more sense if the target (server) sshd daemon did a callback instead of how it actually works, whence my thoughts on it and I wonder if the original authors were thinking about it that way.
No, it's more secure than identd. You're not trusting the IP address of
host A. Host A can only log in if it has a private key proving that it
is host A, and the username of the caller is protected by the same
signature.
DNS is not really part of the security,
^ if that were completely true, than there wouldn’t be any need for HostbasedUsesNameFromPacketOnly option, though it in fact seem to do something slightly different than what its name implies, at least for me - once disabled, I can’ t login at all, so it’s not supplementing the client’s “chost” but rather not using it/trusting it at all.
If it's not working, that's a separate problem which "-vvvv" on the
client and/or server can probably help you with. Most likely the host
name the client is sending does not match the host name in the
known_hosts file on the server. (Or maybe you've found a bug in a
rarely-used code path)
I quoted the "recommended" section in the RFC earlier. The concern is,
just *suppose* the private key from host A were stolen: very bad things
could happen if the person holding that key could login from anywhere,
as any user. Binding the source to IP/DNS information makes it
*slightly* harder to abuse. Personally, I think by this stage you're
toast anyway.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
