TrueNAS Core SSH Cipher

TrueNAS General
1

Hello,
Like to say thank you ahead of time for a resolution.
In the efforts of using the following SSH Cipher aes256-cbc,aes256-ctr,aes192-cbc,aes192-ctr and removing the weak encryption, I noticed that when I stop and start SSHD the old configuration would replace what I had place in to the sshd_config file located /usr/local/etc/ssh so in my infinite wisdom I charrt +i the sshd_config file, well now ssh will not start.

So two questions, does TrueNAS support aes256-cbc,aes256-ctr,aes192-cbc,aes192-ctr and second question is there away to get command line access to chattr -i the file?

Ok was able find the shell plugin, so chattr -i worked, now just remaining is the support question on the Ciphers
Thank You

2

Surely you could do it using the shell through the web GUI? Or at the console?

But to the core of your problem, you shouldn’t be editing anything in /etc/; all of that is managed through the GUI and the middleware. Your options in configuring the SSH service are limited to what’s exposed in the Services → SSH page.

1 Like
3

Thanks Dan,

I was afraid of that, so just for administrative purposes enable SSH. I will alter my policies to reflect this as an as needed basis and to always disable it when done.

Appreciate it!

4

Indeed.

There’s a section named “Auxiliary Parameters” at the bottom. It is here you can specify additional options and risk breaking your system. Lucky you, you’re still on Core. You still have the ability to take a risk with auxiliary parameters galore. :wink:

5

That field is there under SCALE as well. But I’m not sure it can be used to override cipher selections made elsewhere in the config file.

The ciphers that are offered if you disable both options in “weak ciphers” are these:

debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com

Are those that bad?

6

Give it time. Just like Rsync Modules, SMB auxiliary parameters, and NFS auxiliary parameters. :wink:

They’re not “bad”, but the order doesn’t make much sense for non-embedded devices. ChaCha is fast, but AES is even faster with modern Intel/AMD CPUs. In fact, I manually invoke -c aes128-ctr from my client/scripts, so that it doesn’t use ChaCha.

But such a difference would only be seen for large transfers. Simply connecting and running commands over SSH, it doesn’t matter.