I don't know whether this is reasonable possible, but I thought
I'd ask anyway, just in case:

Is it possible to guarantee SSH to a specific client, to the
exclusion of all other clients? In effect, all other connection would be
immediately rejected, even before the SSH protocol exchange gets going.
The following requirements must be met:

- The SSH server must be listening on port 22.
- The target client may connect from different, arbitrary IP
addresses.

This would be easily possible with tweaked SSH servers and
clients, but I am not sure it can be done with off-the-shelf ones.

On Thu, 08 Dec 2022 14:47:14 -0500, Harold Johanssen <noemail@please.net> wrote:

> I don't know whether this is reasonable possible, but I thought
> I'd ask anyway, just in case:
>
> Is it possible to guarantee SSH to a specific client, to the
> exclusion of all other clients? In effect, all other connection would be
> immediately rejected, even before the SSH protocol exchange gets going.
> The following requirements must be met:
>
> - The SSH server must be listening on port 22.
> - The target client may connect from different, arbitrary IP
> addresses.
>
> This would be easily possible with tweaked SSH servers and
> clients, but I am not sure it can be done with off-the-shelf ones.

Excluding all other clients would go against the fact that linux is a multi-user
system, so it's not a standard feature.

killing the sshd server does not kill the working ssh connection(s), so you could
have a script run on login via ssh that kills the sshd server, but you'd have
to also figure out how to restart it after that connection ends (intentionally
or not).

Why do you want to do this? There's probably a better way to lock things when
needed.

Regards, Dave Hodgins

On Thu, 08 Dec 2022 16:31:45 -0500, David W. Hodgins wrote:

> On Thu, 08 Dec 2022 14:47:14 -0500, Harold Johanssen
> <noemail@please.net> wrote:
>
>> I don't know whether this is reasonable possible, but I thought
>> I'd ask anyway, just in case:
>>
>> Is it possible to guarantee SSH to a specific client, to the
>> exclusion of all other clients? In effect, all other connection would
>> be immediately rejected, even before the SSH protocol exchange gets
>> going. The following requirements must be met:
>>
>> - The SSH server must be listening on port 22.
>> - The target client may connect from different, arbitrary IP
>> addresses.
>>
>> This would be easily possible with tweaked SSH servers and
>> clients, but I am not sure it can be done with off-the-shelf ones.
>
> Excluding all other clients would go against the fact that linux is a
> multi-user system, so it's not a standard feature.
>
> killing the sshd server does not kill the working ssh connection(s), so
> you could have a script run on login via ssh that kills the sshd server,
> but you'd have to also figure out how to restart it after that
> connection ends (intentionally or not).
>
> Why do you want to do this? There's probably a better way to lock things
> when needed.
>
> Regards, Dave Hodgins

You misunderstood what I wrote. What I meant is the following:

I want to ssh into a specific system that I control, from
wherever I am in the Internet. Any ssh connections from anybody else into
that system, wherever they are coming from in the Internet, are
automatically rejected - it is not that they are rejected when the wrong
username and password are supplied; rather, their connection requests are
rejected before the ssh protocol gets started. Can this be done, with the
constraints that I specified?

This would be networking-related question: in a nutshell, if the
TCP connection on port 22 is coming from me then it is forwarded to the
ssh daemon; otherwise, it is dropped immediately. The problem is, how
would the TCP code in my server know that the connection is coming me
from me, as opposed to anybody else?

On Thu, 08 Dec 2022 20:20:58 -0500, Harold Johanssen <noemail@please.net> wrote:
> I want to ssh into a specific system that I control, from
> wherever I am in the Internet. Any ssh connections from anybody else into
> that system, wherever they are coming from in the Internet, are
> automatically rejected - it is not that they are rejected when the wrong
> username and password are supplied; rather, their connection requests are
> rejected before the ssh protocol gets started. Can this be done, with the
> constraints that I specified?
>
> This would be networking-related question: in a nutshell, if the
> TCP connection on port 22 is coming from me then it is forwarded to the
> ssh daemon; otherwise, it is dropped immediately. The problem is, how
> would the TCP code in my server know that the connection is coming me
> from me, as opposed to anybody else?

See https://linuxhandbook.com/ssh-disable-password-authentication/
(keep the ssh key on a usb stick for your use), and also add
https://www.howtogeek.com/442733/how-to-use-port-knocking-on-linux-and-why-you-shouldnt/

Never rely on just port knocking.

The only other way I can see it being done is if you know in advance what ip
addresses you'll be connecting from, then add rules to allow it when needed.

Regards, Dave Hodgins

On Thu, 8 Dec 2022 19:47:14 -0000 (UTC), Harold Johanssen wrote:
>
> I don't know whether this is reasonable possible, but I thought
> I'd ask anyway, just in case:
>
> Is it possible to guarantee SSH to a specific client, to the
> exclusion of all other clients? In effect, all other connection would be
> immediately rejected, even before the SSH protocol exchange gets going.
> The following requirements must be met:
>
> - The SSH server must be listening on port 22.
> - The target client may connect from different, arbitrary IP
> addresses.
>
> This would be easily possible with tweaked SSH servers and
> clients, but I am not sure it can be done with off-the-shelf ones.

I can think of several ways.

The sshd_config (probably in /etc/ssh/sshd_config) knows

AllowUsers user1

If this entry exists, only user1 can login.

Then there is

ListenAddress

so SSH will only listen to the IP following.

There is also the good old /etc/hosts.allow and /etc/hosts.deny

In the deny you could add

sshd: ALL

and in the allow only those IP(s) to grant access.

Personally I only use AllowUsers in the /etc/ssh/sshd_config which
works. Thus other users I have on the system cannot access via SSH, even
if provided the correct password.

After altering the config you need to restart the SSH-Server.

Alternatively (or use all of the options if paranoid) there are "host
keys". Users identify with their unique "host key" and don't need to
provide a password. One could even deactivate password auth. Then no user
can log in, even if provided the correct password. Their host key(s) must
match instead.
--
Andreas

If the accepted clients have specific, known IP addresses, then if the server
has a firewall (eg iptables, firewalld, etc.), then firewall rules could be
set up to "reject" (or drop) port 22 packets from non-accepted IP addresses.
No changes to sshd or special settings in /etc/ssh/*config would be needed.

At Thu, 08 Dec 2022 16:31:45 -0500 "David W. Hodgins" <dwhodgins@nomail.afraid.org> wrote:

>
> On Thu, 08 Dec 2022 14:47:14 -0500, Harold Johanssen <noemail@please.net> wrote:
>
> > I don't know whether this is reasonable possible, but I thought
> > I'd ask anyway, just in case:
> >
> > Is it possible to guarantee SSH to a specific client, to the
> > exclusion of all other clients? In effect, all other connection would be
> > immediately rejected, even before the SSH protocol exchange gets going.
> > The following requirements must be met:
> >
> > - The SSH server must be listening on port 22.
> > - The target client may connect from different, arbitrary IP
> > addresses.
> >
> > This would be easily possible with tweaked SSH servers and
> > clients, but I am not sure it can be done with off-the-shelf ones.
>
> Excluding all other clients would go against the fact that linux is a multi-user
> system, so it's not a standard feature.
>
> killing the sshd server does not kill the working ssh connection(s), so you could
> have a script run on login via ssh that kills the sshd server, but you'd have
> to also figure out how to restart it after that connection ends (intentionally
> or not).
>
> Why do you want to do this? There's probably a better way to lock things when
> needed.
>
> Regards, Dave Hodgins
>
>

--
Robert Heller -- Cell: 413-658-7953 GV: 978-633-5364
Deepwoods Software -- Custom Software Services
http://www.deepsoft.com/ -- Linux Administration Services
heller@deepsoft.com -- Webhosting Services

At Fri, 9 Dec 2022 01:20:58 -0000 (UTC) Harold Johanssen <noemail@please.net> wrote:

>
> On Thu, 08 Dec 2022 16:31:45 -0500, David W. Hodgins wrote:
>
> > On Thu, 08 Dec 2022 14:47:14 -0500, Harold Johanssen
> > <noemail@please.net> wrote:
> >
> >> I don't know whether this is reasonable possible, but I thought
> >> I'd ask anyway, just in case:
> >>
> >> Is it possible to guarantee SSH to a specific client, to the
> >> exclusion of all other clients? In effect, all other connection would
> >> be immediately rejected, even before the SSH protocol exchange gets
> >> going. The following requirements must be met:
> >>
> >> - The SSH server must be listening on port 22.
> >> - The target client may connect from different, arbitrary IP
> >> addresses.
> >>
> >> This would be easily possible with tweaked SSH servers and
> >> clients, but I am not sure it can be done with off-the-shelf ones.
> >
> > Excluding all other clients would go against the fact that linux is a
> > multi-user system, so it's not a standard feature.
> >
> > killing the sshd server does not kill the working ssh connection(s), so
> > you could have a script run on login via ssh that kills the sshd server,
> > but you'd have to also figure out how to restart it after that
> > connection ends (intentionally or not).
> >
> > Why do you want to do this? There's probably a better way to lock things
> > when needed.
> >
> > Regards, Dave Hodgins
>
> You misunderstood what I wrote. What I meant is the following:
>
> I want to ssh into a specific system that I control, from
> wherever I am in the Internet. Any ssh connections from anybody else into
> that system, wherever they are coming from in the Internet, are
> automatically rejected - it is not that they are rejected when the wrong
> username and password are supplied; rather, their connection requests are
> rejected before the ssh protocol gets started. Can this be done, with the
> constraints that I specified?
>
> This would be networking-related question: in a nutshell, if the
> TCP connection on port 22 is coming from me then it is forwarded to the
> ssh daemon; otherwise, it is dropped immediately. The problem is, how
> would the TCP code in my server know that the connection is coming me
> from me, as opposed to anybody else?

Only the SSH server can know it is from you. You could disable password
authenific ation and force RSA public/private key authentification -- this
will kill brute-force password attacks (or actually make them ineffective and
avoid wasting time hashing "guessed" passwords). That is the best you can do.
The only check possible IS the SSH authentification process. Since you might
be connecting from "anywhere", IP-level firewalling won't work. At the initial
connection level there is no "knowledge" as to who is connecting. The sshd
process uses its authentification exchange process to determing "who" is
connecting and if they are really who they say they are (eg username [who] and
password/keys/etc. authentificate the connection).

>
>
>

--
Robert Heller -- Cell: 413-658-7953 GV: 978-633-5364
Deepwoods Software -- Custom Software Services
http://www.deepsoft.com/ -- Linux Administration Services
heller@deepsoft.com -- Webhosting Services

On 12/8/22 17:20, Harold Johanssen wrote:

> This would be networking-related question: in a nutshell, if the
> TCP connection on port 22 is coming from me then it is forwarded to the
> ssh daemon; otherwise, it is dropped immediately. The problem is, how
> would the TCP code in my server know that the connection is coming me
> from me, as opposed to anybody else?

This has nothing at all to do with ssh.

It's possible with iptables but you'd had to know your IP in advance.

Can also be done with TCPwrappers.
/etc/hosts.allow
/etc/hosts.deny

<https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/security_guide/sect-security_guide-tcp_wrappers_and_xinetd-tcp_wrappers_configuration_files>

On 2022-12-09 02:20, Harold Johanssen wrote:
> On Thu, 08 Dec 2022 16:31:45 -0500, David W. Hodgins wrote:
>
>> On Thu, 08 Dec 2022 14:47:14 -0500, Harold Johanssen
>> <noemail@please.net> wrote:

....

> You misunderstood what I wrote. What I meant is the following:
>
> I want to ssh into a specific system that I control, from
> wherever I am in the Internet. Any ssh connections from anybody else into
> that system, wherever they are coming from in the Internet, are
> automatically rejected - it is not that they are rejected when the wrong
> username and password are supplied; rather, their connection requests are
> rejected before the ssh protocol gets started. Can this be done, with the
> constraints that I specified?

No, unless you know how the server is going to know that it is you
calling before hearing your name...

You first answer this, and then we find how the program does that.

Like for example, you know in advance what IP the client is going to have.

Or the client triggers some events before hand. Say, knocking on some
port sequence.

In the end, people do two things:

- make the server listen to a high port instead
- make the server not respond to login/password, but to a public key
challenge.

You may add other things.

--
Cheers, Carlos.

On 12/8/22 10:42 PM, Carlos E.R. wrote:
> On 2022-12-09 02:20, Harold Johanssen wrote:
>> On Thu, 08 Dec 2022 16:31:45 -0500, David W. Hodgins wrote:
>>
>>> On Thu, 08 Dec 2022 14:47:14 -0500, Harold Johanssen
>>> <noemail@please.net> wrote:
>
> ...
>
>>     You misunderstood what I wrote. What I meant is the following:
>>
>>     I want to ssh into a specific system that I control, from
>> wherever I am in the Internet. Any ssh connections from anybody else into
>> that system, wherever they are coming from in the Internet, are
>> automatically rejected - it is not that they are rejected when the wrong
>> username and password are supplied; rather, their connection requests are
>> rejected before the ssh protocol gets started. Can this be done, with the
>> constraints that I specified?
>
> No, unless you know how the server is going to know that it is you
> calling before hearing your name...

Agreed. SSH - or any other connection system - starts
assuming that all users are equal.

Now there IS the olde-tyme trick called "port knocking"
and there's software to implement that. Those who do not
"knock" correctly don't get in. It's a bit cludgy, but
it IS very secure.

Frankly, decent passwords combined with low tolerance
for brute-force methods like trying 999 times a second
from the same IP address are often Good Enough.

Alas for a big commercial/govt system ... you just can't
DO that. THEY have to bias towards high-volume traffic and
idiot users and thus lose a lot of options when it comes
to rejecting Bad Actors.

Ain't nothin' "perfect" ....

Harold Johanssen <noemail@please.net> wrote:

Hello Harold,

> [...]
> This would be networking-related question: in a nutshell, if the
> TCP connection on port 22 is coming from me then it is forwarded to the
> ssh daemon; otherwise, it is dropped immediately. The problem is, how
> would the TCP code in my server know that the connection is coming me
> from me, as opposed to anybody else?

strange thinking: Don't communicate ("before the SSH protocol is
started") but recognise me from whichever IP address I might come...

For the case that you still didn't get over to us what you really want
to accomplish you might look into the "tcp wrapper" which is still
linked into the ssh daemon.
But from what I understand about your concern I would recommend a port
knocking mechanism. Hint: Don't use "knockd" for diverse reasons as long
as the system(s) in question already has netfilter tables since this
firewall code is able to implement port knocking totally and very
flexible as a ruleset system.

Best regards,
Henning
--
Honesty is for the most part less profitable than dishonesty.
-- Plato

Harold Johanssen <noemail@please.net> writes:
> I don't know whether this is reasonable possible, but I thought
> I'd ask anyway, just in case:
>
> Is it possible to guarantee SSH to a specific client, to the
> exclusion of all other clients? In effect, all other connection would be
> immediately rejected, even before the SSH protocol exchange gets going.
> The following requirements must be met:
>
> - The SSH server must be listening on port 22.
> - The target client may connect from different, arbitrary IP
> addresses.
>
> This would be easily possible with tweaked SSH servers and
> clients, but I am not sure it can be done with off-the-shelf ones.

AIUI you want to avoid exposing the SSH session setup implementation to
anything but your chosen clients, for some reason that you’ve not
stated. (Perhaps explaining the motivation would help.)

To do that you need a reasonably secure way to identify your chosen
clients. A VPN could do the job, but now you’re exposing the VPN’s
session setup code to the entire Internet instead of the SSH equivalent.

Unless you have a reason to believe that the VPN is better than SSH, in
whatever way it is you care about, you’ve not gained anything - you’ve
just added complexity to your system.

--
http://www.greenend.org.uk/rjk/

On 08/12/2022 19:47, Harold Johanssen wrote:
> I don't know whether this is reasonable possible, but I thought
> I'd ask anyway, just in case:
>
> Is it possible to guarantee SSH to a specific client, to the
> exclusion of all other clients? In effect, all other connection would be
> immediately rejected, even before the SSH protocol exchange gets going.
> The following requirements must be met:
>
> - The SSH server must be listening on port 22.
> - The target client may connect from different, arbitrary IP
> addresses.
>
> This would be easily possible with tweaked SSH servers and
> clients, but I am not sure it can be done with off-the-shelf ones.
think about this for a moment.
To connect, a packet with source port and IP musts connect to
destination port 22 at IP address of server.

In order for this all to work at all, the only variable you can use to
identify 'legal' traffic at the TCP level is the source port.

At that level a simple firewall rule that rejected all connections other
than those from a specific source port would do what you want.

How to ensure your application only used that port is somewhat trickier,
especially if its behind NAṪ

So its possible, but non trivial

--
“Puritanism: The haunting fear that someone, somewhere, may be happy.”

H.L. Mencken, A Mencken Chrestomathy

On 09/12/2022 01:20, Harold Johanssen wrote:
> On Thu, 08 Dec 2022 16:31:45 -0500, David W. Hodgins wrote:
>
>> On Thu, 08 Dec 2022 14:47:14 -0500, Harold Johanssen
>> <noemail@please.net> wrote:
>>
>>> I don't know whether this is reasonable possible, but I thought
>>> I'd ask anyway, just in case:
>>>
>>> Is it possible to guarantee SSH to a specific client, to the
>>> exclusion of all other clients? In effect, all other connection would
>>> be immediately rejected, even before the SSH protocol exchange gets
>>> going. The following requirements must be met:
>>>
>>> - The SSH server must be listening on port 22.
>>> - The target client may connect from different, arbitrary IP
>>> addresses.
>>>
>>> This would be easily possible with tweaked SSH servers and
>>> clients, but I am not sure it can be done with off-the-shelf ones.
>>
>> Excluding all other clients would go against the fact that linux is a
>> multi-user system, so it's not a standard feature.
>>
>> killing the sshd server does not kill the working ssh connection(s), so
>> you could have a script run on login via ssh that kills the sshd server,
>> but you'd have to also figure out how to restart it after that
>> connection ends (intentionally or not).
>>
>> Why do you want to do this? There's probably a better way to lock things
>> when needed.
>>
>> Regards, Dave Hodgins
>
> You misunderstood what I wrote. What I meant is the following:
>
> I want to ssh into a specific system that I control, from
> wherever I am in the Internet. Any ssh connections from anybody else into
> that system, wherever they are coming from in the Internet, are
> automatically rejected - it is not that they are rejected when the wrong
> username and password are supplied; rather, their connection requests are
> rejected before the ssh protocol gets started. Can this be done, with the
> constraints that I specified?

I use a random sshd high port for this.
Ok if someone port scans they might find it. But script kiddies are not
so good as that.

>
> This would be networking-related question: in a nutshell, if the
> TCP connection on port 22 is coming from me then it is forwarded to the
> ssh daemon; otherwise, it is dropped immediately. The problem is, how
> would the TCP code in my server know that the connection is coming me
> from me, as opposed to anybody else?
>
As I said, either because it isn't on 22 at all, or because you ate
using an identifiable source port

--
"The most difficult subjects can be explained to the most slow witted
man if he has not formed any idea of them already; but the simplest
thing cannot be made clear to the most intelligent man if he is firmly
persuaded that he knows already, without a shadow of doubt, what is laid
before him."

- Leo Tolstoy

On Fri, 9 Dec 2022 01:20:58 -0000 (UTC), Harold Johanssen wrote:
> On Thu, 08 Dec 2022 16:31:45 -0500, David W. Hodgins wrote:
>> On Thu, 08 Dec 2022 14:47:14 -0500, Harold Johanssen
>> <noemail@please.net> wrote:
>>
>>> I don't know whether this is reasonable possible, but I thought
>>> I'd ask anyway, just in case:
>>>
>>> Is it possible to guarantee SSH to a specific client, to the
>>> exclusion of all other clients? In effect, all other connection would
>>> be immediately rejected, even before the SSH protocol exchange gets
>>> going. The following requirements must be met:
>>>
>>> - The SSH server must be listening on port 22.
>>> - The target client may connect from different, arbitrary IP
>>> addresses.
>>>
>>> This would be easily possible with tweaked SSH servers and
>>> clients, but I am not sure it can be done with off-the-shelf ones.
>>
>> Excluding all other clients would go against the fact that linux is a
>> multi-user system, so it's not a standard feature.
>>
>> killing the sshd server does not kill the working ssh connection(s), so
>> you could have a script run on login via ssh that kills the sshd server,
>> but you'd have to also figure out how to restart it after that
>> connection ends (intentionally or not).
>>
>> Why do you want to do this? There's probably a better way to lock things
>> when needed.
>>
>> Regards, Dave Hodgins
>
> You misunderstood what I wrote. What I meant is the following:
>
> I want to ssh into a specific system that I control, from
> wherever I am in the Internet. Any ssh connections from anybody else into
> that system, wherever they are coming from in the Internet, are
> automatically rejected - it is not that they are rejected when the wrong
> username and password are supplied; rather, their connection requests are
> rejected before the ssh protocol gets started. Can this be done, with the
> constraints that I specified?

For crying out loud!
Simply use public-private keys _only_
between the one client (you) and the ssh server.

On 09/12/2022 13:55, Allodoxaphobia wrote:

>> I want to ssh into a specific system that I control, from
>> wherever I am in the Internet. Any ssh connections from anybody else into
>> that system, wherever they are coming from in the Internet, are
>> automatically rejected - it is not that they are rejected when the wrong
>> username and password are supplied; rather, their connection requests are
>> rejected before the ssh protocol gets started. Can this be done, with the
>> constraints that I specified?
>
> For crying out loud!
> Simply use public-private keys _only_
> between the one client (you) and the ssh server.

Yeah, I don't think I understand the question, because I just use
..ssh/authorised_keys. It seemed registering the specific client public
key in .ssh/authorised_keys and turning off ssh password authentication
would do the trick.

On Thu, 8 Dec 2022 19:47:14 -0000 (UTC), Harold Johanssen wrote:

> I don't know whether this is reasonable possible, but I thought I'd ask
> anyway, just in case:
>
> Is it possible to guarantee SSH to a specific client, to the
> exclusion of all other clients? In effect, all other connection would be
> immediately rejected, even before the SSH protocol exchange gets going.
> The following requirements must be met:
>
> - The SSH server must be listening on port 22.
> - The target client may connect from different, arbitrary IP
> addresses.
>
> This would be easily possible with tweaked SSH servers and
> clients, but I am not sure it can be done with off-the-shelf ones.

Thank everybody for your suggestion. Here's what I am going to do:

Since I am talking about a particular Linux SSH server that I
fully control, and a particular Linux SSH client that I also fully
control, I am going to make use of the SSH identification string. Since
this string contemplates an optional field where one can put anything
(with the constraints mentioned in the relevant RFC) I will use the
contents of that string to filter out incoming connections.

Initially I will use some arbitrary, fixed string - the changes
to the SSH client and server codes to support this are trivial. Later on
I could use a OTP-like scheme, which would not be much more difficult to
pull off. Either way, my server will reject pests before the SSH protocol
exchange gets going (which is elaborate and computationally intensive)
and my client will still work with standard SSH servers. I'll have to
maintain that code, but that will be a nice entertainment.

On 9.12.2022 16.48, Harold Johanssen wrote:
> On Thu, 8 Dec 2022 19:47:14 -0000 (UTC), Harold Johanssen wrote:
>
>> I don't know whether this is reasonable possible, but I thought I'd ask
>> anyway, just in case:
>>
>> Is it possible to guarantee SSH to a specific client, to the
>> exclusion of all other clients? In effect, all other connection would be
>> immediately rejected, even before the SSH protocol exchange gets going.
>> The following requirements must be met:
>>
>> - The SSH server must be listening on port 22.
>> - The target client may connect from different, arbitrary IP
>> addresses.
>>
>> This would be easily possible with tweaked SSH servers and
>> clients, but I am not sure it can be done with off-the-shelf ones.
>
> Thank everybody for your suggestion. Here's what I am going to do:
>
> Since I am talking about a particular Linux SSH server that I
> fully control, and a particular Linux SSH client that I also fully
> control, I am going to make use of the SSH identification string. Since
> this string contemplates an optional field where one can put anything
> (with the constraints mentioned in the relevant RFC) I will use the
> contents of that string to filter out incoming connections.
>
> Initially I will use some arbitrary, fixed string - the changes
> to the SSH client and server codes to support this are trivial. Later on
> I could use a OTP-like scheme, which would not be much more difficult to
> pull off. Either way, my server will reject pests before the SSH protocol
> exchange gets going (which is elaborate and computationally intensive)
> and my client will still work with standard SSH servers. I'll have to
> maintain that code, but that will be a nice entertainment.

There is a such mechanism already in SSH. Google for
'passswordless ssh login'. The generated cryptographic
keys are far more secure than an invented string.

--

-TV

On 09/12/2022 15:42, Tauno Voipio wrote:
>
> There is a such mechanism already in SSH. Google for
> 'passswordless ssh login'. The generated cryptographic
> keys are far more secure than an invented string.

This is the best way except it does allow for a lot of random traffic
hitting port 22 and trying to find a way in.
Using obscure ports helps with this

--
“It is hard to imagine a more stupid decision or more dangerous way of
making decisions than by putting those decisions in the hands of people
who pay no price for being wrong.”

Thomas Sowell

On Fri, 09 Dec 2022 03:34:32 +0000, Robert Heller wrote:
>
> If the accepted clients have specific, known IP addresses, then if the server
> has a firewall (eg iptables, firewalld, etc.), then firewall rules could be
> set up to "reject" (or drop) port 22 packets from non-accepted IP addresses.
> No changes to sshd or special settings in /etc/ssh/*config would be needed.

SSH has options itself to deal with traffic.

As long as a server can deal with these things I refrained from using a
package filter.

Example SMB. I set up

bind interfaces only = Yes

and

interfaces = 127.0.0.0/8 eth0

to only allow localhost and what comes over Ethernet (my other computer).
--
Andreas

On 09/12/2022 17:44, Andreas Kohlbach wrote:
> On Fri, 09 Dec 2022 03:34:32 +0000, Robert Heller wrote:
>>
>> If the accepted clients have specific, known IP addresses, then if the server
>> has a firewall (eg iptables, firewalld, etc.), then firewall rules could be
>> set up to "reject" (or drop) port 22 packets from non-accepted IP addresses.
>> No changes to sshd or special settings in /etc/ssh/*config would be needed.
>
> SSH has options itself to deal with traffic.
>
> As long as a server can deal with these things I refrained from using a
> package filter.
>
> Example SMB. I set up
>
> bind interfaces only = Yes
>
> and
>
> interfaces = 127.0.0.0/8 eth0
>
> to only allow localhost and what comes over Ethernet (my other computer).

Won't solve OPs problem since the IP address of the source is neither
constant nor known in advance.

--
Socialism is the philosophy of failure, the creed of ignorance and the
gospel of envy.

Its inherent virtue is the equal sharing of misery.

Winston Churchill

At Fri, 9 Dec 2022 17:36:33 +0000 The Natural Philosopher <tnp@invalid.invalid> wrote:

>
> On 09/12/2022 15:42, Tauno Voipio wrote:
> >
> > There is a such mechanism already in SSH. Google for
> > 'passswordless ssh login'. The generated cryptographic
> > keys are far more secure than an invented string.
>
> This is the best way except it does allow for a lot of random traffic
> hitting port 22 and trying to find a way in.
> Using obscure ports helps with this

Not really, but disabling passsword login greatly cuts down the brute force
attempts.

>
>

--
Robert Heller -- Cell: 413-658-7953 GV: 978-633-5364
Deepwoods Software -- Custom Software Services
http://www.deepsoft.com/ -- Linux Administration Services
heller@deepsoft.com -- Webhosting Services

On Fri, 9 Dec 2022 17:42:05 +0200, Tauno Voipio wrote:

> On 9.12.2022 16.48, Harold Johanssen wrote:
>> On Thu, 8 Dec 2022 19:47:14 -0000 (UTC), Harold Johanssen wrote:
>>
>>> I don't know whether this is reasonable possible, but I thought I'd
>>> ask anyway, just in case:
>>>
>>> Is it possible to guarantee SSH to a specific client, to the
>>> exclusion of all other clients? In effect, all other connection would
>>> be immediately rejected, even before the SSH protocol exchange gets
>>> going. The following requirements must be met:
>>>
>>> - The SSH server must be listening on port 22.
>>> - The target client may connect from different, arbitrary IP
>>> addresses.
>>>
>>> This would be easily possible with tweaked SSH servers and
>>> clients, but I am not sure it can be done with off-the-shelf ones.
>>
>> Thank everybody for your suggestion. Here's what I am going to do:
>>
>> Since I am talking about a particular Linux SSH server that I
>> fully control, and a particular Linux SSH client that I also fully
>> control, I am going to make use of the SSH identification string. Since
>> this string contemplates an optional field where one can put anything
>> (with the constraints mentioned in the relevant RFC) I will use the
>> contents of that string to filter out incoming connections.
>>
>> Initially I will use some arbitrary, fixed string - the changes
>> to the SSH client and server codes to support this are trivial. Later
>> on I could use a OTP-like scheme, which would not be much more
>> difficult to pull off. Either way, my server will reject pests before
>> the SSH protocol exchange gets going (which is elaborate and
>> computationally intensive) and my client will still work with standard
>> SSH servers. I'll have to maintain that code, but that will be a nice
>> entertainment.
>
> There is a such mechanism already in SSH. Google for 'passswordless ssh
> login'. The generated cryptographic keys are far more secure than an
> invented string.

That does not prevent the computationally expensive secure
channel establishment exchanges from taking place, for the authentication
mechanisms exchange phase happens after the secure channel has been
created.

Notice what I want to do does not replace the authentication
mechanisms already in place in the ssh protocol - I am just aiming to
slam the door on intruders as early in the connection as possible. Once a
connection is accepted by virtue of the mechanism described above, the
rest is pure ssh.

On 09/12/2022 19:35, Robert Heller wrote:
> At Fri, 9 Dec 2022 17:36:33 +0000 The Natural Philosopher <tnp@invalid.invalid> wrote:
>
>>
>> On 09/12/2022 15:42, Tauno Voipio wrote:
>>>
>>> There is a such mechanism already in SSH. Google for
>>> 'passswordless ssh login'. The generated cryptographic
>>> keys are far more secure than an invented string.
>>
>> This is the best way except it does allow for a lot of random traffic
>> hitting port 22 and trying to find a way in.
>> Using obscure ports helps with this
>
> Not really, but disabling passsword login greatly cuts down the brute force
> attempts.
>
Does it? Cant say I noticed.

Problem is you need password to get in to set up the passwordless logins¡!

--
In a Time of Universal Deceit, Telling the Truth Is a Revolutionary Act.

- George Orwell

On 09/12/2022 22:03, Harold Johanssen wrote:
> Notice what I want to do does not replace the authentication
> mechanisms already in place in the ssh protocol - I am just aiming to
> slam the door on intruders as early in the connection as possible. Once a
> connection is accepted by virtue of the mechanism described above, the
> rest is pure ssh.

Then the only criteria available are the source port and IP address.
So its either port knocking to open a hole, or its using a guaranteed
source port, since the source IP address cannot be guaranteed.

There are no other options

--
In a Time of Universal Deceit, Telling the Truth Is a Revolutionary Act.

- George Orwell