Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.unix.programmer > #17065 > unrolled thread
| Started by | boltar@caprica.universe |
|---|---|
| First post | 2026-04-16 08:44 +0000 |
| Last post | 2026-04-17 14:58 +0000 |
| Articles | 20 on this page of 82 — 12 participants |
Back to article view | Back to comp.unix.programmer
MacOS TCP port permissions boltar@caprica.universe - 2026-04-16 08:44 +0000
Re: MacOS TCP port permissions Geoff Clare <geoff@clare.See-My-Signature.invalid> - 2026-04-16 13:23 +0100
Re: MacOS TCP port permissions boltar@caprica.universe - 2026-04-16 14:48 +0000
Re: MacOS TCP port permissions Richard Kettlewell <invalid@invalid.invalid> - 2026-04-16 20:29 +0100
Re: MacOS TCP port permissions boltar@caprica.universe - 2026-04-17 10:31 +0000
Re: MacOS TCP port permissions cross@spitfire.i.gajendra.net (Dan Cross) - 2026-04-17 14:04 +0000
Re: MacOS TCP port permissions boltar@caprica.universe - 2026-04-17 14:41 +0000
Re: MacOS TCP port permissions cross@spitfire.i.gajendra.net (Dan Cross) - 2026-04-17 15:20 +0000
Re: MacOS TCP port permissions boltar@caprica.universe - 2026-04-17 15:50 +0000
Re: MacOS TCP port permissions cross@spitfire.i.gajendra.net (Dan Cross) - 2026-04-17 16:09 +0000
Re: MacOS TCP port permissions boltar@caprica.universe - 2026-04-18 10:28 +0000
Re: MacOS TCP port permissions cross@spitfire.i.gajendra.net (Dan Cross) - 2026-04-18 15:06 +0000
Re: MacOS TCP port permissions boltar@caprica.universe - 2026-04-18 15:26 +0000
Re: MacOS TCP port permissions cross@spitfire.i.gajendra.net (Dan Cross) - 2026-04-18 15:48 +0000
Re: MacOS TCP port permissions boltar@caprica.universe - 2026-04-18 15:52 +0000
Re: MacOS TCP port permissions cross@spitfire.i.gajendra.net (Dan Cross) - 2026-04-18 15:56 +0000
Re: MacOS TCP port permissions boltar@caprica.universe - 2026-04-18 15:59 +0000
Re: MacOS TCP port permissions cross@spitfire.i.gajendra.net (Dan Cross) - 2026-04-18 16:12 +0000
Re: MacOS TCP port permissions boltar@caprica.universe - 2026-04-19 09:02 +0000
Re: MacOS TCP port permissions scott@slp53.sl.home (Scott Lurndal) - 2026-04-18 15:56 +0000
Re: MacOS TCP port permissions boltar@caprica.universe - 2026-04-18 15:58 +0000
Re: MacOS TCP port permissions Nuno Silva <nunojsilva@invalid.invalid> - 2026-04-19 00:05 +0100
Re: MacOS TCP port permissions Nuno Silva <nunojsilva@invalid.invalid> - 2026-04-19 00:01 +0100
Re: MacOS TCP port permissions cross@spitfire.i.gajendra.net (Dan Cross) - 2026-04-18 23:50 +0000
Re: MacOS TCP port permissions scott@slp53.sl.home (Scott Lurndal) - 2026-04-17 19:56 +0000
Re: MacOS TCP port permissions Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-17 13:34 -0700
Re: MacOS TCP port permissions Richard Kettlewell <invalid@invalid.invalid> - 2026-04-17 22:53 +0100
Re: MacOS TCP port permissions cross@spitfire.i.gajendra.net (Dan Cross) - 2026-04-17 22:56 +0000
Re: MacOS TCP port permissions Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-17 16:48 -0700
Re: MacOS TCP port permissions cross@spitfire.i.gajendra.net (Dan Cross) - 2026-04-18 01:56 +0000
Re: MacOS TCP port permissions boltar@caprica.universe - 2026-04-18 10:39 +0000
Re: MacOS TCP port permissions cross@spitfire.i.gajendra.net (Dan Cross) - 2026-04-18 15:08 +0000
Re: MacOS TCP port permissions boltar@caprica.universe - 2026-04-18 15:28 +0000
Re: MacOS TCP port permissions cross@spitfire.i.gajendra.net (Dan Cross) - 2026-04-18 15:48 +0000
Re: MacOS TCP port permissions boltar@caprica.universe - 2026-04-18 15:55 +0000
Re: MacOS TCP port permissions cross@spitfire.i.gajendra.net (Dan Cross) - 2026-04-18 15:57 +0000
Re: MacOS TCP port permissions boltar@caprica.universe - 2026-04-19 09:00 +0000
Re: MacOS TCP port permissions cross@spitfire.i.gajendra.net (Dan Cross) - 2026-04-19 13:20 +0000
Re: MacOS TCP port permissions boltar@caprica.universe - 2026-04-20 09:34 +0000
Re: MacOS TCP port permissions cross@spitfire.i.gajendra.net (Dan Cross) - 2026-04-20 12:42 +0000
Re: MacOS TCP port permissions boltar@caprica.universe - 2026-04-20 14:14 +0000
Re: MacOS TCP port permissions cross@spitfire.i.gajendra.net (Dan Cross) - 2026-04-20 17:04 +0000
Re: MacOS TCP port permissions boltar@caprica.universe - 2026-04-18 10:36 +0000
Re: MacOS TCP port permissions Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-18 17:54 -0700
Re: MacOS TCP port permissions baltar@caprica.prime - 2026-04-19 09:08 +0000
Re: MacOS TCP port permissions cross@spitfire.i.gajendra.net (Dan Cross) - 2026-04-19 13:29 +0000
Re: MacOS TCP port permissions boltar@caprica.universe - 2026-04-20 09:35 +0000
Re: MacOS TCP port permissions Nuno Silva <nunojsilva@invalid.invalid> - 2026-04-19 10:45 +0100
Re: MacOS TCP port permissions boltar@caprica.universe - 2026-04-20 09:32 +0000
Re: MacOS TCP port permissions Nuno Silva <nunojsilva@invalid.invalid> - 2026-04-20 23:52 +0100
Re: MacOS TCP port permissions boltar@caprica.universe - 2026-04-21 08:27 +0000
Re: MacOS TCP port permissions boltar@caprica.universe - 2026-04-18 10:30 +0000
Re: MacOS TCP port permissions Richard Kettlewell <invalid@invalid.invalid> - 2026-04-17 20:09 +0100
Re: MacOS TCP port permissions boltar@caprica.universe - 2026-04-18 10:32 +0000
Re: MacOS TCP port permissions Richard Kettlewell <invalid@invalid.invalid> - 2026-04-18 13:02 +0100
Re: MacOS TCP port permissions boltar@caprica.universe - 2026-04-18 14:40 +0000
Re: MacOS TCP port permissions kalevi@kolttonen.fi (Kalevi Kolttonen) - 2026-04-18 15:14 +0000
Re: MacOS TCP port permissions boltar@caprica.universe - 2026-04-18 15:29 +0000
Re: MacOS TCP port permissions kalevi@kolttonen.fi (Kalevi Kolttonen) - 2026-04-18 15:52 +0000
Re: MacOS TCP port permissions boltar@caprica.universe - 2026-04-18 15:57 +0000
Re: MacOS TCP port permissions kalevi@kolttonen.fi (Kalevi Kolttonen) - 2026-04-18 15:59 +0000
Re: MacOS TCP port permissions Nuno Silva <nunojsilva@invalid.invalid> - 2026-04-19 00:24 +0100
Re: MacOS TCP port permissions cross@spitfire.i.gajendra.net (Dan Cross) - 2026-04-18 23:53 +0000
Running sshd on another port does have merit - even if in theory it does not (Was: MacOS TCP port permissions) gazelle@shell.xmission.com (Kenny McCormack) - 2026-04-19 16:01 +0000
Re: Running sshd on another port does have merit - even if in theory it does not kalevi@kolttonen.fi (Kalevi Kolttonen) - 2026-04-19 16:28 +0000
Re: MacOS TCP port permissions boltar@caprica.universe - 2026-04-19 09:03 +0000
Re: MacOS TCP port permissions Nuno Silva <nunojsilva@invalid.invalid> - 2026-04-19 10:26 +0100
Re: MacOS TCP port permissions Richard Kettlewell <invalid@invalid.invalid> - 2026-04-18 17:07 +0100
Re: MacOS TCP port permissions Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-04-18 22:36 +0000
Re: MacOS TCP port permissions Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-04-16 23:23 +0000
Re: MacOS TCP port permissions Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-16 16:34 -0700
Re: MacOS TCP port permissions Nuno Silva <nunojsilva@invalid.invalid> - 2026-04-17 01:00 +0100
Re: MacOS TCP port permissions Nicolas George <nicolas$george@salle-s.org> - 2026-04-17 07:12 +0000
Re: MacOS TCP port permissions Richard Kettlewell <invalid@invalid.invalid> - 2026-04-17 08:54 +0100
Re: MacOS TCP port permissions Nicolas George <nicolas$george@salle-s.org> - 2026-04-17 13:49 +0000
Re: MacOS TCP port permissions cross@spitfire.i.gajendra.net (Dan Cross) - 2026-04-17 14:50 +0000
Re: MacOS TCP port permissions Nuno Silva <nunojsilva@invalid.invalid> - 2026-04-18 09:22 +0100
Re: MacOS TCP port permissions scott@slp53.sl.home (Scott Lurndal) - 2026-04-18 15:55 +0000
Re: MacOS TCP port permissions cross@spitfire.i.gajendra.net (Dan Cross) - 2026-04-18 16:09 +0000
Re: MacOS TCP port permissions boltar@caprica.universe - 2026-04-17 10:31 +0000
Re: MacOS TCP port permissions Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-04-17 22:53 +0000
Goodbye, Privileged Ports! [was Re: MacOS TCP port permissions] cross@spitfire.i.gajendra.net (Dan Cross) - 2026-04-17 14:58 +0000
Page 2 of 5 — ← Prev page 1 [2] 3 4 5 Next page →
| From | boltar@caprica.universe |
|---|---|
| Date | 2026-04-18 15:58 +0000 |
| Message-ID | <10s09ml$3an24$1@dont-email.me> |
| In reply to | #17112 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Nuno Silva <nunojsilva@invalid.invalid> |
|---|---|
| Date | 2026-04-19 00:05 +0100 |
| Message-ID | <10s12nk$3itid$4@dont-email.me> |
| In reply to | #17116 |
On 2026-04-18, boltar@caprica.universe wrote: > 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. This is not "UAC" in Windows NT 6.0, not even comparable, if the warning is only shown when there is a reason for it to be: either you're setting it anew, or something changed. It's quite easy to include some note on this in e.g. tutorials people would follow to connect to some organization's ssh services, and that's besides clients themselves often adding a note of some sort. It's not some kind of nagging that makes people automatically dismiss it. -- Nuno Silva
[toc] | [prev] | [next] | [standalone]
| From | Nuno Silva <nunojsilva@invalid.invalid> |
|---|---|
| Date | 2026-04-19 00:01 +0100 |
| Message-ID | <10s12fp$3itid$3@dont-email.me> |
| In reply to | #17093 |
On 2026-04-18, 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. > >>>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. It'd still take a lot of luck to have the code generate the same private key as the one you want to impersonate. (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?) -- Nuno Silva
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-04-18 23:50 +0000 |
| Message-ID | <10s15bq$1fk$1@reader1.panix.com> |
| In reply to | #17123 |
In article <10s12fp$3itid$3@dont-email.me>, Nuno Silva <nunojsilva@invalid.invalid> wrote: >[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?) Oh no; careful: you'll summon P.O. and the gang that's always arguing with him, and this will turn into comp.theory 2.0. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-04-17 19:56 +0000 |
| Message-ID | <egwER.293175$4wI6.219945@fx24.iad> |
| In reply to | #17082 |
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 +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. 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. >*plonk* > >I honestly can't be bothered. Yeah, it's hard for you to coherently argue about topic you seem to know very little about.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-04-17 13:34 -0700 |
| Message-ID | <87tst9s4v4.fsf@kst.eternal-september.org> |
| In reply to | #17085 |
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.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Richard Kettlewell <invalid@invalid.invalid> |
|---|---|
| Date | 2026-04-17 22:53 +0100 |
| Message-ID | <wwvo6jh1cfw.fsf@LkoBDZeT.terraraq.uk> |
| In reply to | #17086 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> 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 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.)
Yes.
> Which means, unless I'm missing something, that the warning about
> a changed host key is not likely to show up.
However things end up with a bogus server running, in the end there’s
just two possibilities: either the client already knows legitimate a
host key for the server, or it doesn’t. In the former case the client
presents its user with a message about the host key changing; in the
latter case it presents its user with the host key hash to confirm. For
example, with OpenSSH:
The authenticity of host 'hostname (192.168.0.1)' can't be established.
ECDSA key fingerprint is SHA256:KkkvOHG9x/ytdyQybQeTepWeTbQ1m3aNH8yFajCMMW4.
Are you sure you want to continue connecting (yes/no/[fingerprint])?
There’s no situation where a session is just established with an unknown
host key and zero user intervention.
> (Unless the system doesn't have an ssh server -- but then how does the
> user get into it?)
We started out talking about Macs, in which case, probably physical
access. But they’re almost all personal systems so the single legitimate
user is the administrator anyway.
Other options are remote desktop, VNC, a serial port, or exploiting an
RCE vulnerability.
> And even if there's no existing ssh server, a non-root sshd would only
> provide access to the user's account.
The attack is that the substitute SSH server simulates a legitimate
session and captures any credentials the end user enters. Success is
most likely if the user uses password authentication (and probably quite
unlikely otherwise, unless the attacker knows a lot about the user’s
expectations).
--
https://www.greenend.org.uk/rjk/
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-04-17 22:56 +0000 |
| Message-ID | <10rudri$19o$1@reader1.panix.com> |
| In reply to | #17086 |
In article <87tst9s4v4.fsf@kst.eternal-september.org>,
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>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?)
The SSH protocol is conceptually layered into two parts: the
"SSH transport protocol", described in RFC4253, is the lower
layer protocol, and authenticates _hosts_ (see section 1 of the
RFC). A side-effect of the host authentication exchange is
the generation of a random ephemeral encryption key suitable for
use with a symmetric cipher.
This type of authentication is based on public key cryptography.
When SSH server software is installed onto a computer, part of
the initial configuration process is generating a public/private
key pair (the "host key") that is used in the host
authentication protocol; the public key is distributed widely,
while the private key is (as the name implies) private to the
server itself. One of the most basic mechanisms for securing
the host private key is ensuring that only the administrator can
read it.
User authentication is described in RFC4252 ("the Secure Shell
Authentication Protocol"). It is intended to be used over a
connection already host-authenticated and encrypted by the SSH
transport protocol.
You are correct that if an SSH server is already running and
bound to the well-known SSH server port (e.g., TCP port 22),
then some other programm cannot bind to that port (even if
running as root).
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 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.
>More plausibly, a non-root user could set up an ftp server.
Potentially they could, though most Unix-y systems store the
user's password hashed using some one-way algorithm that is not
easily invertible, and on top of that, only allow privileged
access to the hashed passwords. So they could set up an
imposter FTP service (who uses the insecure FTP protocol in this
day and age?!) and collect passwords the user enters, but they
could not necessarily validate that those passwords are actually
the user's real password.
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-04-17 16:48 -0700 |
| Message-ID | <87cxzxrvvl.fsf@kst.eternal-september.org> |
| In reply to | #17089 |
cross@spitfire.i.gajendra.net (Dan Cross) writes:
[...]
> 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.
[...]
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-04-18 01:56 +0000 |
| Message-ID | <10ruoc8$5hh$1@reader1.panix.com> |
| In reply to | #17090 |
In article <87cxzxrvvl.fsf@kst.eternal-september.org>, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: >cross@spitfire.i.gajendra.net (Dan Cross) writes: >[...] >> 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. *shrug* People will do all sorts of ill-advised things. You can lead a horse to water, but cannot make it drink. Here's a scenario in which the whole "reserved ports" thing does not help. Consider cases where the `ssh` daemon would not be running. One such case might be when the server is down for maintenance. Here, a malicious actor might put a different machine that they control onto the network, and configure it with the MAC and IP addresses of the target server; they then start whatever ssh daemon they like, as root: which they can do since it's their machine. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | boltar@caprica.universe |
|---|---|
| Date | 2026-04-18 10:39 +0000 |
| Message-ID | <10rvn05$355fj$1@dont-email.me> |
| In reply to | #17089 |
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.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-04-18 15:08 +0000 |
| Message-ID | <10s06oj$74t$2@reader1.panix.com> |
| In reply to | #17097 |
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. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | boltar@caprica.universe |
|---|---|
| Date | 2026-04-18 15:28 +0000 |
| Message-ID | <10s07uq$3a63c$1@dont-email.me> |
| In reply to | #17101 |
On Sat, 18 Apr 2026 15:08:03 -0000 (UTC) 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.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-04-18 15:48 +0000 |
| Message-ID | <10s094m$3vv$2@reader1.panix.com> |
| In reply to | #17104 |
In article <10s07uq$3a63c$1@dont-email.me>, <boltar@caprica.universe> wrote: >On Sat, 18 Apr 2026 15:08:03 -0000 (UTC) >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. 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. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | boltar@caprica.universe |
|---|---|
| Date | 2026-04-18 15:55 +0000 |
| Message-ID | <10s09gt$3al9g$1@dont-email.me> |
| In reply to | #17107 |
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!". >>>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.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-04-18 15:57 +0000 |
| Message-ID | <10s09lm$3vv$4@reader1.panix.com> |
| In reply to | #17111 |
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? >>>>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. I think you don't understand how cryptography works. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | boltar@caprica.universe |
|---|---|
| Date | 2026-04-19 09:00 +0000 |
| Message-ID | <10s25j3$1km5f$1@dont-email.me> |
| In reply to | #17115 |
On Sat, 18 Apr 2026 15:57:42 -0000 (UTC) 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.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-04-19 13:20 +0000 |
| Message-ID | <10s2kqt$a75$1@reader1.panix.com> |
| In reply to | #17129 |
In article <10s25j3$1km5f$1@dont-email.me>, <boltar@caprica.universe> wrote: >On Sat, 18 Apr 2026 15:57:42 -0000 (UTC) >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. And others have pointed out to you how it really isn't. And you cannot resist proving yourself incapable of understanding that. >>>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 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. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | boltar@caprica.universe |
|---|---|
| Date | 2026-04-20 09:34 +0000 |
| Message-ID | <10s4rud$katd$1@dont-email.me> |
| In reply to | #17135 |
On Sun, 19 Apr 2026 13:20:29 -0000 (UTC) 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?
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-04-20 12:42 +0000 |
| Message-ID | <10s56vt$3ui$1@reader1.panix.com> |
| In reply to | #17140 |
In article <10s4rud$katd$1@dont-email.me>, <boltar@caprica.universe> wrote: >On Sun, 19 Apr 2026 13:20:29 -0000 (UTC) >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. Yeah, you just don't understand the counter examples. >>>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? That you don't have the foggiest idea how any of this works. >>>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? You're not worth my time. - Dan C.
[toc] | [prev] | [next] | [standalone]
Page 2 of 5 — ← Prev page 1 [2] 3 4 5 Next page →
Back to top | Article view | comp.unix.programmer
csiph-web