unwanted disconnection web interface when ssh settings private/public key

[Paul042020]

Hello everyone

I have a problem with my user with whom I connect to administer my NAS in ssh.
To connect via ssh, I created a specific user "Toto" for whom I checked the "permit sudo" box and who does not own any dataset and is not part of any group.
Until now, I was using a password and never had any problem, but sometimes I had to switch to the super-user with a "sudo su" for tasks that don't pass with "sudo Toto".
Recently, I wanted to increase security by using an ssh connection with a private/public key.
I created the key pair on the truenas web interface, and copied the public key into the field provided on the "Toto" user profile.
At the moment, when I saved the changes to Toto's profile, I was logged out of the web interface. I could not log in again. However, I could connect via ssh with my user "Toto" and his password.
To regain access to the web interface, I had to restart the server.
I went back to the profile of the user "Toto", the public key had not been saved.
I tried again and it caused exactly the same problem.
After restarting the server, I went back to the profile of the user "Toto", I tried my luck by assigning him a dataset. Bingo, the public key was correctly registered and I was not disconnected from the web interface.
I tried an ssh connection, which seemed to work fine, however, strangely, I had to enter the password of the user "Toto" at the time of the connection.

My questions:
1] Why does ssh login via private/public key require assigning a dataset to the user?
2] Why does it cause a disconnection from the web interface, when I am logged in with root on the web interface.
3] Why does the ssh connection still ask me for the ssh password if the private/public key system is set? Am I missing something? Is the private/public key connection really functional?

Regards

 

[Whattteva]

1] Why does ssh login via private/public key require assigning a dataset to the user?

I'm not 100% sure of this, but I'm guessing because logins require a home directory to store your shell preferences, your ssh public key, etc.
Basically, I don't think it necessarily needs a dataset. More that it needs somewhere to store the user's home directory.

2] Why does it cause a disconnection from the web interface, when I am logged in with root on the web interface.

I've never had this happen to me, but then again I've never tried to create a user that requires login with no home directory. I suspect, this is a side effect of that.

3] Why does the ssh connection still ask me for the ssh password if the private/public key system is set? Am I missing something? Is the private/public key connection really functional?

Yes, it is most definitely functional. The most likely cause is you didn't set it up correctly. Connect to the ssh with -v option to see if your key was even passed through during login or if it got rejected.

 

[danb35]

Why does the ssh connection still ask me for the ssh password if the private/public key system is set? Am I missing something? Is the private/public key connection really functional?

The most common reason for this is improper permissions on the various files in ~/.ssh/, specifically the authorized_keys file, which needs to be readable only by the owner.

 

[Whattteva]

The most common reason for this is improper permissions on the various files in ~/.ssh/, specifically the authorized_keys file, which needs to be readable only by the owner.

This is actually not correct. On my system, authorized_keys permissions are the normal rw-r--r--. The only file that is only owner-readable is id_rsa, which is what is needed on the client only, not the server.

 

[Paul042020]

Hello
I think you are right, the key authentication fails, but I don't know why

PS C:\Users\Peter> ssh toto@192.168.0.55 -v
OpenSSH_for_Windows_8.1p1, LibreSSL 3.0.2
debug1: Connecting to 192.168.0.55 [192.168.0.55]
debug1: Connection established.
debug1: identity file C:\\Users\\Peter/.ssh/id_rsa type -1
debug1: identity file C:\\Users\\Peter/.ssh/id_rsa-cert type -1
debug1: identity file C:\\Users\\Peter/.ssh/id_dsa type -1
debug1: identity file C:\\Users\\Peter/.ssh/id_dsa-cert type -1
debug1: identity file C:\\Users\\Peter/.ssh/id_ecdsa type -1
debug1: identity file C:\\Users\\Peter/.ssh/id_ecdsa-cert type -1
debug1: identity file C:\\Users\\Peter/.ssh/id_ed25519 type -1
debug1: identity file C:\\Users\\Peter/.ssh/id_ed25519-cert type -1
debug1: identity file C:\\Users\\Peter/.ssh/id_xmss type -1
debug1: identity file C:\\Users\\Peter/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_for_Windows_8.1
debug1: Remote protocol version 2.0, remote software version OpenSSH_8.8-hpn14v15
debug1: match: OpenSSH_8.8-hpn14v15 pat OpenSSH* compat 0x04000000
debug1: Authenticating to 192.168.0.55 as 'toto'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:mCCLyjjrGULe7TTHsXYR5hZNKQTP6EJHysaZxoHH
debug1: checking without port identifier
debug1: Host '192.168.0.55' is known and matches the ECDSA host key.
debug1: Found key in C:\\Users\\Peter/.ssh/known_hosts:6
debug1: found matching key w/out port
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey in after 134217728 blocks
debug1: pubkey_prepare: ssh_get_authentication_socket: No such file or directory
debug1: Will attempt key: C:\\Users\\Peter/.ssh/id_rsa
debug1: Will attempt key: C:\\Users\\Peter/.ssh/id_dsa
debug1: Will attempt key: C:\\Users\\Peter/.ssh/id_ecdsa
debug1: Will attempt key: C:\\Users\\Peter/.ssh/id_ed25519
debug1: Will attempt key: C:\\Users\\Peter/.ssh/id_xmss
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,sk-ssh-ed25519@openssh.com,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,sk-ecdsa-sha2-nistp256@openssh.com,webauthn-sk-ecdsa-sha2-nistp256@openssh.com>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: C:\\Users\\Peter/.ssh/id_rsa
debug1: Trying private key: C:\\Users\\Peter/.ssh/id_dsa
debug1: Trying private key: C:\\Users\\Peter/.ssh/id_ecdsa
debug1: Trying private key: C:\\Users\\Peter/.ssh/id_ed25519
debug1: Trying private key: C:\\Users\\Peter/.ssh/id_xmss
debug1: Next authentication method: password
debug1: read_passphrase: can't open /dev/tty: No such file or directory
Toto@192.168.0.55's password:
debug1: Authentication succeeded (password).
Authenticated to 192.168.0.55 ([192.168.0.55]).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: pledge: network
debug1: ENABLE_VIRTUAL_TERMINAL_INPUT is supported. Reading the VTSequence from console
debug1: ENABLE_VIRTUAL_TERMINAL_PROCESSING is supported. Console supports the ansi parsing
debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
Last login: Fri Oct 21 17:22:31 2022 from 192.168.0.74
FreeBSD 13.1-RELEASE-p1 n245406-814eb095751 TRUENAS

TrueNAS (c) 2009-2022, iXsystems, Inc.
All rights reserved.
TrueNAS code is released under the modified BSD license with some
files copyrighted by (c) iXsystems, Inc.

For more information, documentation, help or support, go here:
http://truenas.com
Bienvenue sur TrueNAS
truenas% debug1: client_input_channel_req: channel 0 rtype keepalive@openssh.com reply 1
debug1: client_input_channel_req: channel 0 rtype keepalive@openssh.com reply 1
debug1: client_input_channel_req: channel 0 rtype keepalive@openssh.com reply 1
debug1: client_input_channel_req: channel 0 rtype keepalive@openssh.com reply 1

I think you are right, the key authentication fails, but I don't know why :

debug1: client_input_channel_req: channel 0 rtype keepalive@openssh.com reply 1

 

[Whattteva]

Hello
I think you are right, the key authentication fails, but I don't know why


I think you are right, the key authentication fails, but I don't know why :

What's the permission of your key file (whichever one you're using)? It needs to be -rw------- No one else is supposed to be able to read it.

Also, check /var/log/auth.log on the TrueNAS machine. It could offer a clue as to what might've gone wrong.

 

[Paul042020]

/var/log/auth.log file :

Oct 15 23:14:34 truenas 1 2022-10-15T23:14:34.761436+02:00 truenas.local sshd 94122 - - Unable to negotiate with 192.168.0.55 port 10157: no matching host key type found. Their offer: sk-ecds>Oct 15 23:14:34 truenas 1 2022-10-15T23:14:34.762329+02:00 truenas.local sshd 94123 - - Unable to negotiate with 192.168.1.32 port 61353: no matching host key type found. Their offer: sk-ssh->Oct 15 23:38:39 truenas 1 2022-10-15T23:38:39.858128+02:00 truenas.local sshd 94334 - - Accepted password for toto from 192.168.0.74 port 54956 ssh2
Oct 15 23:50:46 truenas 1 2022-10-15T23:50:46.200014+02:00 truenas.local sshd 94336 - - Received disconnect from 192.168.0.74 port 54956:11: disconnected by user
Oct 15 23:50:46 truenas 1 2022-10-15T23:50:46.200070+02:00 truenas.local sshd 94336 - - Disconnected from user toto 192.168.0.74 port 54956
Oct 16 15:22:21 truenas 1 2022-10-16T15:22:21.962223+02:00 truenas.local sshd 1509 - - Server listening on :: port 22.
Oct 16 15:22:21 truenas 1 2022-10-16T15:22:21.962406+02:00 truenas.local sshd 1509 - - Server listening on 0.0.0.0 port 22.
Oct 16 16:37:28 truenas 1 2022-10-16T16:37:28.846982+02:00 truenas.local sshd 1503 - - Server listening on :: port 22.
Oct 16 16:37:28 truenas 1 2022-10-16T16:37:28.847180+02:00 truenas.local sshd 1503 - - Server listening on 0.0.0.0 port 22.
Oct 16 19:12:42 truenas 1 2022-10-16T19:12:42.916868+02:00 truenas.local shutdown 3976 - - power-down by root:
Oct 16 20:53:24 truenas 1 2022-10-16T20:53:24.356802+02:00 truenas.local sshd 1501 - - Server listening on :: port 22.
Oct 16 20:53:24 truenas 1 2022-10-16T20:53:24.356987+02:00 truenas.local sshd 1501 - - Server listening on 0.0.0.0 port 22.
Oct 16 22:06:31 truenas 1 2022-10-16T22:06:31.828270+02:00 truenas.local sshd 2690 - - Failed password for toto from 192.168.0.74 port 52889 ssh2
Oct 16 22:06:36 truenas 1 2022-10-16T22:06:36.431421+02:00 truenas.local sshd 2690 - - Accepted password for toto from 192.168.0.74 port 52889 ssh2
Oct 16 22:36:04 truenas 1 2022-10-16T22:36:04.144754+02:00 truenas.local sshd 2763 - - Failed password for root from 192.168.0.74 port 53083 ssh2
Oct 16 22:36:21 truenas 1 2022-10-16T22:36:21.250919+02:00 truenas.local sshd 2763 - - Failed password for root from 192.168.0.74 port 53083 ssh2
Oct 16 22:36:23 truenas 1 2022-10-16T22:36:23.809018+02:00 truenas.local sshd 2763 - - Failed password for root from 192.168.0.74 port 53083 ssh2
Oct 16 22:36:24 truenas 1 2022-10-16T22:36:24.484872+02:00 truenas.local sshd 2763 - - Failed password for root from 192.168.0.74 port 53083 ssh2
Oct 16 22:36:26 truenas 1 2022-10-16T22:36:26.096930+02:00 truenas.local sshd 2763 - - error: Received disconnect from 192.168.0.74 port 53083:13: Unable to authenticate [preauth]
Oct 16 22:36:26 truenas 1 2022-10-16T22:36:26.096967+02:00 truenas.local sshd 2763 - - Disconnected from authenticating user root 192.168.0.74 port 53083 [preauth]
Oct 16 22:36:52 truenas 1 2022-10-16T22:36:52.662323+02:00 truenas.local sshd 2765 - - Accepted password for toto from 192.168.0.74 port 53086 ssh2
Oct 17 13:18:41 truenas 1 2022-10-17T13:18:41.747557+02:00 truenas.local sshd 1501 - - Server listening on :: port 22.
Oct 17 13:18:41 truenas 1 2022-10-17T13:18:41.747740+02:00 truenas.local sshd 1501 - - Server listening on 0.0.0.0 port 22.
debug1: client_input_channel_req: channel 0 rtype keepalive@openssh.com reply 1050 - - Accepted password for toto from 192.168.0.74 port 53809 ssh2
debug1: client_input_channel_req: channel 0 rtype keepalive@openssh.com reply 1070 - - Failed password for root from 192.168.0.74 port 53811 ssh2
Oct 17 13:37:12 truenas 1 2022-10-17T13:37:12.067268+02:00 truenas.local sshd 2070 - - fatal: Timeout before authentication for 192.168.0.74 port 53811
Oct 17 13:37:40 truenas 1 2022-10-17T13:37:40.243004+02:00 truenas.local shutdown 2116 - - power-down by root:
Oct 17 13:37:40 truenas 1 2022-10-17T13:37:40.631575+02:00 truenas.local sshd 1501 - - Received signal 15; terminating.
Oct 21 16:47:16 truenas 1 2022-10-21T16:47:16.613027+02:00 truenas.local sshd 1501 - - Server listening on :: port 22.
Oct 21 16:47:16 truenas 1 2022-10-21T16:47:16.613212+02:00 truenas.local sshd 1501 - - Server listening on 0.0.0.0 port 22.
Oct 21 16:55:33 truenas 1 2022-10-21T16:55:33.430295+02:00 truenas.local sshd 1900 - - Connection closed by authenticating user toto 192.168.0.74 port 55189 [preauth]
Oct 21 17:20:54 truenas 1 2022-10-21T17:20:54.508286+02:00 truenas.local sshd 2179 - - Connection reset by authenticating user toto 192.168.0.74 port 55380 [preauth]
Oct 21 17:21:59 truenas 1 2022-10-21T17:21:59.940387+02:00 truenas.local sshd 2181 - - Connection reset by authenticating user toto 192.168.0.74 port 55381 [preauth]
Oct 21 17:22:22 truenas 1 2022-10-21T17:22:22.566370+02:00 truenas.local sshd 2203 - - Connection closed by authenticating user toto 192.168.0.74 port 55385 [preauth]
Oct 21 17:22:31 truenas 1 2022-10-21T17:22:31.012163+02:00 truenas.local sshd 2213 - - Accepted password for toto from 192.168.0.74 port 55386 ssh2
Oct 21 17:24:56 truenas 1 2022-10-21T17:24:56.012994+02:00 truenas.local sshd 2215 - - Received disconnect from 192.168.0.74 port 55386:11: disconnected by user
Oct 21 17:24:56 truenas 1 2022-10-21T17:24:56.013047+02:00 truenas.local sshd 2215 - - Disconnected from user toto 192.168.0.74 port 55386
Oct 21 17:25:07 truenas 1 2022-10-21T17:25:07.212721+02:00 truenas.local sshd 2247 - - Accepted password for toto from 192.168.0.74 port 55395 ssh2
Oct 21 18:26:20 truenas 1 2022-10-21T18:26:20.073993+02:00 truenas.local sshd 2249 - - Received disconnect from 192.168.0.74 port 55395:11: disconnected by user
Oct 21 18:26:20 truenas 1 2022-10-21T18:26:20.074050+02:00 truenas.local sshd 2249 - - Disconnected from user toto 192.168.0.74 port 55395
Oct 21 21:12:07 truenas 1 2022-10-21T21:12:07.091506+02:00 truenas.local login 4831 - - login on pts/0 as root
Oct 21 21:14:54 truenas 1 2022-10-21T21:14:54.034503+02:00 truenas.local sshd 4860 - - Accepted password for toto from 192.168.0.74 port 56147 ssh2
Oct 21 21:15:11 truenas 1 2022-10-21T21:15:11.587642+02:00 truenas.local sshd 4862 - - Received disconnect from 192.168.0.74 port 56147:11: disconnected by user
Oct 21 21:15:11 truenas 1 2022-10-21T21:15:11.587693+02:00 truenas.local sshd 4862 - - Disconnected from user toto 192.168.0.74 port 56147
Oct 21 21:15:24 truenas 1 2022-10-21T21:15:24.975825+02:00 truenas.local sshd 4870 - - Accepted password for toto from 192.168.0.74 port 56148 ssh2

What's the permission of your key file (whichever one you're using)? It needs to be -rw------- No one else is supposed to be able to read it.

sorry how do you do it?

 

[Whattteva]

Actually, you should check if any of these files actually exist first. Usually the one you need is the id_rsa one.

Code:

debug1: Will attempt key: C:\\Users\\Peter/.ssh/id_rsa
debug1: Will attempt key: C:\\Users\\Peter/.ssh/id_dsa
debug1: Will attempt key: C:\\Users\\Peter/.ssh/id_ecdsa
debug1: Will attempt key: C:\\Users\\Peter/.ssh/id_ed25519
debug1: Will attempt key: C:\\Users\\Peter/.ssh/id_xmss

If you can't find any of them, then that's your problem.

 

[Paul042020]

Hello,
I managed to find the problem this week-end. It is indeed on the client side, the ssh-agent service was not activated on my windows
Unfortunately, I still can't connect, I have a second error with the message "Permission denied (publickey)"
After a bit of reading, it seems that this is due to a server-side right problem. What is recommended for the .ssh directory seems to be 700 and the authorized_keys file seems to be 600, but I couldn't find a recommendation for the dataset that hosts the .ssh directory.
In any case with 700 rights, it doesn't work.

@danb35

The most common reason for this is improper permissions on the various files in ~/.ssh/, specifically the authorized_keys file, which needs to be readable only by the owner.

what you say is that 400 is enough for the authorized_keys file ?

 

[Whattteva]

It doesn't work because that isn't the issue. Look at this coming straight from my TrueNAS machine.

Code:

root@nas:~ # ls -ld .ssh
drwxr-xr-x  2 root  wheel  3 Jul 31 01:58 .ssh
root@nas:~ # ls -l .ssh
-rw-r--r--  1 root  wheel  226 Jul 31 01:58 authorized_keys

As you can see, both .ssh directory and authorized_keys have the regular 755 and 644 permissions on my TrueNAS machine and logins work just fine. Those do not need to be owner-readable only. You may notice that I don't have any key file nor any known_hosts file and that's ok because I don't use the TrueNAS box to connect anywhere, so it doesn't need any private keys. It only needs a public key as it only ever functions in the server role.

Now, do you see something similar to this?

Code:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

If you do, it's the key file on your client machine that is too unprotected. If you don't, then either there is a typo in your key file or ssh cannot find your key file at all.

You still haven't answered my question as to which file you are using between all those key files and if the files even exist on your system.
You need to have a file named as those mentioned above with contents similar to this following example for id_rsa:

Code:

-----BEGIN RSA PRIVATE KEY-----
A bunch of gibberish
...
...
...
...
-----END RSA PRIVATE KEY-----

Now THIS particular file DOES need to be owner-readable only as you can see here from my client machine (NOT TrueNAS):

Code:

user@client:~/.ssh$ ls -l id_rsa
-rw------- 1 user user 1000 Oct 26 14:32 id_rsa

As you can see, this one DOES have 600 permission.

 

[Paul042020]

Hello,

I come to give some news.
I managed to connect via the key. I also had a problem with the owner of the dataset where the /.ssh directory is stored.

After solving the problem, here are the permissions I have :

• owner of dataset : rwx --- --- (700)
• directory /.ssh : rwx --- --- (700)
• file "authorized_keys" : rw- --- --- (600)

Thank you for your help

I have two small questions about security items given in the documentation:
On this page https://www.truenas.com/docs/core/coretutorials/services/configuringssh/#service-configuration, it is advised

There are some additional option recommendations for the SSH service: add NoneEnabled no to the Auxiliary Parameters to disable the insecure none cipher.

And
On this page: https://www.truenas.com/docs/solutions/optimizations/security/#ssh
It is advised:

Many SSH ciphers are outdated and vulnerable. It is not safe to enable any weak SSH ciphers. Block both the CBC and Arcfour ciphers by going to Services > SSH > Edit > Advanced Options and adding this line in the Auxiliary Parameters:
Ciphers chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com

Are these two tips complementary or is it either one or the other? If the latter, which option should I choose?


Furthermore, what should be put in the field ?
SSH Service > advanced options > Weak Ciphers >

• check only "None"
• check only "AES-128-CBC"
• check all
• unchek all

(by default, "None" and "AES-128-CBC" are check.)

Regards

 

[Paul042020]

Hello,
I'm coming back to you to know if you have any information about the additional security elements mentioned above?
Regards

 

[Whattteva]

Sorry, I'm not too sure on that. I left mine on default, cause quite frankly, unless you're looking to expose the SSH service to the public internet (I would not recommend it), the default key-based auth should be plenty secure for local SSH access.

 

[jgreco]

Why does ssh login via private/public key require assigning a dataset to the user?

You need somewhere to store the keys. In the UNIX ssh model, that's ${home}/.ssh, and in the TrueNAS model, user homedirs are stored in a ZFS dataset.

Are these two tips complementary or is it either one or the other? If the latter, which option should I choose?

SSH security options are largely a matter of opinion and what you need to be able to interoperate with. The options I use and assign on platforms are unlikely to be suitable to your usage. There are numerous web pages out on the web that explain "securing SSH" in varying levels of detail.

 

[Paul042020]

Hello,

Sorry, I'm not too sure on that. I left mine on default, cause quite frankly, unless you're looking to expose the SSH service to the public internet (I would not recommend it), the default key-based auth should be plenty secure for local SSH access.

No worries. Normally, No, the service should not be exposed to the internet.However, I will be away from home for several months, and if I were to do some very occasional work on the remote nas, I don't want to worry about security at that time. I want it to be simple for my girlfriend who will just have to activate a redirection on the box and deactivate as soon as it's finished.

SSH security options are largely a matter of opinion and what you need to be able to interoperate with. The options I use and assign on platforms are unlikely to be suitable to your usage. There are numerous web pages out on the web that explain "securing SSH" in varying levels of detail.

Yes, I have read pages and pages of them, which I don't necessarily understand. As I'm not an expert (I've already learned a lot from this post), I wanted to stick to what the Truenas documentation advises.
It was while reading these two pages of the doc (given above) that I realized that they were giving two different advices for the same thing.
I wanted your opinion, before possibly pointing out that there was an inconsistency in the doc. Maybe there is a reason.

regards

 

[jgreco]

Yes, I have read pages and pages of them, which I don't necessarily understand. As I'm not an expert (I've already learned a lot from this post), I wanted to stick to what the Truenas documentation advises.

The TrueNAS documentation is not going to be a deep dive into the pros and cons of SSH security. You probably don't want to be using JimBob's 2005 Blog Post on SSH Settings either though.

The basic idea is that there are things that are less secure and there are things that are more secure. You should select a set of things that are more secure to the extent that you don't need the less secure things.

For example, for TrueNAS, the option to use no encryption is exposed. Encryption takes a nontrivial amount of time, and using it can make data transfer operations like replications or rsyncs take a lot of time. Using no encryption can make your NAS replication very fast, but does so at the cost of running your data over the network in plaintext (unencrypted). That's probably okay on your local ethernet, but might suck if you were running the data over the Internet and passing through China and Russia.

 

[Paul042020]

You probably don't want to be using JimBob's 2005 Blog Post on SSH Settings either though.

I'm sorry I didn't understand the reference.

As far as I'm concerned, it's just about administration of the nas. It is not about datas transfer for example a replication on another nas.
On the other hand, I would like this ssh connection to be secure, because I may have to connect remotely from time to time. That's the purpose of the maneuver.
Locally, no, I don't need as much security (home use), especially since most of the time I connect via the GUI.

Typically as mentioned in my post #11, I don't know how to set the option :
SSH Service > advanced options > Weak Ciphers >
case "None"
case "AES-128-CBC"

They are both checked by default, but I am unable to say if it is necessary to leave both boxes checked, or if it is necessary to uncheck one or both (in my case of application).

regards

 

[jgreco]

I would disable both weak ciphers. I don't recall the exact threat model that might exist especially from "None", but if there is a chance that an in-band intruder could trick OpenSSH into negotiating "None", that would be bad.

 

[Whattteva]

On the other hand, I would like this ssh connection to be secure, because I may have to connect remotely from time to time. That's the purpose of the maneuver.
Locally, no, I don't need as much security (home use), especially since most of the time I connect via the GUI.

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.

 

[jgreco]

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.