On 3/24/25 05:39, jeremy ardley wrote:

On 24/3/25 12:29, jeremy ardley wrote:

You could use MFA on the SSH connection and then use certificates to
establish the VPN connection?

My SSH MFA setup has clients must connect using a certificate, then
they must enter a pasword, and then they must complete a google
authenticator.

It is possible to configure OpenVPN with MFA such as google
authenticator, but other mechanisms are possible.

I should mention that having an internet facing ssh service is usually a
very bad idea. The 'better' approach is to have only a VPN exposed and
use heavy security on that. Once the VPN link is established you can ssh through the VPN to internal systems.

This is realy the best way forward.

An other MFA alternative is PKI and user/ PWD prompt and optionaly 2FA.

--
John Doe

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, Mar 25, 2025 at 04:22:10PM +0100, Jan Claeys wrote:

On Mon, 2025-03-24 at 12:39 +0800, jeremy ardley wrote:

I should mention that having an internet facing ssh service is
usually a very bad idea. The 'better' approach is to have only a VPN exposed and use heavy security on that. Once the VPN link is
established you can ssh through the VPN to internal systems.

Why do you think SSH is less secure than any other VPN ?

Lack of knowledge, quite probably.

Cheers
--
t

-----BEGIN PGP SIGNATURE-----

iF0EABECAB0WIQRp53liolZD6iXhAoIFyCz1etHaRgUCZ+LRLgAKCRAFyCz1etHa RnUaAJ9tL51cFb9fnquhOXDK+KGg+IEH/QCeNrKhtMIzFpRUH1pnOzEH445B+eY=
=F8l0
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 2025-03-24 at 12:39 +0800, jeremy ardley wrote:

I should mention that having an internet facing ssh service is
usually a very bad idea. The 'better' approach is to have only a VPN
exposed and use heavy security on that. Once the VPN link is
established you can ssh through the VPN to internal systems.

Why do you think SSH is less secure than any other VPN ?


--
Jan Claeys

(please don't CC me when replying to the list)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Jan Claeys (HE12025-03-25):

I should mention that having an internet facing ssh service is
usually a very bad idea. The 'better' approach is to have only a VPN exposed and use heavy security on that. Once the VPN link is
established you can ssh through the VPN to internal systems.

Why do you think SSH is less secure than any other VPN ?

Why do you think Jan says ssh is less secure than a VPN when Jan is
saying that ssh is less secure than VPN+ssh?

I suggest to add port knocking to protect the VPN.

Regards,

--
Nicolas George

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, 2025-03-25 at 17:12 +0100, Nicolas George wrote:

Jan Claeys (HE12025-03-25):

I should mention that having an internet facing ssh service is
usually a very bad idea. The 'better' approach is to have only a
VPN exposed and use heavy security on that. Once the VPN link is established you can ssh through the VPN to internal systems.

Why do you think SSH is less secure than any other VPN ?

Why do you think Jan says ssh is less secure than a VPN when Jan is
saying that ssh is less secure than VPN+ssh?

Jeremy insinuated that, not me, by saying that having SSH listening
publicly is a bad idea, and that “a VPN” listening publicly is somehow safer.

As OpenSSH can be used as a VPN (if you want), a statement like that
makes very little sense, unless SSH would be somehow less secure than
all the other VPN solutions.


--
Jan Claeys

(please don't CC me when replying to the list)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Timothy M Butterworth (HE12025-03-25):

It is not that SSH is less secure, it is that crackers attempt to brute
force SSH servers. If you really want to have SSH open to the internet you may want to hide it behind port knocking.

Let us not exaggerate please. A ssh server publicly available on its
usual port is annoying with the logging noise, but unless you are very constrained in terms of CPU or bandwidth it is not a danger.

Also, all this hinges on the ability to run the port knocking or VPN on
any legitimate client. That is a rather strong condition. If it does not
hold: if your users might not be able to install port knocking software,
not allowed to run VPN clients, or if an annoying firewall is in the
middle, you have no choice but to let a public access.

Regards,

--
Nicolas George

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, Mar 25, 2025 at 01:58:27PM -0400, Timothy M Butterworth wrote:

[...]

It is not that SSH is less secure, it is that crackers attempt to brute
force SSH servers [...]

You still use passwords?

Cheers
--
t

-----BEGIN PGP SIGNATURE-----

iF0EABECAB0WIQRp53liolZD6iXhAoIFyCz1etHaRgUCZ+MWEQAKCRAFyCz1etHa RqgTAJ9/rtKmSFtzTism1tHESdFGtQG6swCfZ7r/3pZIxyMsoXjavA4KYSwchXc=
=msH8
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 2025-03-26 at 04:55 +0800, jeremy ardley wrote:

Out of the box debian has passwords enabled and certificates allowed
but not mandatory.

I can guarantee at least 90% of all debian installations do not have
the defaults changed (let alone any of the other flavours of linux).

Obviously nobody is suggesting that people run an insecure SSH setup.
You should always use keys with SSH, but especially when it’s publicly listening.

This is the precise reason I get dozens of attempts  a minute on my
firewall port 22.

FWIW: at that rate it takes millions of years to guess an even halfway semi-secure 8-character password, let alone the really secure longer
one you _should_ be using.

(But almost all of those attempts only try a small number of very
insecure and/or “default” user/password combinations anyway.)


--
Jan Claeys

(please don't CC me when replying to the list)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, Mar 26, 2025 at 05:21:53AM +0800, jeremy ardley wrote:

On 25/3/25 23:22, Jan Claeys wrote:

On Mon, 2025-03-24 at 12:39 +0800, jeremy ardley wrote:

I should mention that having an internet facing ssh service is
usually a very bad idea. The 'better' approach is to have only a VPN exposed and use heavy security on that. Once the VPN link is
established you can ssh through the VPN to internal systems.

Why do you think SSH is less secure than any other VPN ?

One reason to choose VPN over ssh is that many ISPs block incoming ports including ssh, telnet, RDP,  smtp, and smb ports.

The more extreme ones block outgoing  connections on most of those those ports as well.

I was once sitting at a $(DAYJOB) where they blocked everything but
443 (and 80). I tunneled ssh over socat (with TLS, so that the handshake
didn't look suspect, in case their firewall sniffed that). Bonus: I
got to see whether they did MITM, since I made my own server and
client certs.

Bigcorps are like that. It was not that the firewall department didn't
want to talk to me. It was that they bought a "product" without really understanding how it works.

Cheers
--
t

-----BEGIN PGP SIGNATURE-----

iF0EABECAB0WIQRp53liolZD6iXhAoIFyCz1etHaRgUCZ+OPrQAKCRAFyCz1etHa Rq8CAJ46HB/5lvwnI050zYdskH2S3uuiSQCdH5x5YVrTbcx5jdxcDCVEtnBgNPs=
=sIer
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

jeremy ardley (HE12025-03-26):

One reason to choose VPN over ssh is that many ISPs block incoming ports including ssh, telnet, RDP,� smtp, and smb ports.

And they do not block ports used for VPNs. How convenient.

--
Nicolas George

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, Mar 26, 2025 at 09:41:55AM +0100, Nicolas George wrote:

[email protected] (HE12025-03-26):

I was once sitting at a $(DAYJOB) where they blocked everything but
443 (and 80). I tunneled ssh over socat (with TLS, so that the handshake didn't look suspect, in case their firewall sniffed that). Bonus: I
got to see whether they did MITM, since I made my own server and
client certs.

If behind a BOFH firewall, ssh is usually a lot easier to tunnel to
sneak through than a VPN.

My bet was that 443 is always open because otherwise mid- and hi-
level mgmt would be on top of the poor admins because they couldn't
go to their share trading casinos: I won :)

Bigcorps are like that. It was not that the firewall department didn't
want to talk to me. It was that they bought a "product" without really understanding how it works.

Must not comment. Must not comment.

My goto quote for this is Bruce Schneier's "Security is a process,
not a product" [1]. If, at a company, this earns me empty stares,
I try to not get involved in their security, but rather watch the
fireworks from afar.

Cheers

[1] https://www.schneier.com/essays/archives/2000/04/the_process_of_secur.html --
t

-----BEGIN PGP SIGNATURE-----

iF0EABECAB0WIQRp53liolZD6iXhAoIFyCz1etHaRgUCZ+PC4QAKCRAFyCz1etHa RsHIAJ0XNRDabOjzRVTjSqeqnzzWW08ovACggabMrblchE7I2sPdPF97BpCu1U8=
=QiSQ
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, Mar 26, 2025 at 10:03:36AM CET, [email protected] said:

On Wed, Mar 26, 2025 at 09:41:55AM +0100, Nicolas George wrote:

[email protected] (HE12025-03-26):

I was once sitting at a $(DAYJOB) where they blocked everything but
443 (and 80). I tunneled ssh over socat (with TLS, so that the handshake didn't look suspect, in case their firewall sniffed that). Bonus: I
got to see whether they did MITM, since I made my own server and
client certs.

If behind a BOFH firewall, ssh is usually a lot easier to tunnel to
sneak through than a VPN.

My bet was that 443 is always open because otherwise mid- and hi-
level mgmt would be on top of the poor admins because they couldn't
go to their share trading casinos: I won :)

Admins would also have problems to get security updates (and not accessing *overflow)


--
Erwan David

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 3/26/25 05:04, [email protected] wrote:

On Wed, Mar 26, 2025 at 09:41:55AM +0100, Nicolas George wrote:

[email protected] (HE12025-03-26):

I was once sitting at a $(DAYJOB) where they blocked everything but
443 (and 80). I tunneled ssh over socat (with TLS, so that the handshake >>> didn't look suspect, in case their firewall sniffed that). Bonus: I
got to see whether they did MITM, since I made my own server and
client certs.

If behind a BOFH firewall, ssh is usually a lot easier to tunnel to
sneak through than a VPN.

My bet was that 443 is always open because otherwise mid- and hi-
level mgmt would be on top of the poor admins because they couldn't
go to their share trading casinos: I won :)

Bigcorps are like that. It was not that the firewall department didn't
want to talk to me. It was that they bought a "product" without really
understanding how it works.

Must not comment. Must not comment.

My goto quote for this is Bruce Schneier's "Security is a process,
not a product" [1]. If, at a company, this earns me empty stares,
I try to not get involved in their security, but rather watch the
fireworks from afar.

Like a continent or more away. Such attitudes are contagious. Whoever
said security is a process, not a product, nailed it.

Cheers

[1] https://www.schneier.com/essays/archives/2000/04/the_process_of_secur.html

Cheers, Gene Heskett, CET.
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, Mar 26, 2025 at 11:28:40AM +0100, Erwan David wrote:

[...]

My bet was that 443 is always open because otherwise mid- and hi-
level mgmt would be on top of the poor admins because they couldn't
go to their share trading casinos: I won :)

Admins would also have problems to get security updates (and not accessing *overflow)

They tended to range too low in the food chain to be relevant.

Cheers
--
t

-----BEGIN PGP SIGNATURE-----

iF0EABECAB0WIQRp53liolZD6iXhAoIFyCz1etHaRgUCZ+PctQAKCRAFyCz1etHa RtxAAJ9cefFGizN1azsPSEkEdGr+ACoEOwCfXaSJIboWGfprEi4L8bjMpqXveS8=
=jT7a
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)