# problems sshfs-mounting share after update

## Elleni

I realized that some shares I usually mount through ssh are gone. Trying to mount manually I see: 

```
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 

```
no matching key exchange method found. Their offer: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
```

 while 

```
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: 

```
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 

```
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: 

```
Host ip.ad.re.ss

        KexAlgorithms +diffie-hellman-group1-sha1

```

in /etc/ssh/ssh_config

Informations found here

----------

## Elleni

Any recommendation on this one?

----------

## Elleni

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.

----------

## Hu

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.

----------

## Elleni

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.

----------

## redfish

As Hu said, perhaps you fell victim to this: https://lwn.net/Articles/853445/

----------

