SSH from NAS to Webserver (ssh/config)

[Ben_beton]

Hi,

I wan't to backup my webserver on my nas.
The webserver is reachable und secured with a keyfile.

I saved my ssh connection config to ~/.ssh/config
there I store my keyfile too.

now when trying to open a ssh session from the nas to my webserver (ssh webserver) it gives me an error "could not resolve webserver: Name or service not known"

seems that ssh is not using the config file. It is working on my MacBook. Is there a difference betwenn ssh on qnap or did I missed something?!

QTS 4.2.0 Build 20160130

[kirkgbr]

Typically "could not resolve xxxxxx" means something wrong with DNS or name service or hosts file. You might try ssh'ing to the webserver via it's IP address to exclude the name service problem.

[Ben_beton]

yes, ssh is trying to resolve "webserver" but webserser is only the host name in the config and not the fqdn to connect to. Thats why I'm thinking ssh is not using the config file stored in ~/.ssh/

any ideas?

[kirkgbr]

My guess is something wrong with your ~/.ssh/config file.

I have duplicated your problem here on my QNAP.

Code: Select all

$ cat ~/.ssh/config
Host webserver
        Hostname webserver.local
        User user1
       
$ ssh webserver
ssh: Could not resolve hostname webserver.local: Name or service not known        
        

However, If I place a resolvable name on the "Hostname" line above it works fine.

[Ben_beton]

yes this is working but on my site I defined to use a keyfile and this keyfile is not used, only hostname and user are being used.

glad to see that ssh webserver is not only a problem on my nas.

I figured out, that it work if I specify -F /patch/to/config (~/.ssh/config)
btw. thanks for the sample, that is helping to understand the issue.

I'm thinking about switching to OpenSSH, maybe then it will work, but it would be best if it works out of the box

[kirkgbr]

Hope you understand that in my example above, "webserver.local" is NOT resolvable and I chose this name to prove the point. If I put a resolvable hostname in there, the config works as expected with "out of the box" ssh.

[Ben_beton]

ok, now its clear, so the issue is only on my side is your signature FW Version 4.1.4 the FW you tested on? I'm running 4.2.0 as postet above, maybe there is someone who is using 4.2.0 and can or can't reproduce the issue

[egerards]

I'm also using FW 4.2.0 and a couple of days ago I created a ~/.ssh/config file and noticed that this file is completely being ignored. When I do an 'ssh -F ~/.ssh/config <short_name>' then it works. For some reason the ssh client is ignoring ~/.ssh/config unless explicitly specified via the '-F' parameter.

[Ben_beton]

thank you for the hint, it's not working on my side. I opened a ticket a few days ago, lets wait and see if the support can help.

[redfish907]

Did you receive a response for the ticket? I have the same issue, and am trying to find a solution. My config files is correct, but it seems as though ssh is ignoring the file.

[Ben_beton]

they replied:

Your request is recognized as feature request. It is forwared to our development and this ticket als technical problem must be closed.

then I asked, why a working thing is now a feature request:

If the standard ssh does not work at all, we will fix. But for personaly generated ssh key, we will not support any more.

I think, that's it

[provenal]

This seems to still be an issue and can't find anything about the ssh client not reading the default config file using the built-in ssh.

Am on a TS-EC1280U
Firmware version 4.2.2 Build 20161102

Code: Select all

# ssh -V
OpenSSH_7.3p1, OpenSSL 1.0.1u  22 Sep 2016

[falloutphil]

Agree this is breaking from the specified OpenSSH behaviour - it's a bug not a feature to restrict this without documenting it - still present on latest OS for x53D series:

[~] # uname -a
Linux NAS 4.14.24-qnap #1 SMP Sat Oct 24 05:11:24 CST 2020 x86_64 GNU/Linux
[~] # ssh -V
OpenSSH_8.0p1, OpenSSL 1.0.2s 28 May 2019
[~] #

[herrkulesh]

ssh is looking for the config file in /share/homes/admin/.ssh/config (and also /usr/etc/ssh_config)

reason is in /etc/passwd where home for admin is defined as /share/homes/admin
so I think it's not a bug

faced the same challenges and strace'd open on ssh

[c01000100]

If anyone else is still looking for a solution, I followed the crumbs from previous posts and arrived at:

- Identify admin home folder

Code: Select all

cat /etc/passwd | grep admin

- Go to the path where current ssh session has set as home

Code: Select all

cd ~

- Create symlink to admin users .ssh folder

Code: Select all

ln -s /share/homes/admin/.ssh/ .ssh

- Rebuild the config file at ~/.ssh/config
- Regenerate ssh keys
- Send .pub keys to necessary remote servers

---
Another solution might be to make an alias for ssh to set the desired config file to use.