ssh logins for any user on QNAP TS-409

The QNAP NAS servers run a Linux OS and out of the box supports ssh logins as the “admin” user (basically root with a different name). But if you add a user and try to log in, it just closes the connection. If you look at /etc/ssh/sshd_config you’ll notice that there is a configuration line for “AllowUsers admin” which may lead you to believe that you just need to modify this line. Unfortunately the ssh server itself is also hard coded to allow admin logins only.

There are several guides for how to get around this restriction. The solution involves installing openssh either in addition to or as a replacement of the built in sshd. Many of these guides seemed overly complex to me, so I took several of them and came up with what I think is the simplest approach to replace the existing sshd with one that allows logins by all users.

This guide is known to work with the QNAP TS-409 running firmware 2.1.2 Build 1112T. It will probably work with other QNAP models, or other firmware versions, but no guarantees. This assumes you know how to ssh to your NAS as admin, you’ve created a new user and you already have ipkg installed and working. If you don’t have ipkg, see this and follow the “Sit Back” approach.

First install openssh:

ipkg update
ipkg install openssh

Now let’s swap out the stock server with the ipkg version:

mv /usr/sbin/sshd /usr/sbin/sshd-orig
cp /opt/sbin/sshd /usr/sbin/

Now on QNAP servers the filesystems are a bit strange because the OS is loaded from firmware onto a ramdisk. As a side effect of this, some system modifications will disappear upon reboot unless you follow special procedures to preserve them. This is true of the /etc/ssh/sshd_config file. We will need to move it to a location outside of the ramdisk.

cp /etc/ssh/sshd_config /mnt/HDA_ROOT/.config/ssh/

Next we need to edit the relocated sshd_config file (use your preferred editor if you don’t like vi):

vi /mnt/HDA_ROOT/.config/ssh/sshd_config

You have two choices when editing this file. Option one is to edit AllowUsers to add the usernames you want to be able to log in. Each username is separated by a space. Alternatively, you can comment out the AllowUsers line completely which will allow any user to log in.

Next copy it back to the normal location:

cp /mnt/HDA_ROOT/.config/ssh/sshd_config /etc/ssh

At this point you can test your configuration. BUT… you are NOT done yet. There’s one more step to make your changes permanent, so don’t just quit after this step.

Log into the web admin interface of your NAS and under the “System Tools” category click on “Remote Login.” Untick “Allow SSH Connection” and press “Apply.” Wait a few seconds, then tick “Allow SSH Connection” and press “Apply” again. This will reset your ssh server and if you did everything right you should now be able to login as users besides admin.

If it does not work, don’t panic. You can restart your NAS and the configuration will be replaced with the original. If you really manage to screw things up, enable telnet and log in that way to try to fix things up.

(Be careful about restarting sshd while logged in via ssh. It is very easy to kill your own connection before the new sshd starts and then you will have to use the web admin interface anyways. If you know what you are doing and are very careful, you can restart it via the shell.)

Now if everything went well, we can make the configuration permanent. We need to create or edit an script which moves the configuration over during boot. First mount the config area:

mount -t ext2 /dev/mtdblock5 /tmp/config

(The device may differ if you have a different model. Check Google if the last step doesn’t work.)

Next we need to edit or create the file:

vi /tmp/config/

If the file doesn’t exist or is empty, insert all of the following. If there is already a script there, skip the first two lines and add the rest at the end of the file:


# SSH Config
cp /mnt/HDA_ROOT/.config/ssh/sshd_config /etc/ssh/sshd_config
/etc/init.d/ restart

After saving it, make sure it is made executable and unmount the filesystem:

chmod +x /tmp/config/
umount /tmp/config

Now you can reboot your NAS and confirm that the configuration was preserved. Keep in mind that it can take 3-4 minutes to reboot. There will be a couple of short beeps during the reboot process and one longer beep when it has completed booting. Be patient and wait for the long beep before trying to login.

In the future be sure to make any configuration changes to sshd_config by editing the non-ramdisk copy like follows:

vi /mnt/HDA_ROOT/.config/ssh/sshd_config
cp /mnt/HDA_ROOT/.config/ssh/sshd_config /etc/ssh

27 thoughts on “ssh logins for any user on QNAP TS-409”

  1. Doesn’t the sshd daemon need to be replaced each time as well?

    i.e., should
    mv /usr/sbin/sshd /usr/sbin/sshd-orig
    cp /opt/sbin/sshd /usr/sbin/

    be included in the login script?

  2. No. /usr is mounted on an actual real partition but /etc is on a ramdisk which is generated from scratch on each boot, so only the config file needs to be replaced on bootup.

  3. Ah, understood, thanks. Are there any good docs about the QNAP architecture that you’ve come across (e.g., what’s a ramdisk, what gets replaced on startup).


  4. FYI – on the firmware that came with my TS-559Pro, /usr was in the RAMDISK as well, so I had to extend your modifications as follows:

    # SSH Config
    if [ -a /opt/sbin/sshd ]; then
    cp /opt/sbin/sshd /usr/sbin/
    cp /mnt/HDA_ROOT/.config/ssh/sshd_config /etc/ssh/sshd_config
    /etc/init.d/ restart

    Just thought I’d pass that on.

    Great instructions!


  5. woops! various corrections: 1) if block closed wrong 2) /opt/ not mounted yet at autorun time so moved sshd somewhere else:

    # SSH Config
    if [ -a /mnt/HDA_ROOT/.autorun/sbin/sshd ]; then
    /etc/init.d/ stop
    cp /mnt/HDA_ROOT/.autorun/sbin/sshd /usr/sbin/
    cp /mnt/HDA_ROOT/.config/ssh/sshd_config /etc/ssh/sshd_config
    /etc/init.d/ start

  6. James,

    I’m basic user of linux. I’ve red several options/topics about this, and yours is the most simple. Thanks for that!
    I do have a question though.

    You’re option does not require a /home/dir for the new users.
    Does this mean that (after i made a user account through the web interface with no /home/dir and set the rights for that user), the user can login and has specific rights on the existing folders?



  7. Okay.
    If i make the home directory with the web interface of the Qnap.
    Is only this directory the shared folder they can reach?
    Or can they also reach other folders?

  8. Even more important: How do i know when SSH is being used?
    By enabling FTE in the Qnap, it standard uses port 21. SSH uses port 22. If i give them the same portnumber (any random number), the Qnap refuses (and gives note that this port is reserved).

  9. Thanks! Agreed, much more straightforward than what I’ve read so far.

    I need user SSH to work around a QNAP bug affecting AFP that causes random disconnects during file transfers (not fixed in 3.3.2 for me). Instead we can now use a script to tunnel AFP via SSH, which seems to work well.

  10. It’s such a shame that we have to find such excellent guides like this with google, rather than through the QNAP forum.

    Thanks a lot for posting this James – really very useful 🙂

  11. Add my thanks for such a decent and working guide. Simple to just copy/paste your instructions as well. I hadn’t realised the original exe actually hardwired the “admin” user as well … was banging my head wondering why changing the conf file wasn’t working…

  12. Just to confirm, this actually worked 100% on my TS-210 model!
    Explained very well, thanks a lot!

    There is just one minor thingy that bothers me. When I log in as a different user, it keeps telling me it couldn’t change directory to /share/homes/user
    Can I tell it to go to /share/user on login instead?


  13. I very rarely leave comments, but this deserves a comment. Thank you so much for a very straight forward approach to setting this up compared to all the other articles I read out there.

    I got so far with the other articles and they never seemed to work or I was never confident in what I did worked they seemed to be too complicated with a lack of information on why things happen, i.e. with the ramdisk overwriting etc

    I believe with this extra clear information you have provided you can actually then understand what you are doing and make less mistakes.

    There are some extras that I think could be nice on here too which I had to do to set up the user to work correctly when they logged in. Unless you have another blog for this of course and I have completely missed it:-)

    I had to edit the /etc/passwd file to set up a home directory for my user, then in this path I set up a symbolic link from .ssh -> /etc/config/ssh

    Thanks very much again 🙂

  14. Thanks,

    It did work well.

    my Config updater is a bit different, because it allows me to update everythin I want on etc with my own settings. Now it was doing a copy of all changes that I saved to /share/MD0_DATA/.config/etc/…. where the same path as the original one was used in etc.



    if [ -d $SPEICHERORT ]; then

    for FILE in `$C_FIND $SDIR -type f`;
    cp $FILE /$FILE
    if [ $DEBUG ]; then
    echo “cp” “$FILE” “/$FILE”

    Well Done James

  15. Thanks for the helpful article.

    I also had to copy the part

    mv /usr/sbin/sshd /usr/sbin/sshd-orig
    cp /opt/sbin/sshd /usr/sbin/

    into my autorun file to make it work after reboot on my TS-469L.

Leave a Reply

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