Guaranteeing SSH access to specific clients

[Harold Johanssen]

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.

[David W. Hodgins]

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

[Harold Johanssen]

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?

[David W. Hodgins]

On Thu, 08 Dec 2022 20:20:58 -0500, Harold Johanssen <noe...@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

[Fritz Wuehler]

Harold Johanssen <noem...@please.net> [HJ]:
HJ> Is it possible to guarantee SSH to a specific client, to the
HJ> exclusion of all other clients?

A few ideas that you might want to explore:

Use port knocking
There is even a port knocking server out there that can be
configured to listen on the same port as the SSH server;
after the former is done, it gets out of the way of the latter.
The client must knock on the port (execute an appropriately
configured port knocking client) before connecting.


Use SSH over a VPN
This way the client will always have a fixed IP (ie. that of their
end of the VPN tunnel) and you can apply firewall rules
blocking access to port 22 from all other IPs.


Use 2FA (e.g. TOTP) + SSH
The client visits a web page and is asked for a six digit
number (generated by their TOTP authenticator app).
The web server captures their IP address and unblocks access
to the SSH server from that specific IP for the next X minutes/hours.

[Andreas Kohlbach]

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

[Robert Heller]

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.

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

[Robert Heller]

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

[stepore]

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>

[Carlos E.R.]

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

[26C.Z969]

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
>>> <noe...@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" ....

[Henning Hucke]

Harold Johanssen <noe...@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

[Richard Kettlewell]

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/

[The Natural Philosopher]

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

[The Natural Philosopher]

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

[Allodoxaphobia]

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

[Pancho]

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.

[Harold Johanssen]

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.

[Tauno Voipio]

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

[The Natural Philosopher]

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

[The Natural Philosopher]

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

[Robert Heller]

At Fri, 9 Dec 2022 17:36:33 +0000 The Natural Philosopher <t...@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.

[Harold Johanssen]

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.

[The Natural Philosopher]

On 09/12/2022 19:35, Robert Heller wrote:
> At Fri, 9 Dec 2022 17:36:33 +0000 The Natural Philosopher <t...@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

[The Natural Philosopher]

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

[Robert Heller]

At Sat, 10 Dec 2022 09:53:29 +0000 The Natural Philosopher <t...@invalid.invalid> wrote:

>
> On 09/12/2022 19:35, Robert Heller wrote:
> > At Fri, 9 Dec 2022 17:36:33 +0000 The Natural Philosopher <t...@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¡!

Not necessarily -- if you have console access, you don't. But, yes, initially
you would.

[Pancho]

On 10/12/2022 09:53, The Natural Philosopher wrote:
> On 09/12/2022 19:35, Robert Heller wrote:
>> At Fri, 9 Dec 2022 17:36:33 +0000 The Natural Philosopher
>> <t...@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¡!
>

Not really, cloud installs let you install a key and turn off SSH
password authentication.

[Pancho]

Sorry, it is called cloud-init, not cloud install.

<https://cloudinit.readthedocs.io/en/latest/>

The "Raspberry Pi Imager" uses this, or similar, when it writes an image
to a microSD.

[Robert Heller]

At Sat, 10 Dec 2022 19:25:09 -0500 Andreas Kohlbach <a...@spamfence.net> wrote:

>
> On Sat, 10 Dec 2022 09:53:29 +0000, The Natural Philosopher wrote:
> >
> > On 09/12/2022 19:35, Robert Heller wrote:
> >> At Fri, 9 Dec 2022 17:36:33 +0000 The Natural Philosopher <t...@invalid.invalid> wrote:
> >
> >>> 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.
>

> Not here. Scammers will don't know that password login was disabled and
> go on trying.

But instead of sshd "wasting time" hashing passwords, it just rejects the
attempt early on. (A fail2ban rule could be used to firewall repeated failed
attempts.)

>
> > Problem is you need password to get in to set up the passwordless logins¡!
>
> Or mailing your key to the admin. Of course he has to trust that it's
> really you.

[Carlos E.R.]

On 2022-12-11 01:53, Robert Heller wrote:
> At Sat, 10 Dec 2022 19:25:09 -0500 Andreas Kohlbach <a...@spamfence.net> wrote:
>> On Sat, 10 Dec 2022 09:53:29 +0000, The Natural Philosopher wrote:
>>>
>>> On 09/12/2022 19:35, Robert Heller wrote:
>>>> At Fri, 9 Dec 2022 17:36:33 +0000 The Natural Philosopher <t...@invalid.invalid> wrote:
>>>
>>>>> 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.
>>
>> Not here. Scammers will don't know that password login was disabled and
>> go on trying.
>
> But instead of sshd "wasting time" hashing passwords, it just rejects the
> attempt early on. (A fail2ban rule could be used to firewall repeated failed
> attempts.)

Firewall (iptables?) can do that directly, no need to involve a script.

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

>>
>> Or mailing your key to the admin. Of course he has to trust that it's
>> really you.

Use PGP to mail the key.

--
Cheers, Carlos.

[Robert Heller]

At Sun, 11 Dec 2022 10:37:26 +0100 "Carlos E.R." <robin_...@es.invalid> wrote:

>
> On 2022-12-11 01:53, Robert Heller wrote:
> > At Sat, 10 Dec 2022 19:25:09 -0500 Andreas Kohlbach <a...@spamfence.net> wrote:
> >> On Sat, 10 Dec 2022 09:53:29 +0000, The Natural Philosopher wrote:
> >>>
> >>> On 09/12/2022 19:35, Robert Heller wrote:
> >>>> At Fri, 9 Dec 2022 17:36:33 +0000 The Natural Philosopher <t...@invalid.invalid> wrote:
> >>>
> >>>>> 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.
> >>
> >> Not here. Scammers will don't know that password login was disabled and
> >> go on trying.
> >
> > But instead of sshd "wasting time" hashing passwords, it just rejects the
> > attempt early on. (A fail2ban rule could be used to firewall repeated failed
> > attempts.)
>
> Firewall (iptables?) can do that directly, no need to involve a script.

fail2ban programmably matches the logs to generate firewall rule (eg iptables,
or whatever) for offending IP addresses.

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

> >>
> >> Or mailing your key to the admin. Of course he has to trust that it's
> >> really you.
>
> Use PGP to mail the key.
>

--

[Carlos E.R.]

On 2022-12-11 13:50, Robert Heller wrote:
> At Sun, 11 Dec 2022 10:37:26 +0100 "Carlos E.R." <robin_...@es.invalid> wrote:
>
>>
>> On 2022-12-11 01:53, Robert Heller wrote:
>>> At Sat, 10 Dec 2022 19:25:09 -0500 Andreas Kohlbach <a...@spamfence.net> wrote:
>>>> On Sat, 10 Dec 2022 09:53:29 +0000, The Natural Philosopher wrote:
>>>>>
>>>>> On 09/12/2022 19:35, Robert Heller wrote:
>>>>>> At Fri, 9 Dec 2022 17:36:33 +0000 The Natural Philosopher <t...@invalid.invalid> wrote:
>>>>>
>>>>>>> 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.
>>>>
>>>> Not here. Scammers will don't know that password login was disabled and
>>>> go on trying.
>>>
>>> But instead of sshd "wasting time" hashing passwords, it just rejects the
>>> attempt early on. (A fail2ban rule could be used to firewall repeated failed
>>> attempts.)
>>
>> Firewall (iptables?) can do that directly, no need to involve a script.
>
> fail2ban programmably matches the logs to generate firewall rule (eg iptables,
> or whatever) for offending IP addresses.

Yes, I know. But there are iptables rules can do something similar
without reading or writing files, inside the kernel.

I can not say how to do that directly with iptables, but the old
SuSEfirewall2 thing did it:

# Example:
# Allow max three ssh connects per minute from the same IP address:
# "0/0,tcp,22,,hitcount=3,blockseconds=60,recentname=ssh"

FW_SERVICES_ACCEPT_EXT= that


--
Cheers, Carlos.

[Pancho]

On 11/12/2022 19:55, Carlos E.R. wrote:

>>> Firewall (iptables?) can do that directly, no need to involve a script.
>>
>> fail2ban programmably matches the logs to generate firewall rule (eg
>> iptables,
>> or whatever) for offending IP addresses.
>
> Yes, I know. But there are iptables rules can do something similar
> without reading or writing files, inside the kernel.
>
> I can not say how to do that directly with iptables, but the old
> SuSEfirewall2 thing did it:
>
> # Example:
> #    Allow max three ssh connects per minute from the same IP address:
> #      "0/0,tcp,22,,hitcount=3,blockseconds=60,recentname=ssh"
>
> FW_SERVICES_ACCEPT_EXT= that
>
>

<https://unix.stackexchange.com/questions/26883/how-to-limit-number-off-ssh-login-attempts-per-time-interval>

[Richard Kettlewell]

That will rate-limits all SSH connections. It’s not the same as fail2ban
which blocks source addresses that display malicious activity.

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

[Carlos E. R.]

No, it rate limits only the IPs that attempted 3 connects per minute.
The 0/0 means it checks on all IPs.

--
Cheers,
Carlos E.R.

[Ted Heise]

On Sat, 10 Dec 2022 09:56:16 +0000,

The Natural Philosopher <t...@invalid.invalid> wrote:

> 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

Agreed.

For what it's worth, I did this for many years on my personal home
server (heise.nu) with iptables rules that allowed ssh from only a
few IPs I knew I'd be coming from. I may have used tcpwrappers
too, I think.

Anyway, it was a bit clunky when travelling, or when the IP
address changed for any of my usual connection originating
locations. To update the rules remotely, I'd need to ssh in via
another shell account. This meant doing sudo via that shell
account server, so I suppose the root password would have been
visible to admins of that server. A small risk that I found
acceptable, because I had reasonable trust in those systems and
their staff.

--
Ted Heise <the...@panix.com> West Lafayette, IN, USA