Private-Public-Key-Authentication with OpenSSH in ffp

If you have to login to your NAS frequently, you might want to automate this process a little. One of the functions of openssh is the authentication via Private/Public-Key, which will be described for the user ”root” in the following tutorial. Of course you can adapt this tutorial to other users.

Changing the home of the user
By default, the home directory of the user ”root” is set to /home, which is located in the internal flash-memory. This memory is deleted every time the device is rebooted. Thus the home-directory of the root-user should be used to the directory of ffp.

mkdir -p /ffp/home/root/
usermod -d /ffp/home/root/ root

You need to repeat the last two steps every time your firmware gets upgraded.

Generating the keypair

mkdir /ffp/home/root/.ssh
cd /ffp/home/root/.ssh

There are now two choices for the key. You can either have a password (which can automatically be entered by ssh-agent or PuttY Pageant) or no password. Both ways are described below and will generate two files named keypair and which contain the private and public key needed for the authentication:

  • Without Password
    ssh-keygen -f keypair -C 'Generated by' -t rsa -q
  • With Password
    ssh-keygen -f keypair -C 'Generated by' -N '' -t rsa -q

Activating authorized_keys in SSH
Open /ffp/etc/ssh/sshd_config and search for the following line:

#PubkeyAuthentication yes

And remove the comment:

PubkeyAuthentication yes

Moving the generated keys to authorized_keys

touch authorized_keys
chmod 600 authorized_keys
cat >> authorized_keys

Adding the private Key to the client
To copy the private keyfile to the client, you can choose between different ways depending on the available OS and programs.

  • Windows
    Download and install WinSCP and connect to your NAS-Device. Copy the File ~/.ssh/keypair to the client into a secure location.
  • Linux
    On the NAS-Device enter the following command with your credentials to copy the key to the client ”remote-system”:
    cat ~/.ssh/keypair | ssh user@remote-system 'umask 077; cat >>~/.ssh/authorized_keys'

20 thoughts on “Private-Public-Key-Authentication with OpenSSH in ffp”

  1. First of all, Thanks for the nice fun_plug package.
    Installed it without any issues to DNS-325 (using the 325 specific files).
    Have ssh working with key file authentication, but only partially. That is the reason I’m asking.

    It works from my own network (192.168.x.x.), but not from the internet.
    Now the issue could be with my POS buggy adsl router, telewell 510. It’s not the 1st time I would be having issues with port forwaring/NAT.

    Just want to be sure: Is there anything in DNS-325 or services installed by funplug which would disallow connections from sources other than local (192.168.x.x / 10.x.x.x) networks?

    (My target is to mount my dlink with sshfs as my music server, even available when I’m at office. For that one does not need too much bandwith).

    1. Just to clarify: I can connect with ssh nicely from my computer ->
      If I try ssh -> my_externalIP

      I just get connection refused. Makes me to suspect the router, but one can never be 100% sure.

    2. Never mind, got it sorted out.
      It was indeed the TW-EA510 ver 3 ADSL modem/router that was to be blamed.

      That is a really crappy equipment when it comest to port forwarding.

      Btw. I’d rather donate you cup or two of coffee by direct bank transfer from my bank account to yours without involving paypal (I boycott it after wikileaks). Pls. send me IBAN/BIC details in private message.

  2. For some reason, my ssh public-key authentication stopped working.
    It might be me cleaning up /ffp/home/root/HD_a2
    or then again, not.

    Trying to login with ssh -vv, I get nothing I would say as error.
    How do I get sshd to write a log somewhere to find out what is the issue?

    1. Funny how sleeping over the issue gives the solution next morning.
      Issue solved by:
      – Update NFS share, remove root squash
      – as root (on my laptop), connect to the NSF share, chmod 755 /ffp/start/
      – restart dslink from the web console -> telnet now enabled
      – try everything you can think of
      – Sleep on it and wake fresh in the morning
      – modify /ffp/etc/ssh/sshd_config uncomment logging
      – modify /etc/syslog.conf – uncomment the catch-all section
      – restart syslogd: sh /ffp/start/ restart
      – try to log in via ssh
      – check /var/log/messages

      In my case, I somehow had managed to mess up the permissions/owner of /ffp/home/root and ssh refused to authenticate.
      Once fixed the issue, stop telnetd, enable root quash on NFS.

  3. Ok, trying to rsync between the dns-323 and a dns-320. Tried this example for a Linux box, but it’s still asking for a password?


    1. If anyone else comes across this, I also kept getting asked for a password after enabling public key. In my experience, this always has to do with permissions. If world can read any of the home dir, the .ssh dir, or any files in it, SSHD usually won’t work as expected.

  4. Hi,
    Thanks for the tutorial.
    I found that this:

    cat ../ >> authorized_keys

    needed to be changed to this:

    cat >> authorized_keys

    Because in following the tutorial you are already in /ffp/home/root/.ssh

    I guess everybody has been doing this already.

  5. Hi,
    Nice tutorial. I check funplug log on my vol1 and in it during sshd startup it ask to overwrite the existing ssh host keys. I’m using ffp 0.7 and never seen this before in ffp 0.5. Why is it trying to generate a new ssh host key every startup?

    1. I think there’s an error at the end of the in /ffp/start/:
      if [ ! -f /etc/ssh/ssh_host_ecdsa_key ]; then
      /ffp/bin/ssh-keygen -t ecdsa -f /ffp/etc/ssh/ssh_host_ecdsa_key -N ''

      should be changed to
      if [ ! -f /ffp/etc/ssh/ssh_host_ecdsa_key ]; then
      /ffp/bin/ssh-keygen -t ecdsa -f /ffp/etc/ssh/ssh_host_ecdsa_key -N ''

  6. In the section “Adding the private Key to the client” you describe how to copy the private keypair to the clients.
    It should be the other way around, public keypair should be copied to the clients.
    Private keypair stays permanently on the host.

    1. @Boris and others.

      Yes. The pub key is given to remote hosts. The private key is kept on the box where the keys were generated.

      So when you ssh into a remote host from the nas box , you should not be asked for a password by the remote host.

  7. I am struggling to get NFS working to a DNS-325. I think that the current issue is different UID’s and GID’s. How do I change the UID and GID on a DNS-325.

  8. Hello. Trying to make a command

    usermod -d /ffp/home/root/ root

    via telnet, but get an error:
    “usermod: user root is currently logged in”

    what I’m doing wrong?

Leave a Reply

Your email address will not be published. Required fields are marked *