openssh unix dev - Sep 2025 - How to specify chost (client hostname) used for hostbased authentication?

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. I?d expect it to be a
completely separate and isolatd connection outside of the client?s control.
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.

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

I?ll plunge into the RFCs over the weekend :)

Sorry and thanks for you explanation, very much appreciated

Jan
> On 5. 9. 2025, at 12:04, Brian Candler <b.candler at pobox.com>
wrote:
> 
> On 05/09/2025 10:45, Jan Schermer wrote:
>> I am not that familiar with HostbasedAuthentication, or rather how it
was/is actually used and what the background is.
> 
> There's a reasonable overview here:
> 
> https://hea-www.harvard.edu/~fine/Tech/ssh-host-based.html
> 
> Basically it's to get rssh-like functionality between a local cluster
of machines that trust each other.  A user logged in as "foo" on
machine A can ssh into account "foo" on machine B. But instead of user
foo having their own personal key pair, there's a key pair between the hosts
themselves.
> 
> Hence all users on machine A can login as the corresponding user on machine
B: convenient in some environments, but not very secure.  Generally to be
avoided unless you have a good reason to use it.  If you're on a dynamic IP
address you probably want to do normal user pubkey authentication, not host
authentication.
> 
>> To me, the whole thing with SSHKeySign looks like the server could
actually SSH back to the client(?s server), have the server sign/verify it (sort
of out-of-band) and then accept/reject the original authentication, not sure if
something like that is behind this design or not but that?s why my thoughts went
for verifying the hostname by forward DNS lookup?
> 
> Sorry, I don't understand that at all.
> 
> With host-based authentication, host A is connecting to host B. Host B has
a "known_hosts" entry for host A, which contains the public key
corresponding to host A's private key.  Once host A has proved its identify
(via ssh-keysign to prove it has the private key), host B accepts the
connection. It then trusts host A to assert which username is logging in
(whether that be "foo" or "bar" or "root")
> 
> I don't see why host B would also want to SSH back to host A as part of
A logging into B. In that case, host A would also have to allow ssh connections
from host B. Sounds like a chicken-and-egg situation.
> 
> The DNS is not really part of the authentication, except in as much as host
B needs to know who is trying to authenticate, so that it can select the correct
public key from its known_hosts file. This can be done either by:
> 
> - host B doing a reverse DNS lookup on the source IP address of the TCP
connection
> 
> - host A sending its own identity "hostA" as the chost field in
the authentication exchange
> 
> But in either case, it's only selecting a *candidate* for
authentication. If hostA cannot actually *prove* that it is hostA, which it does
by signing a challenge using hostA's private key, then authentication will
fail.  So DNS is not really part of the security, any more that when I type
"ssh brian at 1.2.3.4" I am *claiming* that I am user
"brian" but won't get any further without a successful
authentication.
> 
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

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.

Hi,

On Fri, Sep 05, 2025 at 12:44:09PM +0200, 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. I???d expect it to be
a completely separate and isolatd connection outside of the client???s control.
The client is supposed to present credentials (= a nonce signed with
a host key) that it has no access to.  So it asks a local helper binary
to produce that signature.  If that binary produces a signature that
matches, the client has proof that it's "running on the host that
it claims to be".

Earlier versions tied this to "the rsh client is suid root and can connect
from a privileged port" but that's way less secure than an isolated
binary
that can be well audited and does one thing only.
> 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.
Identd is no more or less trustworthy than "any other root-owned
binary",
but there's much more room for network interference.

gert
-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
                             Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany                             gert at
greenie.muc.de