View previous topic :: View next topic |
Author |
Message |
Elleni Veteran
Joined: 23 May 2006 Posts: 1270
|
Posted: Sat Dec 26, 2020 3:11 pm Post subject: problems sshfs-mounting share after update |
|
|
I realized that some shares I usually mount through ssh are gone. Trying to mount manually I see:
Code: | ssh -v -i /etc/ssh/ssh_host_rsa_key -p number root@ip.ad.re.ss
OpenSSH_8.4p1, OpenSSL 1.1.1i 8 Dec 2020
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Authenticator provider $SSH_SK_PROVIDER did not resolve; disabling
debug1: Connecting to ip.ad.re.ss [ip.ad.re.ss] port number.
debug1: Connection established.
debug1: identity file /etc/ssh/ssh_host_rsa_key type 0
debug1: identity file /etc/ssh/ssh_host_rsa_key-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.4
debug1: Remote protocol version 1.99, remote software version OpenSSH_4.2
debug1: match: OpenSSH_4.2 pat OpenSSH_2*,OpenSSH_3*,OpenSSH_4* compat 0x00000002
debug1: Authenticating to ip.ad.re.ss:number as 'root'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: (no match)
Unable to negotiate with ip.ad.re.ss port number: no matching key exchange method found. Their offer: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 |
Maybe something was changed on a recent update of my gentoo ssh client (or on the ssh server on the nas)?
How can this be solved?
I am a little confused as Code: | no matching key exchange method found. Their offer: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 | while Code: | ssh -Q kex
diffie-hellman-group1-sha1
diffie-hellman-group14-sha1
diffie-hellman-group14-sha256
diffie-hellman-group16-sha512
diffie-hellman-group18-sha512
diffie-hellman-group-exchange-sha1
diffie-hellman-group-exchange-sha256
ecdh-sha2-nistp256
ecdh-sha2-nistp384
ecdh-sha2-nistp521
curve25519-sha256
curve25519-sha256@libssh.org
sntrup4591761x25519-sha512@tinyssh.org |
I can succesfully ssh to the nas with:
Code: | ssh -oKexAlgorithms=+diffie-hellman-exchange-group1-sha1 -i /path/to/rsa_key -p portnumber root@ip.ad.re.ss
ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 -i /path/to/rsa_key -p portnumber root@ip.ad.re.ss |
and
Code: | ssh -oKexAlgorithms=+diffie-hellman-group14-sha1 -i /path/to/rsa_key -p portnumber root@ip.ad.re.ss
|
So the remaining question would be how to proceed, I guess.
Should I enable an option in gentoo ssh client and if so, which of the three is the best method? The nas it is quite an old model and I don't know if there still are updates provided for it. Can I check somehow what methods are supported on the server and adapt to get the best keyexchange configured? On the ssh server on the nas ssh -Q kex does not work (ssh: illegal option -- Q) How can I find out what the supported key-exchange options are on the server side?
I can workaround the problem by adding:
Code: | Host ip.ad.re.ss
KexAlgorithms +diffie-hellman-group1-sha1
| in /etc/ssh/ssh_config
Informations found here |
|
Back to top |
|
|
Elleni Veteran
Joined: 23 May 2006 Posts: 1270
|
Posted: Sun Jan 03, 2021 8:44 pm Post subject: |
|
|
Any recommendation on this one? |
|
Back to top |
|
|
Elleni Veteran
Joined: 23 May 2006 Posts: 1270
|
Posted: Thu Apr 29, 2021 11:34 pm Post subject: |
|
|
I am coming back on this one and would like to hear a maybe better solution than the workaround? Additionally I observe that it takes a very long - minutes - amount of time till the mounting networksystems service finishes while booting.
And I see that only 4 of the 5 entries in fstab are mounted. The server is finally fully booted a mount -a mounts the fifth sshfs share that was not being mounted while booting despite being in fstab the same way. I would love to improve above situation and am interested to hear what I could do. If there are any useful informations helping understand abo e behaviour I'd happily provide. |
|
Back to top |
|
|
Hu Moderator
Joined: 06 Mar 2007 Posts: 21633
|
Posted: Fri Apr 30, 2021 1:31 am Post subject: |
|
|
ssh -Q lists what is supported, not what will be used. The presence of an entry in that output says your ssh can use that if it is instructed to do so. It does not say that the default will be to use any of those. If I recall correctly, openssh has been steadily deprecating old algorithms that should no longer be used due to known weaknesses. The correct solution is to update the server to support good algorithms. I fully expect that an embedded NAS will not have such updates available, because vendors of such devices typically abandon them far too soon. Seeing a NAS still running OpenSSH_4.2 is impressively ancient though.
Why are you using sshfs with a NAS? Typically, a NAS will export its filesystems over NFS. |
|
Back to top |
|
|
Elleni Veteran
Joined: 23 May 2006 Posts: 1270
|
Posted: Fri Apr 30, 2021 6:45 pm Post subject: |
|
|
Exactly, it is quite ancient. sshfs is used as the nas provides additional space to our nextcloud instance. The gentoo nextcloud server is on a hosted vps, while the nas is on a friends place whose provider happens to provide a fixed ip. |
|
Back to top |
|
|
redfish n00b
Joined: 27 Apr 2021 Posts: 22
|
|
Back to top |
|
|
|