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