Risk level remotely connecting to router webui over http?

[Digilog]

Sorry, you are wrong. Look at your own google search results.

We are not talking about SSH tunnelled through a SSL/TLS connection (which I think is what you're referring to) but a native SSH connection using public/private key authentication (e.g. RSA, ECDSA, etc). FYI Asus routers use dropbear not "Bear Drop".

I'm talking about SSL auth of SSH. Some call this "public key auth"

Using tls/ssh is a different story but that is an outdated method and the public key auth method is the common SSH connection over the internet.

Looks like the author of beardrop SSH admits lack of documentation for public key auth with their software and posted instructions on how to do it:

https://github.com/mkj/dropbear

They dropped the bear when writing their toy SSH software for toy routers. I would just configure the router with the web gui and be done and have the SSH turn off as well as any web facing login.

 

[ColinTaylor]

I'm talking about SSL auth of SSH. Some call this "public key auth"

Looks like the author of beardrop SSH admits lack of documentation for public key auth with their software and posted instructions on how to do it:

https://github.com/mkj/dropbear

Public key auth (e.g. ssh-rsa) is not the same as SSL, that was precisely my point. I can see no reference to SSL in the link you posted.

Your previous google search linked to this (https://www.securew2.com/blog/how-does-ssh-certificate-authentication-work), amongst others which says:

• While SSH certificates secure SSH connections, SSL certificates manage security between web servers and clients.

 

[Digilog]

Public key auth (e.g. ssh-rsa) is not the same as SSL, that was precisely my point. I can see no reference to SSL in the link you posted.

I think you going over semantics. Do you know what software generates a RSA key? And what generates a certificate for SSH.

Needless to say, no one normally use a username/password for SSH over the internet. They use a RSA key.

 

[ColinTaylor]

I think you going over semantics. Do you know what software generates a RSA key? And what generates a certificate for SSH.

Yes I do. Semantics are important. RSA is just an encryption algorithm which can be used by both SSH and SSL/TLS. SSL/TLS certificates have a time component (see your other post) whereas SSH keys do not. They are not the same thing and it is confusing to call an SSH key an "SSL certificate".

N.B. This is all said within the context of typical home routers (the subject of this thread) and not some hosted internet service.

Needless to say, no one normally use a username/password for SSH over the internet. They use a RSA key.

True.

 

[RMerlin]

SSH servers did get hit by a security iussue a few months ago. SSH isn't as secure as VPNs because the protocol is more "open": it can negotiate a wide array of ciphers and key types, it supports various features like tunnelling and compression, and so on. VPNs are more focused, generally set to a very specific cipher and featureset (and these, like compression in OpenVPN, tend to be deprecated these days), and tend to be safer due to this.

 

[Digilog]

SSH servers did get hit by a security iussue a few months ago. SSH isn't as secure as VPNs because the protocol is more "open": it can negotiate a wide array of ciphers and key types, it supports various features like tunnelling and compression, and so on. VPNs are more focused, generally set to a very specific cipher and featureset (and these, like compression in OpenVPN, tend to be deprecated these days), and tend to be safer due to this.

The problem is that there is good and bad ways to connect via SSH and VPN. And the same issues is with VPN when using the same auth mechanism that is vulnerable in SSH.

""An SSH brute force attack is when attackers use the trial and error method to guess login credentials to gain access to the corporate network. ""

same thing happens to a VPN when using Ike Auth

You can't brute force attack Key based auth which is what the OpenVPN uses by default. SSH servers, you have to set this up generally and most, if not all, hosting services use this method when they give SSH access to the Webmaster.

 

[Digilog]

SSH servers did get hit by a security iussue a few months ago.

Its been known for years for both VPN and SSH. That is why by default OpenVPN sets up key based auth instead of user/password via Ike Auth. SSH assumes the user/password method and assumes that the Local IT is going to set up key based auth when using it over the internet. Because SSH was designed for the internal network and is highly recommended, because its the practice, to change the auth mechanism to key base when opening the port up to the internet.

I guess this is the difference between people who went to a real networking school and learned industry practices vs some self taught guy that picks up things or go with the hive mind on a technique without knowing why.

 

[RMerlin]

Brute force weakness has nothing to do with these security vulnerabilities. Key-based authentication was still susceptible to issues such as CVE-2024-6387 or CVE-2023-48795. The latter required a lot of emergency patching for anyone who had an SSH daemon exposed to the naked Internet.

 

[Digilog]

Brute force weakness has nothing to do with these security vulnerabilities. Key-based authentication was still susceptible to issues such as CVE-2024-6387 or CVE-2023-48795. The latter required a lot of emergency patching for anyone who had an SSH daemon exposed to the naked Internet.

What the report doesn't say its part of the old SSH auth schemes. Because key base auth doesn't use the protocals in openssh-ssh1 which is the sub-module that has the vulnerability. Because in key mode there is no wait for client auth and logins are turned off ( openssh-ssh1 is disabled). So when they go to port 22 without presenting their key, they are booted instantly. Of course, I set after 3 failed times the IP is blocked until SSH is rebooted.

Problem with vulneralbility reports, they don't always show eveything including practices adopted.

Just like the CUPS vulneralbility. That only effected a percentage of users. Of course I'm not because I havn't used CUPS since the dot matrix era. Since I use HP printers ever since they started supporting Linux around 20 years ago, I have been using HPLIP instead of CUPS and a lot of Linux users got on the HP printer wagon years ago.