How to specify chost (client hostname) used for hostbased authentication?

[Brian Candler]

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.