I don’t think you have a current ssh session. Isn’t that run just asking the client for its configuration? Attempting to find an easy way to determine what the sshd uses led me first to a remote query way:
Listing host’s available ssh ciphers from client
ssh -vv -p 12345 184.82.24.166
debug2: peer server KEXINIT proposal
...
debug2: host key algorithms: rsa-sha2-512,rsa-sha2-256,ecdsa-sha2-nistp256
so there’s that lost ssh-ed25519 again. I’m not seeing security hate for it, in fact I even found:
It’s 2023. You Should Be Using an Ed25519 SSH Key (And Other Current Best Practices)
Can Asustor be safely downgraded to see if it was there before? If so, that supports the theory.
Possibly it’s still a little premature, but it seems fair to ask Asustor why the algorithm isn’t there.
From your ssh client testing, it appears to be on the system – except not in their shipped sshd.
There are defaults. We’re probably seeing them. The referenced sshd_config man page says.
Ciphers
Specifies the ciphers allowed. Multiple ciphers must be comma-separated. If the specified list begins with a ‘+’ character, then the specified ciphers will be appended
to the default set instead of replacing them.
This plus method of querying the sshd should be enough to let you see if you can get lost cipher.
I’m not sure what the risk is if sshd breaks (and how to fix it), but your backups are already down.
OpenSSH Manual Pages links docs. I don’t know if Asustor is systemd-based. You could ps test.
sshd page says -E can log to a log_file, but I’m not sure how you’d configure that into Asustor.
EDIT 1:
Although we might trip over other settings later, the relevant setting to start with might be this one:
HostKeyAlgorithms
Specifies the host key signature algorithms that the server offers
and on the client side if one wants to drive the sshd in a certain way, the setting might be this one:
HostKeyAlgorithms
Specifies the host key signature algorithms that the client wants to use in order of preference. Alternately if the specified list begins with a ‘+’ character, then the specified signature algorithms will be appended to the default set instead of replacing them.
EDIT 2:
I notice that the client man page says:
The list of available signature algorithms may also be obtained using “ssh -Q HostKeyAlgorithms”.
which is sort of puzzling. I don’t think it can reach into an un-named connection or remote sshd, but maybe it can speak for the sshd on its own system. I don’t think you said what system you were on.
EDIT 3:
Because I don’t have an Asustor to try to fix, I tried breaking Manjaro using the following config line:
HostKeyAlgorithms rsa-sha2-512,rsa-sha2-256,ecdsa-sha2-nistp256
and got its ssh to match Duplicati’s limited-by-what-mono-can-provide configuration using config line:
HostKeyAlgorithms ssh-ed25519,ssh-rsa,ssh-dss
systemctl restart sshd (known to not work on Asustor – it reportedly uses a different restart way).
$ ssh -vv 127.0.0.1
OpenSSH_9.5p1, OpenSSL 3.1.4 24 Oct 2023
...
debug1: Local version string SSH-2.0-OpenSSH_9.5
debug1: Remote protocol version 2.0, remote software version OpenSSH_9.5
...
debug2: host key algorithms: ssh-ed25519,ssh-rsa,ssh-dss
...
debug2: host key algorithms: rsa-sha2-512,rsa-sha2-256,ecdsa-sha2-nistp256
...
debug1: kex: host key algorithm: (no match)
Unable to negotiate with 127.0.0.1 port 22: no matching host key type found. Their offer: rsa-sha2-512,rsa-sha2-256,ecdsa-sha2-nistp256
$
EDIT 4:
I was going to show a failure to the Asustor with my cut-down ssh client, but it looks different now:
debug2: host key algorithms: rsa-sha2-512,rsa-sha2-256,ssh-rsa,ecdsa-sha2-nistp256
so maybe workaround is already underway? Long-term question is whether ssh-rsa is the safest.
EDIT 5:
Probably OK for some test, but don’t stay on that one, at least according to information found here.
and I am most likely in another timezone than you (+7). I will try to answer asap but sometimes I can’t do it immediately.