Category: 電腦 / Computers

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 http://forum.qnap.com/viewtopic.php?f=85&t=1085 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 autorun.sh 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 autorun.sh file:

vi /tmp/config/autorun.sh

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:

#!/bin/sh

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

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

chmod +x /tmp/config/autorun.sh
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

If you are trying to use this plugin on XP 64-bit OS you may find that you follow all the directions to install it and then run into an error:

“unable to load …ReduceFlickerSSE3.dll”

The problem is that the instructions tell you to install AvsRecursion.dll in “C:\WINDOWS\system32”. On XP x64 it should actually be installed in “C:\WINDOWS\SysWOW64”. Move it there and it should work fine.

This is a bizarre problem I ran into on my new desktop that I wasn’t able to find a solution to by googling, so hopefully this post will help some other poor soul avoid hours of banging head against keyboard which is not good for either head or keyboard. Anyways…

Let’s say you have an XP Pro x64 64-bit system. You’ve installed Avisynth and DGMPGDEC and have run dgindex on some video and set up an avs project file for it. Most things read it in fine, like AvsP and Megui. But when you try to play it with Media Player Classic you get an error that it can not render MEDIASUBTYPE_YV12.

I’m not sure if this has anything to do with a 64-bit OS, but I’ve done the same thing on 32-bit systems before and never ran into the problem. It could also be a quirk in the software versions of the programs I use. Anyhow, I’m putting all this in so that the next person to search on the terms I was searching on will find some useful advice.

There is one easy workaround for it which is to stick “converttorgb()” at the end of the avs file, but that has issues of its own once you get to encoding or whatever else you were going to do with the avs project.

There are a few pointers in google to setting ffdshow to use the RGB YV12 output conversion settings to solve the problem, which is the wrong advice but put me on the right path.

The real solution is to bring up the ffdshow “Video decoder configuration” program, click on codecs, scroll all the way to the bottom and find the “Raw Video” format. Click on the second column (which probably says “disabled”) and a little pulldown menu will come up. Set it to “all supported” and then click on the “OK” button at the bottom.

Should play just fine now.