I've just discovered that the current version of MacOS I'm running (15.7.5) doesn't seem to enforce restricted TCP ports below 1024 and a process
without root permission seems to be able to open a listening socket on any port it pleases. I'm using a standard user account without AFAIK any special priviledges given to it.
Perhaps MacOS never enforced this, anyone know?
boltar wrote:
I've just discovered that the current version of MacOS I'm running (15.7.5) >> doesn't seem to enforce restricted TCP ports below 1024 and a process
without root permission seems to be able to open a listening socket on any >> port it pleases. I'm using a standard user account without AFAIK any special
priviledges given to it.
Perhaps MacOS never enforced this, anyone know?
Apparently it changed in MacOS Mojave to match how iOS behaves.
See https://developer.apple.com/forums/thread/674179
Geoff Clare <geoff@clare.See-My-Signature.invalid> gabbled:
boltar wrote:
I've just discovered that the current version of MacOS I'm running
(15.7.5) doesn't seem to enforce restricted TCP ports below 1024 and
a process without root permission seems to be able to open a
listening socket on any port it pleases. I'm using a standard user
account without AFAIK any special priviledges given to it.
Perhaps MacOS never enforced this, anyone know?
Apparently it changed in MacOS Mojave to match how iOS behaves.
See https://developer.apple.com/forums/thread/674179
Cheers for that. Whoever "DTS Engineer" is he clearly doesn't
understand the reasons the restriction was put in in the first place -
ie that the services on low ports are the real deal and not maybe some credential snatcher spun up by a user. eg, running a hacked version of
sshd on port 22.
Whoever "DTS Engineer" is he clearly doesn't understand the reasons
the restriction was put in in the first place - ie that the services
on low ports are the real deal and not maybe some credential
snatcher spun up by a user. eg, running a hacked version of sshd on
port 22.
On Thu, 16 Apr 2026 14:48:08 -0000 (UTC), boltar wrote:
Whoever "DTS Engineer" is he clearly doesn't understand the reasons
the restriction was put in in the first place - ie that the services
on low ports are the real deal and not maybe some credential
snatcher spun up by a user. eg, running a hacked version of sshd on
port 22.
You really expect a remote client to trust a connection to some random machine just because the destination port number is in some arbitrary rCLprivilegedrCY range?
On Thu, 16 Apr 2026 14:48:08 -0000 (UTC), boltar wrote:
Whoever "DTS Engineer" is he clearly doesn't understand the reasons
the restriction was put in in the first place - ie that the services
on low ports are the real deal and not maybe some credential
snatcher spun up by a user. eg, running a hacked version of sshd on
port 22.
You really expect a remote client to trust a connection to some random machine just because the destination port number is in some arbitrary rCLprivilegedrCY range?
You really expect a remote client to trust a connection to some random machine just because the destination port number is in some arbitrary rCLprivilegedrCY range?
Lawrence DrCOOliveiro , dans le message <10rrr1p$225jt$3@dont-email.me>,
a |-crit-a:
You really expect a remote client to trust a connection to some random
machine just because the destination port number is in some arbitrary
rCLprivilegedrCY range?
When rCLsome random machinerCY is a machine on the same network
administered by the same time, it becomes a lot more reasonable to
trust it. Even if it has untrusted users too.
boltar@caprica.universe writes:
Geoff Clare <geoff@clare.See-My-Signature.invalid> gabbled:
boltar wrote:
I've just discovered that the current version of MacOS I'm running
(15.7.5) doesn't seem to enforce restricted TCP ports below 1024 and
a process without root permission seems to be able to open a
listening socket on any port it pleases. I'm using a standard user
account without AFAIK any special priviledges given to it.
Perhaps MacOS never enforced this, anyone know?
Apparently it changed in MacOS Mojave to match how iOS behaves.
See https://developer.apple.com/forums/thread/674179
Cheers for that. Whoever "DTS Engineer" is he clearly doesn't
understand the reasons the restriction was put in in the first place -
ie that the services on low ports are the real deal and not maybe some
credential snatcher spun up by a user. eg, running a hacked version of
sshd on port 22.
Aside from loopback, you never had that assurance anyway.
In the case of SSH, the defence is host key verification, not which port
it runs on.
On Thu, 16 Apr 2026 14:48:08 -0000 (UTC), boltar wrote:
Whoever "DTS Engineer" is he clearly doesn't understand the reasons
the restriction was put in in the first place - ie that the services
on low ports are the real deal and not maybe some credential
snatcher spun up by a user. eg, running a hacked version of sshd on
port 22.
You really expect a remote client to trust a connection to some random >machine just because the destination port number is in some arbitrary >rCLprivilegedrCY range?
That only works in specific niches.
* macOS is not the first OS to discard the rCyprivileged portrCO concept;
Windows never had it.
Richard Kettlewell <invalid@invalid.invalid> gabbled: >>boltar@caprica.universe writes:
Geoff Clare <geoff@clare.See-My-Signature.invalid> gabbled:
boltar wrote:
I've just discovered that the current version of MacOS I'm running
(15.7.5) doesn't seem to enforce restricted TCP ports below 1024 and >>>>> a process without root permission seems to be able to open a
listening socket on any port it pleases. I'm using a standard user
account without AFAIK any special priviledges given to it.
Perhaps MacOS never enforced this, anyone know?
Apparently it changed in MacOS Mojave to match how iOS behaves.
See https://developer.apple.com/forums/thread/674179
Cheers for that. Whoever "DTS Engineer" is he clearly doesn't
understand the reasons the restriction was put in in the first place -
ie that the services on low ports are the real deal and not maybe some
credential snatcher spun up by a user. eg, running a hacked version of
sshd on port 22.
Aside from loopback, you never had that assurance anyway.
In the case of SSH, the defence is host key verification, not which port
it runs on.
A hacked version of ssh could save or forward everything it receives.
Crypto is only useful outside of the process, inside its irrelevant.
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
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.
Richard Kettlewell , dans le message
<wwvfr4uuimd.fsf@LkoBDZeT.terraraq.uk>, a |-crit-a:
That only works in specific niches.
* macOS is not the first OS to discard the rCyprivileged portrCO concept;
Windows never had it.
Only idiots run servers on these systems anyway.
Geoff Clare <geoff@clare.See-My-Signature.invalid> gabbled:
boltar wrote:
I've just discovered that the current version of MacOS I'm running (15.7.5) >>> doesn't seem to enforce restricted TCP ports below 1024 and a process
without root permission seems to be able to open a listening socket on any >>> port it pleases. I'm using a standard user account without AFAIK any special
priviledges given to it.
Perhaps MacOS never enforced this, anyone know?
Apparently it changed in MacOS Mojave to match how iOS behaves.
See https://developer.apple.com/forums/thread/674179
Cheers for that. Whoever "DTS Engineer" is he clearly doesn't understand the >reasons the restriction was put in in the first place - ie that the services >on low ports are the real deal and not maybe some credential snatcher spun
up by a user. eg, running a hacked version of sshd on port 22.
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?
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.
You do realise the data has to be decrypted by ssh in order to
do anything with it, right?
Or did you think it passed the encrypted stream
direct to bash?
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?
Irrelevant. A hacked ssh server could do anything the hacker wants with the >>decrypted data.
What decrypted data? Authentication of the incoming connection
cross@spitfire.i.gajendra.net (Dan Cross) gabbled:
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?
Oh FFS, the hacker server would use whatever keys the hacker wanted it to >use. Do try and keep up.
Irrelevant. A hacked ssh server could do anything the hacker wants with the >>>decrypted data.
What decrypted data? Authentication of the incoming connection
*plonk*
I honestly can't be bothered.
cross@spitfire.i.gajendra.net (Dan Cross) gabbled:
<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?
On Fri, 17 Apr 2026 15:20:09 -0000 (UTC)
cross@spitfire.i.gajendra.net (Dan Cross) gabbled:
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?
Oh FFS, the hacker server would use whatever keys the hacker wanted it to >use. Do try and keep up.
*plonk*
I honestly can't be bothered.
boltar@caprica.universe writes:[...]
[...]Oh FFS, the hacker server would use whatever keys the hacker wanted it to >>use. Do try and keep up.
You don't seem to have an understanding of the session
establishment protocol used by ssh, or the context of the
thread you've butted into (context: the ability for a
non-privileged process to bind to ports below 1024).
In that particular scenario, the non-privleged process
cannot read the host key. Yes, it can present a different
host key, which David pointed out may cause the client to
complain that the host key has been changed - a clear warning
to the user that the host he is attempting to log into may
have been compromised.
If I understand correctly, a non-root user can set up a server on a "privileged" port, but not if that port is already in use. If root is already has sshd listening on port 22, a non-root user won't be able
to set up another server on the same port. (And an ssh server on a
port other than 22 isn't going to be visible unless someone goes
looking for it.)
Which means, unless I'm missing something, that the warning about
a changed host key is not likely to show up.
(Unless the system doesn't have an ssh server -- but then how does the
user get into it?)
And even if there's no existing ssh server, a non-root sshd would only provide access to the user's account.
On Thu, 16 Apr 2026 23:23:37 -0000 (UTC), Lawrence DrCOOliveiro wrote:
You really expect a remote client to trust a connection to some
random machine just because the destination port number is in some
arbitrary rCLprivilegedrCY range?
On a corporate LAN, yes.
scott@slp53.sl.home (Scott Lurndal) writes:
boltar@caprica.universe writes:[...]
[...]Oh FFS, the hacker server would use whatever keys the hacker wanted it to >>>use. Do try and keep up.
You don't seem to have an understanding of the session
establishment protocol used by ssh, or the context of the
thread you've butted into (context: the ability for a
non-privileged process to bind to ports below 1024).
In that particular scenario, the non-privleged process
cannot read the host key. Yes, it can present a different
host key, which David pointed out may cause the client to
complain that the host key has been changed - a clear warning
to the user that the host he is attempting to log into may
have been compromised.
If I understand correctly, a non-root user can set up a server on a >"privileged" port, but not if that port is already in use. If root
is already has sshd listening on port 22, a non-root user won't
be able to set up another server on the same port. (And an ssh
server on a port other than 22 isn't going to be visible unless
someone goes looking for it.)
Which means, unless I'm missing something, that the warning about
a changed host key is not likely to show up. (Unless the system
doesn't have an ssh server -- but then how does the user get
into it?)
And even if there's no existing ssh server, a non-root sshd would
only provide access to the user's account.
More plausibly, a non-root user could set up an ftp server.
But suppose the SSH daemon is not running, and some random user
sets up an imposter server listening on that port. Since
unprivileged users can bind any port (including 22), they can do
so. But, since they presumably cannot read the file containing
the host private key, they lack the cryptographic key material
required to authenticate as the real server using the RFC4253
host authentication protocol. Clients will notice that and
fail to establish an SSH transport protocol connection, well
before user authentication is attempted, let alone a shell or
anything similar is executed.
[...]
But suppose the SSH daemon is not running, and some random user
sets up an imposter server listening on that port. Since
unprivileged users can bind any port (including 22), they can do
so. But, since they presumably cannot read the file containing
the host private key, they lack the cryptographic key material
required to authenticate as the real server using the RFC4253
host authentication protocol. Clients will notice that and
fail to establish an SSH transport protocol connection, well
before user authentication is attempted, let alone a shell or
anything similar is executed.
And *some* users will see the "WARNING: REMOTE HOST IDENTIFICATION HAS >CHANGED!" message and blindly add the new key to their known_hosts file.
Richard Kettlewell , dans le message
<wwvfr4uuimd.fsf@LkoBDZeT.terraraq.uk>, a |-crit-a:
That only works in specific niches.
* macOS is not the first OS to discard the rCyprivileged portrCO concept;
Windows never had it.
Only idiots run servers on these systems anyway.
In article <10rtkrv$2ifdm$1@dont-email.me>, <boltar@caprica.universe> wrote: >>On Fri, 17 Apr 2026 15:20:09 -0000 (UTC)
Oh FFS, the hacker server would use whatever keys the hacker wanted it to >>use. Do try and keep up.
....and then they wouldn't match what the user already had in
their, `.ssh/known_hosts` file.
I honestly can't be bothered.
Yes. You clearly, obviously, can't be bothered to understand
even the most rudimentary concepts around how public key
authentication works. Like, at all.
boltar@caprica.universe writes:
On Fri, 17 Apr 2026 15:20:09 -0000 (UTC)
cross@spitfire.i.gajendra.net (Dan Cross) gabbled:
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 +0100Not if it can't read the host key because it doesn't have
A hacked version of ssh could save or forward everything it receives. >>>>>
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?
Oh FFS, the hacker server would use whatever keys the hacker wanted it to >>use. Do try and keep up.
You don't seem to have an understanding of the session
establishment protocol used by ssh, or the context of the
thread you've butted into (context: the ability for a
non-privileged process to bind to ports below 1024).
boltar@caprica.universe writes:
cross@spitfire.i.gajendra.net (Dan Cross) gabbled:
<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?
Non-root users canrCOt read the legitimate host key:
$ ls -l /etc/ssh/ssh_host_ed25519_key
-rw------- 1 root root 399 Dec 10 2017 /etc/ssh/ssh_host_ed25519_key
$ cat /etc/ssh/ssh_host_ed25519_key
cat: /etc/ssh/ssh_host_ed25519_key: Permission denied
If a malicious non-root user creates their own host key then clients
will refuse to talk to their SSH server. For example OpenSSH display an
error like this:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
scott@slp53.sl.home (Scott Lurndal) writes:
If I understand correctly, a non-root user can set up a server on a >"privileged" port, but not if that port is already in use. If root
Which means, unless I'm missing something, that the warning about
a changed host key is not likely to show up. (Unless the system
doesn't have an ssh server -- but then how does the user get
into it?)
And even if there's no existing ssh server, a non-root sshd would
only provide access to the user's account.
In article <87tst9s4v4.fsf@kst.eternal-september.org>,
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
And even if there's no existing ssh server, a non-root sshd would
only provide access to the user's account.
Not even. The client wouldn't be able to authenticate the
identity of the server _at all_, regardless of what user it was
running at.
Richard Kettlewell <invalid@invalid.invalid> gabbled:
boltar@caprica.universe writes:
cross@spitfire.i.gajendra.net (Dan Cross) gabbled:
<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?
Non-root users canrCOt read the legitimate host key:
Why would the hacked server need to?
If a malicious non-root user creates their own host key then clients
will refuse to talk to their SSH server. For example OpenSSH display an
error like this:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
How can it have changed if the only sshd running was the one the hacker
set up?
boltar@caprica.universe writes:
Richard Kettlewell <invalid@invalid.invalid> gabbled: >>>boltar@caprica.universe writes:
cross@spitfire.i.gajendra.net (Dan Cross) gabbled:
<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?
Non-root users canrCOt read the legitimate host key:
Why would the hacked server need to?
The point is that your hacked server is not going to be using the
legitimate host key.
How can it have changed if the only sshd running was the one the hacker
set up?
Largely already discussed in <wwvo6jh1cfw.fsf@LkoBDZeT.terraraq.uk>, but
in brief, if the client doesnrCOt already trust the key then the user gets >told that the key is unknown, and if it does then the user has at some
point in the past chosen to trust that key (or a CA that signed it).
cross@spitfire.i.gajendra.net (Dan Cross) gabbled:
In article <10rtkrv$2ifdm$1@dont-email.me>, <boltar@caprica.universe> wrote: >>>On Fri, 17 Apr 2026 15:20:09 -0000 (UTC)
Oh FFS, the hacker server would use whatever keys the hacker wanted it to >>>use. Do try and keep up.
....and then they wouldn't match what the user already had in
their, `.ssh/known_hosts` file.
Right, because an extra warning prompt from the client will stop people >logging in.
I honestly can't be bothered.
Yes. You clearly, obviously, can't be bothered to understand
even the most rudimentary concepts around how public key
authentication works. Like, at all.
And you apparently have no idea that if someone has the source code to a >program they can make it do and behave whatever and however they want.
I suggest you stick to sys admin and leave the dev discussions to people
who have a clue.
cross@spitfire.i.gajendra.net (Dan Cross) gabbled:
In article <87tst9s4v4.fsf@kst.eternal-september.org>,
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
And even if there's no existing ssh server, a non-root sshd would
only provide access to the user's account.
Not even. The client wouldn't be able to authenticate the
identity of the server _at all_, regardless of what user it was
running at.
And why's that? Do give us the benefit of your wisdom.
[...] No one when first connecting to an sshd goes
to google the key to see if its valid, they type "yes" and carry on.
In article <10rvmcd$1hiok$1@dont-email.me>, <boltar@caprica.universe> wrote: >>On Fri, 17 Apr 2026 16:09:19 -0000 (UTC)
cross@spitfire.i.gajendra.net (Dan Cross) gabbled:
In article <10rtkrv$2ifdm$1@dont-email.me>, <boltar@caprica.universe> wrote:
On Fri, 17 Apr 2026 15:20:09 -0000 (UTC)
Oh FFS, the hacker server would use whatever keys the hacker wanted it to >>>>use. Do try and keep up.
....and then they wouldn't match what the user already had in
their, `.ssh/known_hosts` file.
Right, because an extra warning prompt from the client will stop people >>logging in.
Wow, you really don't get it.
And you apparently have no idea that if someone has the source code to a >>program they can make it do and behave whatever and however they want.
I suggest you stick to sys admin and leave the dev discussions to people >>who have a clue.
Lol. I'm not a sysadmin.
In article <10rvn05$355fj$1@dont-email.me>, <boltar@caprica.universe> wrote: >>On Fri, 17 Apr 2026 22:56:50 -0000 (UTC)
cross@spitfire.i.gajendra.net (Dan Cross) gabbled:
In article <87tst9s4v4.fsf@kst.eternal-september.org>,
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
And even if there's no existing ssh server, a non-root sshd would
only provide access to the user's account.
Not even. The client wouldn't be able to authenticate the
identity of the server _at all_, regardless of what user it was
running at.
And why's that? Do give us the benefit of your wisdom.
I already explained it. You didn't understand it. I see no
reason to believe that explaining it again would enlighten you,
as you seem to revel in deliberate ignorance.
boltar@caprica.universe wrote:
[...] No one when first connecting to an sshd goes
to google the key to see if its valid, they type "yes" and carry on.
Not really true. Some people are more cautious than that.
Anyway, lots has been said in this thread, but I suppose
nobody has mentioned that running sshd on port > 1024
is pretty common nowadays.
cross@spitfire.i.gajendra.net (Dan Cross) gabbled:
In article <10rvmcd$1hiok$1@dont-email.me>, <boltar@caprica.universe> wrote: >>>On Fri, 17 Apr 2026 16:09:19 -0000 (UTC)
cross@spitfire.i.gajendra.net (Dan Cross) gabbled:
In article <10rtkrv$2ifdm$1@dont-email.me>, <boltar@caprica.universe> wrote:
On Fri, 17 Apr 2026 15:20:09 -0000 (UTC)
Oh FFS, the hacker server would use whatever keys the hacker wanted it to >>>>>use. Do try and keep up.
....and then they wouldn't match what the user already had in
their, `.ssh/known_hosts` file.
Right, because an extra warning prompt from the client will stop people >>>logging in.
Wow, you really don't get it.
What, that people ignore warnings?
And you apparently have no idea that if someone has the source code to a >>>program they can make it do and behave whatever and however they want.
I suggest you stick to sys admin and leave the dev discussions to people >>>who have a clue.
Lol. I'm not a sysadmin.
Stick to cleaning the floors then because you apparently have no idea about >modifying code.
cross@spitfire.i.gajendra.net (Dan Cross) gabbled:
In article <10rvn05$355fj$1@dont-email.me>, <boltar@caprica.universe> wrote: >>>On Fri, 17 Apr 2026 22:56:50 -0000 (UTC)
cross@spitfire.i.gajendra.net (Dan Cross) gabbled:
In article <87tst9s4v4.fsf@kst.eternal-september.org>,
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
And even if there's no existing ssh server, a non-root sshd would >>>>>only provide access to the user's account.
Not even. The client wouldn't be able to authenticate the
identity of the server _at all_, regardless of what user it was
running at.
And why's that? Do give us the benefit of your wisdom.
I already explained it. You didn't understand it. I see no
No you haven't. At all.
reason to believe that explaining it again would enlighten you,
as you seem to revel in deliberate ignorance.
The only ignorant person is you who seems to think an ssh client wouldn't >connect to a modified sshd not running as root because [reasons].
Please give those reasons or go find something more useful to do.
In article <10s07ro$3a575$1@dont-email.me>, <boltar@caprica.universe> wrote: >>Stick to cleaning the floors then because you apparently have no idea about >>modifying code.
Hey, I'm not the one who doesn't understand how SSH works, Mr
Anonymous Internet Rando Guy.
Security by obscurity never works. A port scanner would find it in minutes.
On 2026-04-17, Nicolas George wrote:
Richard Kettlewell , dans le message
<wwvfr4uuimd.fsf@LkoBDZeT.terraraq.uk>, a |-crit-a:
That only works in specific niches.
* macOS is not the first OS to discard the rCyprivileged portrCO concept; >>> Windows never had it.
Only idiots run servers on these systems anyway.
In article <10s07uq$3a63c$1@dont-email.me>, <boltar@caprica.universe> wrote: >>On Sat, 18 Apr 2026 15:08:03 -0000 (UTC)
I already explained it. You didn't understand it. I see no
No you haven't. At all.
Go read RFC 4253.
reason to believe that explaining it again would enlighten you,
as you seem to revel in deliberate ignorance.
The only ignorant person is you who seems to think an ssh client wouldn't >>connect to a modified sshd not running as root because [reasons].
Please give those reasons or go find something more useful to do.
See above reference.
On Fri, 17 Apr 2026 16:09:19 -0000 (UTC)
cross@spitfire.i.gajendra.net (Dan Cross) gabbled:
In article <10rtkrv$2ifdm$1@dont-email.me>, <boltar@caprica.universe> wrote: >>>On Fri, 17 Apr 2026 15:20:09 -0000 (UTC)
Oh FFS, the hacker server would use whatever keys the hacker wanted it to >>>use. Do try and keep up.
....and then they wouldn't match what the user already had in
their, `.ssh/known_hosts` file.
Right, because an extra warning prompt from the client will stop people >logging in.
cross@spitfire.i.gajendra.net (Dan Cross) gabbled:
In article <10s07ro$3a575$1@dont-email.me>, <boltar@caprica.universe> wrote: >>>Stick to cleaning the floors then because you apparently have no idea about >>>modifying code.
Hey, I'm not the one who doesn't understand how SSH works, Mr
You're the one who doesn't seem to understand that as long as the client
gets a valid certificate its happy. Beyond that all bets are off.
Anonymous Internet Rando Guy.
And what? Perhaps you should be too - no one is going to be too impressed >with your inability to follow a line of deduction if they google your name >though you might be lucky in that google probably no longer indexes usenet >now.
boltar@caprica.universe wrote:
Security by obscurity never works. A port scanner would find it in minutes.
You have already proven your stupidity in this thread
many times before. Your lack of understanding is huge.
cross@spitfire.i.gajendra.net (Dan Cross) gabbled:
In article <10s07uq$3a63c$1@dont-email.me>, <boltar@caprica.universe> wrote: >>>On Sat, 18 Apr 2026 15:08:03 -0000 (UTC)
I already explained it. You didn't understand it. I see no
No you haven't. At all.
Go read RFC 4253.
What about it? You think someone in there it says "if the sshd code is hacked >it automagically won't work! So ya boo sucks Mr hacker!".
reason to believe that explaining it again would enlighten you,
as you seem to revel in deliberate ignorance.
The only ignorant person is you who seems to think an ssh client wouldn't >>>connect to a modified sshd not running as root because [reasons].
Please give those reasons or go find something more useful to do.
See above reference.
You truly are an idiot.
boltar@caprica.universe writes:
On Fri, 17 Apr 2026 16:09:19 -0000 (UTC)
cross@spitfire.i.gajendra.net (Dan Cross) gabbled:
In article <10rtkrv$2ifdm$1@dont-email.me>, <boltar@caprica.universe> wrote:
On Fri, 17 Apr 2026 15:20:09 -0000 (UTC)
Oh FFS, the hacker server would use whatever keys the hacker wanted it to >>>>use. Do try and keep up.
....and then they wouldn't match what the user already had in
their, `.ssh/known_hosts` file.
Right, because an extra warning prompt from the client will stop people >>logging in.
That's likely to be the case. ssh isn't generally used by unsophisticated >users (you may be an exception to the rule).
In article <10s09b5$3ajoj$1@dont-email.me>, <boltar@caprica.universe> wrote: >>On Sat, 18 Apr 2026 15:48:03 -0000 (UTC)
cross@spitfire.i.gajendra.net (Dan Cross) gabbled:
In article <10s07ro$3a575$1@dont-email.me>, <boltar@caprica.universe> wrote:
Stick to cleaning the floors then because you apparently have no idea about >>>>modifying code.
Hey, I'm not the one who doesn't understand how SSH works, Mr
You're the one who doesn't seem to understand that as long as the client >>gets a valid certificate its happy. Beyond that all bets are off.
Actually, I acknowledged that in my first post on the matter.
Not my fault if you can't read.
And what? Perhaps you should be too - no one is going to be too impressed >>with your inability to follow a line of deduction if they google your name >>though you might be lucky in that google probably no longer indexes usenet >>now.
I'm not too worried about my reputation, but I can see why you
On Sat, 18 Apr 2026 15:52:56 -0000 (UTC)
kalevi@kolttonen.fi (Kalevi Kolttonen) gabbled:
boltar@caprica.universe wrote:
Security by obscurity never works. A port scanner would find it in minutes. >>You have already proven your stupidity in this thread
many times before. Your lack of understanding is huge.
So you think sshd isn't vulnerable to DDoS. Another fool to put on the list.
Richard Kettlewell <invalid@invalid.invalid> gabbled:
boltar@caprica.universe writes:
Richard Kettlewell <invalid@invalid.invalid> gabbled: >>>>boltar@caprica.universe writes:
cross@spitfire.i.gajendra.net (Dan Cross) gabbled:
<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?
Non-root users canrCOt read the legitimate host key:
Why would the hacked server need to?
The point is that your hacked server is not going to be using the >>legitimate host key.
And why would there be a legitimate host key in the first place?
You're assuming there was a legitimate version of sshd running there beforehand which clients had connected to.
How can it have changed if the only sshd running was the one the hacker
set up?
Largely already discussed in <wwvo6jh1cfw.fsf@LkoBDZeT.terraraq.uk>, but
in brief, if the client doesnrCOt already trust the key then the user gets >>told that the key is unknown, and if it does then the user has at some >>point in the past chosen to trust that key (or a CA that signed it).
Yes, we all know this. And? No one when first connecting to an sshd
goes to google the key to see if its valid, they type "yes" and carry
on.
Nuno Silva <nunojsilva@invalid.invalid> writes:
On 2026-04-17, Nicolas George wrote:
Richard Kettlewell , dans le message
<wwvfr4uuimd.fsf@LkoBDZeT.terraraq.uk>, a |-crit-a:
That only works in specific niches.
* macOS is not the first OS to discard the rCyprivileged portrCO concept; >>>> Windows never had it.
Only idiots run servers on these systems anyway.
There were a couple of occasions where Apple tried to
enter the server market (e.g. the 1U Xserv). They never
really caught on. IIRC, they were intending at one
point to use their ARM64 silicon in a line of servers.
They do build custom servers for their own datacenters
using their ARM64 silicon.
cross@spitfire.i.gajendra.net (Dan Cross) gabbled:
In article <10s09b5$3ajoj$1@dont-email.me>, <boltar@caprica.universe> wrote: >>>On Sat, 18 Apr 2026 15:48:03 -0000 (UTC)
cross@spitfire.i.gajendra.net (Dan Cross) gabbled:
In article <10s07ro$3a575$1@dont-email.me>, <boltar@caprica.universe> wrote:
Stick to cleaning the floors then because you apparently have no idea about
modifying code.
Hey, I'm not the one who doesn't understand how SSH works, Mr
You're the one who doesn't seem to understand that as long as the client >>>gets a valid certificate its happy. Beyond that all bets are off.
Actually, I acknowledged that in my first post on the matter.
Not my fault if you can't read.
So you're arguing against yourself. Have fun.
And what? Perhaps you should be too - no one is going to be too impressed >>>with your inability to follow a line of deduction if they google your name >>>though you might be lucky in that google probably no longer indexes usenet >>>now.
I'm not too worried about my reputation, but I can see why you
I wouldn't be if I were you either , too late :)
No one when first connecting to an sshd goes to google the key to
see if its valid, they type "yes" and carry on.
On Fri, 17 Apr 2026 16:09:19 -0000 (UTC)
cross@spitfire.i.gajendra.net (Dan Cross) gabbled:
In article <10rtkrv$2ifdm$1@dont-email.me>, <boltar@caprica.universe> wrote: >>>On Fri, 17 Apr 2026 15:20:09 -0000 (UTC)
Oh FFS, the hacker server would use whatever keys the hacker wanted it to >>>use. Do try and keep up.
....and then they wouldn't match what the user already had in
their, `.ssh/known_hosts` file.
Right, because an extra warning prompt from the client will stop people logging in.
I honestly can't be bothered.
Yes. You clearly, obviously, can't be bothered to understand
even the most rudimentary concepts around how public key
authentication works. Like, at all.
And you apparently have no idea that if someone has the source code to a program they can make it do and behave whatever and however they want.
I suggest you stick to sys admin and leave the dev discussions to people
who have a clue.
On Sat, 18 Apr 2026 15:56:25 GMT
scott@slp53.sl.home (Scott Lurndal) gabbled:
boltar@caprica.universe writes:
On Fri, 17 Apr 2026 16:09:19 -0000 (UTC)
cross@spitfire.i.gajendra.net (Dan Cross) gabbled:
In article <10rtkrv$2ifdm$1@dont-email.me>, <boltar@caprica.universe> wrote:
On Fri, 17 Apr 2026 15:20:09 -0000 (UTC)
Oh FFS, the hacker server would use whatever keys the hacker wanted it to >>>>>use. Do try and keep up.
....and then they wouldn't match what the user already had in
their, `.ssh/known_hosts` file.
Right, because an extra warning prompt from the client will stop people >>>logging in.
That's likely to be the case. ssh isn't generally used by unsophisticated >>users (you may be an exception to the rule).
No, it isn't, because ALL first ssh connections give that warning and almost all people ignore it. But I wouldn't expect an aspie to understand that.
On Sat, 18 Apr 2026 15:14:38 -0000 (UTC)
kalevi@kolttonen.fi (Kalevi Kolttonen) gabbled:
boltar@caprica.universe wrote:
[...] No one when first connecting to an sshd goes
to google the key to see if its valid, they type "yes" and carry on.
Not really true. Some people are more cautious than that.
Pfft, yeah, right.
Anyway, lots has been said in this thread, but I suppose
nobody has mentioned that running sshd on port > 1024
is pretty common nowadays.
Security by obscurity never works. A port scanner would find it in
minutes.
[snip]
(The way you word it sounds like you'd also say it's just a matter of
coding to be able to write a computer program that prints 1 if a program >given as input will terminate and 0 if it will keep running forever?)
On 2026-04-18, boltar@caprica.universe wrote:
On Sat, 18 Apr 2026 15:14:38 -0000 (UTC)
kalevi@kolttonen.fi (Kalevi Kolttonen) gabbled:
boltar@caprica.universe wrote:
[...] No one when first connecting to an sshd goes
to google the key to see if its valid, they type "yes" and carry on.
Not really true. Some people are more cautious than that.
Pfft, yeah, right.
I'm not saying you should read the room, but you should at least read
the posts in the thread. It should be evident to you at this point that
at least some people here are at least to some extent cautious enough in >these matters.
Anyway, lots has been said in this thread, but I suppose
nobody has mentioned that running sshd on port > 1024
is pretty common nowadays.
Security by obscurity never works. A port scanner would find it in
minutes.
It can delay, it really depends on what is being obscured. Not knowing a >private key is sort of obscurity, isn't it?
On Fri, 17 Apr 2026 13:34:39 -0700[...]
Keith Thompson <Keith.S.Thompson+u@gmail.com> gabbled:
And even if there's no existing ssh server, a non-root sshd would
only provide access to the user's account.
That would be main downside, not the handwaving guff about certificates
that others have come up with.
In article <10s09gt$3al9g$1@dont-email.me>, <boltar@caprica.universe> wrote: >>On Sat, 18 Apr 2026 15:48:38 -0000 (UTC)
cross@spitfire.i.gajendra.net (Dan Cross) gabbled:
In article <10s07uq$3a63c$1@dont-email.me>, <boltar@caprica.universe> wrote:
On Sat, 18 Apr 2026 15:08:03 -0000 (UTC)
I already explained it. You didn't understand it. I see no
No you haven't. At all.
Go read RFC 4253.
What about it? You think someone in there it says "if the sshd code is hacked >>it automagically won't work! So ya boo sucks Mr hacker!".
....and you think that magically restricting access to port 22
fixes that?
You truly are an idiot.
I think you don't understand how cryptography works.
In article <10s09od$3angd$1@dont-email.me>, <boltar@caprica.universe> wrote: >>On Sat, 18 Apr 2026 15:56:47 -0000 (UTC)
I'm not too worried about my reputation, but I can see why you
I wouldn't be if I were you either , too late :)
....he says as he hides behind a thin veneer of anonymity.
On 2026-04-18, boltar@caprica.universe wrote:
On Sat, 18 Apr 2026 15:14:38 -0000 (UTC)
kalevi@kolttonen.fi (Kalevi Kolttonen) gabbled:
boltar@caprica.universe wrote:
[...] No one when first connecting to an sshd goes
to google the key to see if its valid, they type "yes" and carry on.
Not really true. Some people are more cautious than that.
Pfft, yeah, right.
I'm not saying you should read the room, but you should at least read
the posts in the thread. It should be evident to you at this point that
at least some people here are at least to some extent cautious enough in >these matters.
boltar@caprica.universe writes:
On Fri, 17 Apr 2026 13:34:39 -0700[...]
Keith Thompson <Keith.S.Thompson+u@gmail.com> gabbled:
And even if there's no existing ssh server, a non-root sshd would
only provide access to the user's account.
That would be main downside, not the handwaving guff about certificates
that others have come up with.
One last thing: I don't know whether the your user name "boltar"
is a misspelling of "Baltar" or not.
Don't bother answering. Your recent habit of insulting people,
particularly people who are quite knowledgeable, has earned you a
spot in my killfile. Others will do as they want, but for the sake
of the signal/noise ratio of this newsgroup, I encourage everyone
else to stop replying to your posts.
On Sun, 19 Apr 2026 00:24:34 +0100
Nuno Silva <nunojsilva@invalid.invalid> gabbled:
On 2026-04-18, boltar@caprica.universe wrote:
On Sat, 18 Apr 2026 15:14:38 -0000 (UTC)
kalevi@kolttonen.fi (Kalevi Kolttonen) gabbled:
boltar@caprica.universe wrote:
[...] No one when first connecting to an sshd goes
to google the key to see if its valid, they type "yes" and carry on.
Not really true. Some people are more cautious than that.
Pfft, yeah, right.
I'm not saying you should read the room, but you should at least read
the posts in the thread. It should be evident to you at this point that
at least some people here are at least to some extent cautious enough in >>these matters.
They seem to assume they're typical of most users. They're not.
On Fri, 17 Apr 2026 13:34:39 -0700
Keith Thompson <Keith.S.Thompson+u@gmail.com> gabbled:
scott@slp53.sl.home (Scott Lurndal) writes:
If I understand correctly, a non-root user can set up a server on a >>"privileged" port, but not if that port is already in use. If root
Yes, thats kind of how TCP works. Would be a bit tricky having 2 programs
on the same port.
Which means, unless I'm missing something, that the warning about
a changed host key is not likely to show up. (Unless the system
doesn't have an ssh server -- but then how does the user get
into it?)
Console.
And even if there's no existing ssh server, a non-root sshd would
only provide access to the user's account.
That would be main downside, not the handwaving guff about certificates
that others have come up with.
cross@spitfire.i.gajendra.net (Dan Cross) gabbled:
In article <10s09gt$3al9g$1@dont-email.me>, <boltar@caprica.universe> wrote: >>>On Sat, 18 Apr 2026 15:48:38 -0000 (UTC)
cross@spitfire.i.gajendra.net (Dan Cross) gabbled:
In article <10s07uq$3a63c$1@dont-email.me>, <boltar@caprica.universe> wrote:
On Sat, 18 Apr 2026 15:08:03 -0000 (UTC)
I already explained it. You didn't understand it. I see no
No you haven't. At all.
Go read RFC 4253.
What about it? You think someone in there it says "if the sshd code is hacked
it automagically won't work! So ya boo sucks Mr hacker!".
....and you think that magically restricting access to port 22
fixes that?
No, I'm saying its a small link in the chain of security.
You truly are an idiot.
I think you don't understand how cryptography works.
You think sshd doesn't decrpyt the data before it forwards it
to bash?
Aww, bles
s.
On Sat, 18 Apr 2026 17:54:21 -0700
Keith Thompson <Keith.S.Thompson+u@gmail.com> gabbled: >>boltar@caprica.universe writes:
On Fri, 17 Apr 2026 13:34:39 -0700[...]
Keith Thompson <Keith.S.Thompson+u@gmail.com> gabbled:
And even if there's no existing ssh server, a non-root sshd would
only provide access to the user's account.
That would be main downside, not the handwaving guff about certificates
that others have come up with.
One last thing: I don't know whether the your user name "boltar"
is a misspelling of "Baltar" or not.
Well done, have a scooby snack.
Don't bother answering. Your recent habit of insulting people, >>particularly people who are quite knowledgeable, has earned you a
spot in my killfile. Others will do as they want, but for the sake
Easily worked around.
of the signal/noise ratio of this newsgroup, I encourage everyone
else to stop replying to your posts.
I'll insult people who patronise,
wilfully misunderstand me
and tell me I
don't know what I'm talking about
in order to score pathetic points with
others on this group
when all I did was post what I thought was an interesting
topic about ports.
Some usenet groups like this never change, just an ever decreasing number of >arrogant know-it-alls circle jerking.
This fool also doesn't seem to understand that it's all about
relative effort; the Internet is so chock-full of soft targets
it is hardly worth an adversary's time to search non-default
ports, but a lot of systems change the default simply because
they're tired of their logs being choked by random bot scanning
for known vulnerabilities.
So, I switched the port of sshd. Voila! No more attacks. None.
On 2026-04-18, boltar@caprica.universe wrote:
That would be main downside, not the handwaving guff about certificates
that others have come up with.
It's not "handwaving guff", it's asymmetric cryptography, and computer >science.
Barring a flaw that allows a user to read the system's private key for
sshd - which would be a major issue, I think - there's no feasible way
in which a user could impersonate the key of the legitimate system-wide
sshd. At least without e.g. time travel.
In article <10s25j3$1km5f$1@dont-email.me>, <boltar@caprica.universe> wrote: >>On Sat, 18 Apr 2026 15:57:42 -0000 (UTC)
....and you think that magically restricting access to port 22
fixes that?
No, I'm saying its a small link in the chain of security.
And others have pointed out to you how it really isn't. And you
cannot resist proving yourself incapable of understanding that.
You think sshd doesn't decrpyt the data before it forwards it
Case in point. Rather QED, I'm afraid.
to bash?
Are you aware that there are shells other than `bash`?
Aww, bles
s.
Odd formatting. I guess you can't use a text editor, either.
In article <10s261u$3rucs$1@dont-email.me>, <baltar@caprica.prime> wrote: >>Some usenet groups like this never change, just an ever decreasing number of >>arrogant know-it-alls circle jerking.
Sounds like you're butthurt that got caught out showing your ass
by putting your ignorance on such proud display.
cross@spitfire.i.gajendra.net (Dan Cross) gabbled:
In article <10s25j3$1km5f$1@dont-email.me>, <boltar@caprica.universe> wrote: >>>On Sat, 18 Apr 2026 15:57:42 -0000 (UTC)
....and you think that magically restricting access to port 22
fixes that?
No, I'm saying its a small link in the chain of security.
And others have pointed out to you how it really isn't. And you
cannot resist proving yourself incapable of understanding that.
Its psychological, not software. Another aspie who doesn't get it.
You think sshd doesn't decrpyt the data before it forwards it
Case in point. Rather QED, I'm afraid.
What is a case in point?
to bash?
Are you aware that there are shells other than `bash`?
Nooooooo! Really?? Say it aint so!
Aww, bles
s.
Odd formatting. I guess you can't use a text editor, either.
That really the best you can do?
In article <10s4rud$katd$1@dont-email.me>, <boltar@caprica.universe> wrote: >>On Sun, 19 Apr 2026 13:20:29 -0000 (UTC)
That really the best you can do?
You're not worth my time.
cross@spitfire.i.gajendra.net (Dan Cross) gabbled:
In article <10s4rud$katd$1@dont-email.me>, <boltar@caprica.universe> wrote: >>>On Sun, 19 Apr 2026 13:20:29 -0000 (UTC)
That really the best you can do?
You're not worth my time.
I imagine thats what your boss thinks most days.
On Sun, 19 Apr 2026 10:45:30 +0100
Nuno Silva <nunojsilva@invalid.invalid> gabbled:
On 2026-04-18, boltar@caprica.universe wrote:
That would be main downside, not the handwaving guff about certificates
that others have come up with.
It's not "handwaving guff", it's asymmetric cryptography, and computer >>science.
It is because its utterly irrelevant in this case.
Barring a flaw that allows a user to read the system's private key for
sshd - which would be a major issue, I think - there's no feasible way
in which a user could impersonate the key of the legitimate system-wide >>sshd. At least without e.g. time travel.
Why would it need to? As long as it had a valid key the client is happy with it would work fine.
On 2026-04-20, boltar@caprica.universe wrote:
On Sun, 19 Apr 2026 10:45:30 +0100
Nuno Silva <nunojsilva@invalid.invalid> gabbled:
On 2026-04-18, boltar@caprica.universe wrote:
That would be main downside, not the handwaving guff about certificates >>>> that others have come up with.
It's not "handwaving guff", it's asymmetric cryptography, and computer >>>science.
It is because its utterly irrelevant in this case.
Barring a flaw that allows a user to read the system's private key for >>>sshd - which would be a major issue, I think - there's no feasible way
in which a user could impersonate the key of the legitimate system-wide >>>sshd. At least without e.g. time travel.
Why would it need to? As long as it had a valid key the client is happy with >> it would work fine.
Because the client would not be happy with it.
| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 65 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 10:00:38 |
| Calls: | 862 |
| Files: | 1,311 |
| D/L today: |
3 files (7,546K bytes) |
| Messages: | 265,184 |