You don’t want to do root login to the QNAP, so those files don’t apply. The commands given above for the RPi should work just fine, you just need to provide the correct username (not
pi) and your QNAP’s IP address.
TL;DR: Go for it. Just use the username for your QNAP user (not root, not ever root) instead of
pi in the commands above, and of course, replace the IP address shown with that of your QNAP NAS.
The works of it is just this: each user has (or can have) a
.ssh subdirectory (normally hidden from
ls, but visible by doing
ls -a) in the user’s home directory, and you can
cd into it. This stores that user’s particular SSH configuration. There are three things you might find in this directory if it exists:
- A file typically called
known_hosts, which holds the public host keys of other systems that user has
ssh'd into. These are kept so that future connections to that host can verify the same public key; you’ll get a warning if you connect to a host you’ve connected to before but the key doesn’t match (i.e. maybe somebody put a different machine at that IP address and is now attempting to scrape usernames and passwords). This isn’t relevant to this discussion except as a mention, so I’ll leave it at that (ignore this file).
- A file called
authorized_keys containing the public keys of any other users (or systems) that are allowed to connect to this system as this user without a password.
- Any number of user key files (public and private in a single file, or separated into two files, one often with no suffix and the other with a
.pub suffix) that are used to access other systems. Probably most common on Linux is just two files
id_rsa_pub that are created when the user account is created. I won’t go more into this; these files can be ignored (and don’t touch! )
What we’re doing is we are taking a copy of the public key (only; never move the private key) from the source system (Vera, in this case) and putting it into
authorized_keys on the target system in the SSH config of the target user account. Since the Vera typically only uses its system key for establishing remote connections (OpenWrt doesn’t have users other than root, and does not create a separate key for that user), that’s the public key we are going after. So the
dropbearkey command in the other post plus the
grep that follows extracts the Vera’s host public key. The rest of that command just pushes that public key onto the target user’s
authorized_keys file (creating both the directory and file if needed). And the commands after (
chown, chmod) just make sure that file permissions on any newly created
.ssh directory and
authorized_keys file on the target system are locked down correctly – most
ssh servers will ignore files that have permissions set too relaxed, for security.