unwanted disconnection web interface when ssh settings private/public key

[Paul042020]

Unless you have some severe restrictions when connecting remotely, I would not expose your SSH directly and just tunnel it through a VPN like OpenVPN or Wireguard and access it locally in that way. With a VPN tunnel, you'd be able to access everything, even your web UI safely as if you're physically at home.

This is also good advice.

I had set up a VPN connection via wireguard, which worked very well to access my smb shares this time.
I can also pass the administration via ssh in this same tunnel?

 

[jgreco]

I can also pass the administration via ssh in this same tunnel?

If it works for SMB, it should work for SSH or webUI.

 

[Paul042020]

Yes, I used to access my shares via Wireguard, but now I've done so much work on my test machine that the vpn connection is no longer operational. I will test as soon as possible.
Forgive my ignorance, I thought ssh was secure because it was encrypted with a private/public key (+ passphrase on the private key on the client side).
I imagine that passing ssh through the VPN is more secure because it adds a layer of encryption. So, if I understand correctly, we have ssh encryption over vpn encryption.
Is SSH alone not secure enough to work without VPN?

 

[Patrick M. Hausen]

I consider SSH with public key authentication (and password authentication globally disabled) as just as secure as a VPN. But that is your judgement, really. We use SSH without VPN to manage about one hundred servers.

 

[Paul042020]

We use SSH without VPN to manage about one hundred servers.

From the outside?

Now that I know I can connect via ssh through the VPN tunnel for my data access, I will do so. In my case it's for administration and not to access my data.

Only if, a potential problem would come from the VPN connection where I would have to plan to connect to the ssh service (with private/public key) :)

 

[Patrick M. Hausen]

From the outside?

Yes, sure. These are hosting servers with no services but SSH for administration. Each of them runs from a handful to a couple of hundred customer jails.

 

[Whattteva]

I consider SSH with public key authentication (and password authentication globally disabled) as just as secure as a VPN. But that is your judgement, really. We use SSH without VPN to manage about one hundred servers.

I totally agree with this. However the average home user installing TrueNAS typically wants to easy access to everything besides just SSH and is the primary reason, so I usually always default to just recommend VPN, which will allow access to everything. I'd imagine this is also the reason why corporations also default to VPN. It's just much more convenient.

 

[Paul042020]

Hello,

I totally agree with this. However the average home user installing TrueNAS typically wants to easy access to everything besides just SSH and is the primary reason, so I usually always default to just recommend VPN, which will allow access to everything. I'd imagine this is also the reason why corporations also default to VPN. It's just much more convenient.

Do you mean that you prefer to advise a non-experienced user to use a VPN to access the data on the NAS because setting up a VPN is easier than setting up ssh?


On my side, I have made some progress. You have convinced me to use a VPN. But I don't like to stay on something I don't understand.
First of all I found a lot of information on this exchange:
https://www.truenas.com/community/t...ng-entry-in-services-ssh-configuration.90893/
First of all the options available in SSH Service > advanced options > Weak Ciphers >

• case "None"
• case "AES-128-CBC"

These two settings are checked by default, which unless I'm mistaken allows the ssh service to use "AES-128-CBC" encryption which is now considered weak and "none", which transmits user data completely unencrypted.
According to the speakers of the post, it would be better to disable them (uncheck). A priori, these options were enabled by default from Truenas 12. The reason why Truenas decided to enable these options remains not really documented.

Another interesting point is that the "none" setting corresponds to "NoneEnabled yes".

I've been looking for a long time to find out what settings (cipher,...) are actually taken into account by ssh on Truenas. I didn't find a command that works directly on Truenas, if you have one, I'm interested.
On the other hand, it is possible to do it from the client by installing the NMAP application (a scanner which allows to provide information about the ports, services, ... of the network)
I found this command on the internet :
nmap -sV -p T:22 --script ssh2-enum-algos <server_ip_>
(Attention the ssh port must be the default port [22])
I think the software is talking to the service in question and asking it what it is able to do.

I have performed some tests:

TEST 1:
SSH Service > advanced options > Weak Ciphers

• case "None" : check
• case "AES-128-CBC" : check
• auxiliary parameter : none

Scan NMAP application (see "encryption _algorithms" section) and sshd_config file :

TEST 2:
SSH Service > advanced options > Weak Ciphers

• case "None" : uncheck
• case "AES-128-CBC" : uncheck
• auxiliary parameter : none

Scan NMAP application (see "encryption _algorithms" section) and sshd_config file :

These two tests show first of all that:
1]"none" is indeed the "NoneEnabled" parameter
2] the encryption algorithms used are :
chacha20-poly1305@openssh.com
aes128-ctr
aes192-ctr
aes256-ctr
aes128-gcm@openssh.com
aes256-gcm@openssh.com

When we run the command "ssh -Q cipher", we can see the algorithms supported by ssh.

root@freenas[~]# ssh -Q cipher
3des-cbc
aes128-cbc
aes192-cbc
aes256-cbc
aes128-ctr
aes192-ctr
aes256-ctr
aes128-gcm@openssh.com
aes256-gcm@openssh.com
chacha20-poly1305@openssh.com
root@freenas[~]#

we can see that the algorithms : 3des-cbc, aes128-cbc, aes192-cbc, and aes256-cbc are not in the algorithms brought out by nmap

=> I do not understand the recommendation given on this page Truenas, which recommends to add the line :
Ciphers chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com

Is it that making explicit the allowed encryption algorithms, therefore prohibits any other encryption? Isn't it already the case?

TEST 3 :
SSH Service > advanced options > Weak Ciphers

• case "None" : check
• case "AES-128-CBC" : unheck
• auxiliary parameter : NoneEnabled no

This last test is very interesting because I checked the "none" option, and I added the reverse parameter "NoneEnabled no" in the auxiliary parameters in ssh service parameter of Truenas.
In the sshd_config file, as you can see in the picture, I have two lines added:

• NoneEnabled yes
• NoneEnabled no

Scan NMAP application (see "encryption _algorithms" section) and sshd_config file :

When we scan with NMAP, we see that "none" is present, so it is the "NoneEnabled yes" parameter that is systematically recognized.

I searched a long time for information about the "NoneEnabled" parameter. It is not found in the OpenSSH documentation.
Finally, I found that this parameter is part of an overlay, a series of performance patch for OpenSSH (HPN-SSH).
https://ixsystems.atlassian.net/browse/NAS-110310

In that documentation, I found a reference to "NoneEnabled" that says:

NoneEnabled=[yes/no] client/server
Enable or disable the use of the None cipher. Care must always be used when enabling this as it will allow users to send data in the clear. However, it is important to note that authentication information remains encrypted even if this option is enabled. Set to no by default.

"NoneEnabled no" seems to be the default value for this parameter. Why on this page of Truenas documentation, it is recommended to add the parameter "NoneEnabled no" in the field "Auxiliary parameters

Either I don't understand everything, which is very likely, or the documentation is not quite right

 

[Patrick M. Hausen]

Do you mean that you prefer to advise a non-experienced user to use a VPN to access the data on the NAS because setting up a VPN is easier than setting up ssh?

Setting up a VPN - preferably via some UI builtin to your Internet router/firewall enables easy access to all services - web UI, file sharing, anything you might run in jails or VMs, ... without even having to know what SSH is. So yes, That's easier to set up if your router supports anything like that. The most popular brand in Germany, "Fritzbox", does. Download VPN client for Windows, couple of clicks, done. Not the most modern IPsec implementation but not catastrophically insecure, either.

SSH access gives you command line an that is that. Now explain to a naive user how to use SSH port forwarding to access shares ... good luck.


Patrick

 

[Whattteva]

Do you mean that you prefer to advise a non-experienced user to use a VPN to access the data on the NAS because setting up a VPN is easier than setting up ssh?

That's actually not at all what I'm saying. Depending on how and where you're setting it up, it could be easier or actually it could be harder. SSH is, for the most part, actually pretty simple to setup. However, here's the difference between SSH and VPN. SSH only allows you to access that one thing, SSH. If you need access to other services, you would have to set them up individually. Well, you could tunnel them over SSH, but that's a lot more involved and complicated, requiring port redirection for each service.

On the other hand, setting up VPN could be more hassle in the beginning, but it opens up access to everything on your LAN as if you were physically actually connected to your home network even though you're not. It allows you to use your private IP's because it admits you to the private network. So, it's basically struggle once, reap all the benefits forever and that's why I favor it.

 

[Paul042020]

On the other hand, setting up VPN could be more hassle in the beginning, but it opens up access to everything on your LAN as if you were physically actually connected to your home network even though you're not. It allows you to use your private IP's because it admits you to the private network. So, it's basically struggle once, reap all the benefits forever and that's why I favor it.

Yes, I understand and I agree with you.

You mentioned that a VPN connection from a box is preferable. My provider and its box does not offer this service, the question does not arise for me.
So I use the wireguard service integrated in Truenas.
But if I had the choice, why would I prefer the VPN of the box rather than Truenas. Is it a question of security?

Thanks to you.

 

[Whattteva]

Yes, I understand and I agree with you.

You mentioned that a VPN connection from a box is preferable. My provider and its box does not offer this service, the question does not arise for me.
So I use the wireguard service integrated in Truenas.
But if I had the choice, why would I prefer the VPN of the box rather than Truenas. Is it a question of security?

Thanks to you.

I think you're replying to someone else. I don't know of this "box" you speak of.

 

[Paul042020]

Sorry, in my country, the "box" is the equipment (modem+router) provided by the Internet Service Provider (ISP)

 

[Whattteva]

Sorry, in my country, the "box" is the equipment (modem+router) provided by the Internet Service Provider (ISP)

Ah I see. I setup my VPN on my router box, which is separate from the modem. My ISP did provide me with one of those all-in-one modem+router combo box which I declined cause they tend to be crap. Instead, I told them to just set it up in bridge mode and I have an old PC running OPNsense as my router. Hell, even my old Asus RT-86U is better than their modem+router thing.

 

[Paul042020]

Hello,
I'm coming back to you because I thought I understood in our previous exchanges that I could have access to the web GUI or SSH in addition to the access to shares.
I have set up a VPN link between the NAS and my PC using Wireguard (integrated into Truenas).
I have good access to my shares. However, I don't see how to make the connection to access SSH or webGUI.
Can you help me?
regards

 

[Patrick M. Hausen]

With the VPN active enter "http://" followed by the IP address of your NAS into the URL field of your browser ...
Type ssh <username>@<ip address of your NAS> at a command prompt to use SSH ...

 

[Paul042020]

Hello and thank you. It's ok, it works.
I don't understand because I had tested the IP address in my browser (but without the https://) before posting the message and it didn't work.
Sincerely