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

>
> 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¡!

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

>

--
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 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
>> <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¡!
>

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

On 10/12/2022 14:08, Pancho wrote:
> 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
>>> <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¡!
>>
>
> Not really, cloud installs let you install a key and turn off SSH
> password authentication.

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.

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

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

At Sat, 10 Dec 2022 19:25:09 -0500 Andreas Kohlbach <ank@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 <tnp@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.

--
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 2022-12-11 01:53, Robert Heller wrote:
> At Sat, 10 Dec 2022 19:25:09 -0500 Andreas Kohlbach <ank@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 <tnp@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.

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

>
> On 2022-12-11 01:53, Robert Heller wrote:
> > At Sat, 10 Dec 2022 19:25:09 -0500 Andreas Kohlbach <ank@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 <tnp@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.
>

--
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 2022-12-11 13:50, Robert Heller wrote:
> At Sun, 11 Dec 2022 10:37:26 +0100 "Carlos E.R." <robin_listas@es.invalid> wrote:
>
>>
>> On 2022-12-11 01:53, Robert Heller wrote:
>>> At Sat, 10 Dec 2022 19:25:09 -0500 Andreas Kohlbach <ank@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 <tnp@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.

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>

"Carlos E.R." <robin_listas@es.invalid> writes:
> On 2022-12-11 13:50, Robert Heller wrote:
>> 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

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/

On 13/12/2022 09.36, Richard Kettlewell wrote:
> "Carlos E.R." <robin_listas@es.invalid> writes:
>> On 2022-12-11 13:50, Robert Heller wrote:
>>> 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
>
> That will rate-limits all SSH connections. It’s not the same as fail2ban
> which blocks source addresses that display malicious activity.

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.

On Sat, 10 Dec 2022 09:56:16 +0000,
The Natural Philosopher <tnp@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 <theise@panix.com> West Lafayette, IN, USA