Path: csiph.com!weretis.net!feeder9.news.weretis.net!panix!.POSTED.spitfire.i.gajendra.net!not-for-mail
From: cross@spitfire.i.gajendra.net (Dan Cross)
Newsgroups: comp.unix.programmer
Subject: Re: MacOS TCP port permissions
Date: Fri, 17 Apr 2026 15:20:09 -0000 (UTC)
Organization: PANIX Public Access Internet and UNIX, NYC
Message-ID: <10rtj39$ht9$1@reader1.panix.com>
References: <10rq7hc$1b1bt$1@dont-email.me> <10rt267$1eh57$1@dont-email.me> <10rtel4$jrs$1@reader1.panix.com> <10rtgq7$2h4os$1@dont-email.me>
Injection-Date: Fri, 17 Apr 2026 15:20:09 -0000 (UTC)
Injection-Info: reader1.panix.com; posting-host="spitfire.i.gajendra.net:166.84.136.80"; logging-data="18345"; mail-complaints-to="abuse@panix.com"
X-Newsreader: trn 4.0-test77 (Sep 1, 2010)
Originator: cross@spitfire.i.gajendra.net (Dan Cross)
Xref: csiph.com comp.unix.programmer:17081

In article <10rtgq7$2h4os$1@dont-email.me>,  <boltar@caprica.universe> wrote:
>On Fri, 17 Apr 2026 14:04:20 -0000 (UTC)
>cross@spitfire.i.gajendra.net (Dan Cross) gabbled:
>>In article <10rt267$1eh57$1@dont-email.me>,  <boltar@caprica.universe> wrote:
>>>On Thu, 16 Apr 2026 20:29:37 +0100
>>>A hacked version of ssh could save or forward everything it receives.
>>
>>Not if it can't read the host key because it doesn't have
>>permissions to open the file the key is stored in, and so it
>
>Why wouldn't it have permissions if a user has set up the whole thing?

...because the file containing the host private key is owned by
root, and not the user?  And the client has a cached copy of the
host public key locally whent hey connect?

Unless the attacker is already running as root, in which case,
they could just bind to a low port anyway.

>>>Crypto is only useful outside of the process, inside its irrelevant.
>>
>>"Crypto" in this case is about authentication, not just privacy.
>>Part of the SSH protocol is mutually authenticating both the
>>client _and_ the server using a cryptographically secured key
>>exchange.
>
>Irrelevant. A hacked ssh server could do anything the hacker wants with the
>decrypted data.

What decrypted data?  Authentication of the incoming connection
happens when the connection is established, before a session is
initiated, and thus before any data is exchanged, let alone
"decrypted", and before anything is "run" on the server.

If authentication fails, "bash" (which is not the only shell
people use) is never invoked.

>You do realise the data has to be decrypted by ssh in order to 
>do anything with it, right?

It sounds like you might not have a good handle on how the
session is established, and in particular, how it is
authenticated.

>Or did you think it passed the encrypted stream
>direct to bash?

Passing a stream of encrypted data to bash is likely to produce
nonsense.

	- Dan C