[HOW-TO] Install Optware/OpenSSH as default SSHd Server

Discussion on setting up QNAP NAS products.
Post Reply
User avatar
pwilson
Guru
Posts: 22533
Joined: Fri Mar 06, 2009 11:20 am
Location: Victoria, BC, Canada (UTC-08:00)

[HOW-TO] Install Optware/OpenSSH as default SSHd Server

Post by pwilson »

Installing OpenSSH as default SSHd Server
(but keeping QNAP's SSHD version active as well)

Audience: This post requires some Linux skills, as it requires pre-installation of Optware IPKG, and requires modifying the "autorun.sh". Both of these tasks should be considered MEDIUM to EXPERT Linux Skills required. This is not a project for Linux newbies.

Prerequisites: Installing OpenSSH requires that Optware is already installed. If you don't have Optware IPKG installed, stop here, and go install Optware IPKG first. Please following the instructions in QNAPedia article: Install Optware IPKG, preferably using the QPKG method. I will refer to QNAPedia article: Running Your Own Application at Startup later in this article, so I recommend at least glancing at both of these Wikipedia articles, to ensure you have enough Linux skills to follow both of these documents.

Abstract: QNAP's provided SSHd Server restricts access to Admin-only (by design), and in the v3.8.0/v3.8.1 Firmware does not respect the $HOME Field in the /etc/passwd (which is a symlink to /etc/config/passwd). Consider the following:

Excerpt from /etc/passwd:
admin:x:0:0:administrator,,,:/share/homes/admin:/bin/sh

QNAP's SSHd daemon incorrectly sets the $HOME directory, and the $HOME environment variable to: /root as well, completely ignoring the $HOME environment variable (in the SSHd provided in Firmware v3.8.0 & v3.8.1). This is a very annoying BUG!

QNAPedia article: How To Replace SSH Daemon With OpenSSH is DANGEROUS, because it is attempting to replace the built-in one, rather than supplementing it. If Optware doesn't startup correctly, (for example after a Firmware upgrade), the QNAP owner can find themselves locked-out of their own system.

IMHO the solution is to retain the original SSHd daemon, but move it to an non-standard port, (just as QNAP does with it's "Telnet Daemon", putting Telnet on port 13131/TCP, rather the standard Telnet port 23/TCP). By taking QNAP's daemon off standard SSH port 22/TCP and placing it on a non-standard port, say 12121/TCP (any unused TCP port would do), this leaves port 22/TCP unused by the Firmware which permits installing OpenSSH (via Optware) and letting it attach to the now vacant port 22/TCP.

Doing this will give the QNAP owner a defacto-standard SSHd daemon on port 22/TCP, without disabling the QNAP provided one, which would be still available on non-standard port 12121. This setup leaves the QNAP owner with two(2) working SSHd daemons running at all times: OpenSSH running on 22/TCP, and QNAP's SSHd running on port 12121. Both the following commands would work from a Mac or Linux "Terminal" session:

Ssh to NAS via OpenSSH:

Code: Select all

ssh admin@NAS-IP


Ssh to NAS via QNAP SSHd:

Code: Select all

ssh -p 12121 admin@NAS-IP
Windows/PuTTY users can figure this out pretty easily based on the above commands.

Implementation: The first step in getting OpenSSH installed is to free up port TCP/22 on the NAS, by changing the port used by the QNAP Firmware. For this task simply proceed as follows:
  1. Access the Admin WebUI of your NAS, at http://NAS-IP:8080
    Image
  2. To configure the system settings, click “Administration” on the login portal.
    Image
  3. Click the triangle icon next to "Network Services" to expand the tree and view the items listed under this section
    Image
  4. Select "Telnet / SSH" to access the Telnet and SSH settings
    Image
  5. Reconfigure the settings to change the SSH port from the default port 22/TCP to non-standard port 12121/TCP
    Image
  6. Click Image
Congratulations. QNAP's SSHd server, (bugs and all) is now operating on port 12121/TCP! Grab a beverage!

The next step is to install OpenSSH via Optware. This is far easier than installing installing Optware was.

Login to your NAS via SSH on port 12121, (login as "admin"; see above), and enter the following commands:

Code: Select all

ipkg update
ipkg install openssh
#Start OpenSSH
/opt/sbin/sshd 2>/dev/null
Tough wasn't it. Sorry, no beverage this time (that was too easy).

Congratulations, OpenSSH Server is now running using default settings on Port 22/TCP (Standard SSHd port).

Lets test it, and ensure that you can login on the standard port.
From your PC attempt to Ssh to NAS via OpenSSH:

Code: Select all

ssh admin@NAS-IP


If you are able to successfully login, then you know OpenSSH is installed properly. (If this fails) please reply to this message with information about the failure).
If your test Login worked, then you can follow the steps in QNAPedia article: Running Your Own Application at Startup to add the following lines to your "autorun.sh" file.

Code: Select all

#Start OpenSSH
/opt/sbin/sshd 
Test your Configuration: At this point you should restart your NAS to ensure that OpenSSH does in fact startup when the NAS starts. (It should work, but again, if this fails) please reply to this message with information about the failure). Once your NAS has restarted attempt another SSH login to your NAS (login as "admin").

Lets ensure that you can login on the standard port.
From your PC attempt to Ssh to NAS via OpenSSH:

Code: Select all

ssh admin@NAS-IP


also retry Ssh to NAS via QNAP SSHd:

Code: Select all

ssh -p 12121 admin@NAS-IP
If you are able to successfully login on both ports, then you know OpenSSH is installed properly (including "autostart" at startup), and that your QNAP SSHd daemon is still accessible on port 12121/TCP. Go grab another beverage, you've probably earned it this time.

Now it is time to configure your Host Keys and Private Keys. Consult QNAPedia article: How To Set Up Authorized Keys. Failure to create your own keys will leave your system insecure, so don't be lazy. Setup your keys properly.

Quirks and Usage Tips: Due to the aforementioned $HOME bug in QNAP's SSHd implementation, there are couple of things that you need to be aware of. When access your NAS via SSH protocol on port 12121/TCP therefore will use the BASH environment created by QNAP, with your $HOME located on the RAMdisk, where the .profile etc will get overwritten at every boot. Don't bother changing these files, as they will get overwritten at every boot. :evil: (Blame QNAP not me, it's their flawed design).

When you login via SSH protocol on (default SSH) port 22/TCP via SSH (ie via the OpenSSH Server), it will set your $HOME to the one listed in the /etc/passwd file. (In my configuration it properly sets my $HOME directory, and $HOME variable to "/share/homes/admin" correctly. This means I can customize my ".profile", ".bashrc", & etc and my changes will survive a reboot. This alone makes this modification worth doing!

The other advantage of using OpenSSH rather than QNAP-SSHd for your SSH access, is that the OpenSSH implementation will allow "users" to login, as OpenSSH does not suffer from the same "stupid" Admin-only restriction that QNAP's SSHd does. You may want to take advantage of this "feature". If you create users via the Admin WebUI (See: Users section of the QNAP Turbo NAS User Manual) they too can log into the NAS. They will not have "root" priviledges, so this is relatively safe. If you don't like this behaviour, you MUST change the users shell listed in the /etc/passwd file to: /bin/false rather than /bin/sh in order to prevent them from logging in via SSH. BE AWARE OF THIS. I view this as a "feature", as I can control who can and who can not login to my NAS be editing the /etc/passwd file. (Consider yourself warned).

Some readers will view this as a disadvantage.

Caveat: My autostart method could use some work. I didn't bother to build a proper start/stop script for this, (as I always want SSH running anyway), but OpenSSH should really be setup properly with a openssh.sh start/stop script probably started from /opt/etc/init.d if you following the instructions from the Running /opt/etc/init.d/* on startup section of the QNAPedia article: Install Optware IPKG. If any community members desire this, please post a reply to this message asking me to do so. (I skipped it at this time, simply because I haven't bothered for my own use yet.

Anyway folks, I hope the QNAP NAS Community finds this article helpful. Sorry I couldn't simplify these instructions any better than this. Hopefully QNAP will eventually replace their broken SSHd daemon with a bug-fixed version that doesn't have the Admin-only restriction, and which actually respects the $HOME directory defined in the password file. Until this happens, this is a solution that provides the advantages of OpenSSH without loosing access to the default SSHd daemon provided by QNAP. Hopefully one day my instructions contained in this article will no longer be required. :twisted:

Patrick.

Patrick M. Wilson
Victoria, BC Canada
QNAP TS-470 Pro w/ 4 * Western Digital WD30EFRX WD Reds (RAID5) - - Single 8.1TB Storage Pool FW: QTS 4.2.0 Build 20151023 - Kali Linux v1.06 (64bit)
Forums: View My Profile - Search My Posts - View My Photo - View My Location - Top Community Posters
QNAP: Turbo NAS User Manual - QNAP Wiki - QNAP Tutorials - QNAP FAQs

Please review: When you're asking a question, please include the following.
User avatar
schumaku
Guru
Posts: 43579
Joined: Mon Jan 21, 2008 4:41 pm
Location: Kloten (Zurich), Switzerland -- Skype: schumaku
Contact:

Re: [HOW-TO] Install OpenSSH as default SSHd Server

Post by schumaku »

DaxtonD wrote:I have 4 users that I've added via the web admin page. They are not admin's and only have access to a private network share. I'm using OpenSSH so these users can mount their private network share folders on their Andriod phones.
Bad idea. The shell is neither restricted to the users home folder, allows to ready any files with at least o:r (what is essential for the NAS operations without Advanced Folder Permissions ACL deployed), beyond they are able to see all kind of system files, too.
DaxtonD wrote:My question is: while logging in via SSH, Will these users have the same folder permissions as they've been assigned in the web admin?
No, of course not - because neither the shell or i.e. NFS can be controlled in this way.
DaxtonD wrote:Or will they be able to see all folders/directories?
All as much as possible per the U**x file/folder ownerships and protection masks.
DaxtonD wrote:Other than brute-force attacks on passwords, is there any other reason I should consider using key authentication?
Exposing ssh or ftp the Internet will lead do an almost constant flood of brute force, script kiddies playground, slow scanners, ... Even worse: I doubt the QNAP NAS security intrusion detection will cover this non-QNAP daemon. Certainly not what you want to have on your NAS.

Replacing or substituting the sshd? Nice proof of concept - not ready for production and prime time I'm afraid.
User avatar
pwilson
Guru
Posts: 22533
Joined: Fri Mar 06, 2009 11:20 am
Location: Victoria, BC, Canada (UTC-08:00)

Re: [HOW-TO] Install OpenSSH as default SSHd Server

Post by pwilson »

DaxtonD wrote:Thank-you for the detailed and simplified explanation. When I'd originally asked for help, I certainly didn't expect a novel. This is wonderful.

I am having 1 problem.
I did not have an autorun.sh file. I used WinSCP to connect to the NAS an create and edit the autorun.sh file at /tmp/config/autorun.sh (I find this easier than nano or vi)
I added the 2 lines that you'd mentioned above:
#Start OpenSSH
/opt/sbin/sshd

I saved the file, made it executable, restarted the NAS and tried logging in via putty. however, the connection was refused on port 22. Obviously, the autorun failed.
I tried port 12121 and successfully logged in.
to manually start OpenSSH, I typed this:
#Start OpenSSH
Then, i typed:
/opt/sbin/sshd
and received the message:
Could not load host key: /opt/etc/openssh/ssh_host_ecdsa_key

Any ideas?
Did you setup your Host Keys?
I wrote:Now it is time to configure your Host Keys and Private Keys. Consult QNAPedia article: How To Set Up Authorized Keys. Failure to create your own keys will leave your system insecure, so don't be lazy. Setup your keys properly.
Despite the errormessage you provided above, OpenSSH should in fact be running.

You can verify where or not it is running with the following command:

Code: Select all

ps faxo "%U %t %p %a" | grep sshd | grep -v grep
When I run this here, I get:

Code: Select all

ps faxo "%U %t %p %a" | grep sshd | grep -v grep                                                                          
 5781 admin       660 S   /opt/sbin/sshd 
22416 admin       604 S   /usr/sbin/sshd -f /etc/ssh/sshd_config -p 12121 
31825 admin      2132 S   sshd: admin@pts/4 
Please note, both SSH servers running.

It also might be failing to permit login if the $HOME field in the passwd file points to a non-existent directory, or if permissions issues exist.

Try this:

Code: Select all

ls -alFLd 'cat /etc/passwd | grep admin:x | cut -d : -f 6` 
My output for this command looks like this:

Code: Select all

ls -alFLd `cat /etc/passwd | grep admin:x | cut -d : -f 6`
drwxrwx--- 7 admin administrators 4096 2013-01-08 14:23 /share/homes/admin/
Careful with the punctuation here, use cut&paste to get it right.

Please post your output from these commands back to this message thread so I can see what is going on with your NAS.
DaxtonD wrote:Lastly, a question:
I have 4 users that I've added via the web admin page. They are not admin's and only have access to a private network share. I'm using OpenSSH so these users can mount their private network share folders on their Andriod phones.
I don't wish to use public or private keys. Instead, the users will just use the passwords they've been assigned.
My question is: while logging in via SSH, Will these users have the same folder permissions as they've been assigned in the web admin? Or will they be able to see all folders/directories?
Other than brute-force attacks on passwords, is there any other reason I should consider using key authentication?
No, however security is not something to be taken lightly. Key authentication is very good idea. Folder permissions will be what they are, so how the WebUI set them up initially really isn't important. What is important is what the permissions are set to now, regardless of how they got set that way. For example you'll need to check both the classic U**x/Linux file permissions, and also the ACL permissions (if present).

I do not expose my port 22/TCP to the internet. Test everything inside your network first, to ensure it is working. When everything is working you can attempt to expose one or both of your SSHd daemons to the Internet, if you believe it is save to do so. Small steps my friend. The changes in my [HOW-TO] article are fundamentally changing the behaviour of your system, so you need to fully audit it's security before exposing it to the wild internet.

The script-kiddies on the net will eventually "test" your IP address for open ports, and if they detect Port 22/TCP exposed, you will likely become a target for intrusion attempts. Get it working locally first. Once it is working you can look at securing it prior to exposing it to the Internet.

Patrick M. Wilson
Victoria, BC Canada
QNAP TS-470 Pro w/ 4 * Western Digital WD30EFRX WD Reds (RAID5) - - Single 8.1TB Storage Pool FW: QTS 4.2.0 Build 20151023 - Kali Linux v1.06 (64bit)
Forums: View My Profile - Search My Posts - View My Photo - View My Location - Top Community Posters
QNAP: Turbo NAS User Manual - QNAP Wiki - QNAP Tutorials - QNAP FAQs

Please review: When you're asking a question, please include the following.
User avatar
pwilson
Guru
Posts: 22533
Joined: Fri Mar 06, 2009 11:20 am
Location: Victoria, BC, Canada (UTC-08:00)

Re: [HOW-TO] Install OpenSSH as default SSHd Server

Post by pwilson »

DaxtonD wrote:I have 4 users that I've added via the web admin page. They are not admin's and only have access to a private network share. I'm using OpenSSH so these users can mount their private network share folders on their Andriod phones.

schumaku wrote:Bad idea. The shell is neither restricted to the users home folder, allows to ready any files with at least o:r (what is essential for the NAS operations without Advanced Folder Permissions ACL deployed), beyond they are able to see all kind of system files, too.


Afraid Schumaku is absolutely correct here. Granting users "shell" access is not something that should be taken lightly. Even if you only grant this access to users you "trust", you need to remain aware, that if your "trusted" shell users use poor password security, a Script-Kiddie might access your NAS using one of these accounts. Once a Script-kiddie has accessed your system, even via an "unprivileged" user account they will be able to look at your /etc/passwd file, which will fully list all the usernames on your machine, that they can then attempt to hack.
DaxtonD wrote:My question is: while logging in via SSH, Will these users have the same folder permissions as they've been assigned in the web admin?

schumaku wrote:No, of course not - because neither the shell or i.e. NFS can be controlled in this way.
Yet another valid point. While I did admit that "user" access would be possible, I definitely did not recommend enabling it for all users. QNAP restricts their SSHd to "Adnin-only" for some pretty valid reasons. I find the restriction annoying, so I have indeed circumvented it using OpenSSH instead, but I most definitely have not enabled "universal" user access to my NAS. You should be getting this working only for "admin" initially. Once you have it working then you can fully review the
security implications of extending access to "users".
DaxtonD wrote:Or will they be able to see all folders/directories?

schumaku wrote:All as much as possible per the U**x file/folder ownerships and protection masks.

DaxtonD wrote:Other than brute-force attacks on passwords, is there any other reason I should consider using key authentication?


It is far safer, as no password authentication is required, but it also permits commands like "scp" and "sftp" to function with password authentication also which makes moving files between machines far easier to do. This is particularly useful, if you intend to "edit" NAS system files under Windows using a Linux-friendly editor such as "notepad++" or "textpad2" etc. and then transfer the files into place on your NAS.
schumaku wrote:Exposing ssh or ftp the Internet will lead do an almost constant flood of brute force, script kiddies playground, slow scanners, ... Even worse: I doubt the QNAP NAS security intrusion detection will cover this non-QNAP daemon. Certainly not what you want to have on your NAS.

Replacing or substituting the sshd? Nice proof of concept - not ready for production and prime time I'm afraid.
These, and more are issues that need to be considered and addressed prior to exposing any port to the Internet. (This is one of the reasons why I disable UPnP in my router, as I don't want unauthenticated processes to be able to open or forward ports on my Router).

Similarly, Schumaku's observations about QNAP NAS security intrusion detection not covering non-QNAP daemons is another very valid concern, and to be honest this wasn't something I considered when offering my solution. In my case this is NOT a concern, as my Router has "flooding" and "intrusion detection" settings already in place on both 21/TCP (FTP), and 22/TCP (SSH), so I already have this covered. I do not forward 12121, at my Router, so I didn't need to protect this port, but I will now secure it anyway, in case I decide enable it later.

I tried to consider all these issues when I set my system in preparation for writing my [HOW-TO] document. Schumaku has effectively demonstrated that I did not cover all the security issues I should have. Some of these issues can by mitigated by security at the router, but the fact remains, that while OpenSSH does permit "user" access, actually providing it is probably not a good idea. [It kills me to admit this :evil: ].

I still feel the benefits of using OpenSSH for "admin" access, (especially a non-volatile $HOME directory), make this effort worthwhile, but Schumaku's wisdom on these security issues not being properly considered and not being addressed properly still applies. Similarly his observation that this is not ready for production and prime time is unfortunately also correct. (Unfortunately, the $HOME bug in the QNAP SSHd makes their SSHd less than ready for production use also).

His observations on "user" access are absolutely correct, so while I will continue to use this solution here (for admin-only), I completely agree with Schumaku on his observations about user access. The risks outweigh the benefits, so enabling user access with OpenSSH, is not a good idea. QNAP continues to maintain that their "Admin-only" restriction is "by-design", and therefore they will not be changing this restriction anytime soon.

I have complained about the "Admin-only" SSH restriction many times over the years, but I acknowledge that it isn't enough to simply "enable it myself" (by any means possible), as there are some pretty serious security issues to be considered. I hate admitting it, but Schumaku has provided enough compelling reasons for me to withdrawn my objections to the "Admin-only" SSH restriction going forward. Simply removing the restriction would not be enough.

I can be pretty stubborn, but I am prepared to reverse long-held positions on issues, when presented with compelling reasons to do so. In fact I will even go so far as to say that I will remove this solution from my NAS as soon as the SSHd $HOME bug is fixed in the Firmware. I now view my solution as nothing more than a "short-term" workaround for the QNAP SSHd $HOME bug.

Patrick.

PS: @Schumaku, congrats, it isn't often that I change "long-held" views on issues, and I honestly never expected to reverse my view on the "Admin-only" restriction ever. Thank-you for your input on my article, and for providing good reasons for my reversal of attitude.

Patrick M. Wilson
Victoria, BC Canada
QNAP TS-470 Pro w/ 4 * Western Digital WD30EFRX WD Reds (RAID5) - - Single 8.1TB Storage Pool FW: QTS 4.2.0 Build 20151023 - Kali Linux v1.06 (64bit)
Forums: View My Profile - Search My Posts - View My Photo - View My Location - Top Community Posters
QNAP: Turbo NAS User Manual - QNAP Wiki - QNAP Tutorials - QNAP FAQs

Please review: When you're asking a question, please include the following.
User avatar
schumaku
Guru
Posts: 43579
Joined: Mon Jan 21, 2008 4:41 pm
Location: Kloten (Zurich), Switzerland -- Skype: schumaku
Contact:

Re: [HOW-TO] Install OpenSSH as default SSHd Server

Post by schumaku »

That's good... also because of sftp is not the best solution without a (lot) more effort to prohibit any access to files in shares the user has no access to. What is a no-brainer in AFP, SAMBA, FTP/FTPES does expose by far to much when using a shell-based (ssh) access like sftp or the legacy scp.
ilivlad
New here
Posts: 8
Joined: Mon May 28, 2012 10:15 am

Re: [HOW-TO] Install OpenSSH as default SSHd Server

Post by ilivlad »

Hello guys!
I applied this setup on my ts112 and it works but when I restart QNAP contents of my /share/homes/admin/ folder gets deleted.
Firmware is 3.8.1 Build 20121205
What could be the problem?
Thanks!
User avatar
schumaku
Guru
Posts: 43579
Joined: Mon Jan 21, 2008 4:41 pm
Location: Kloten (Zurich), Switzerland -- Skype: schumaku
Contact:

Re: [HOW-TO] Install OpenSSH as default SSHd Server

Post by schumaku »

ilivlad wrote:I applied this setup on my ts112 and it works but when I restart QNAP contents of my /share/homes/admin/ folder gets deleted.
"Home Folder" feature enabled? This will create the homes share.
ilivlad
New here
Posts: 8
Joined: Mon May 28, 2012 10:15 am

Re: [HOW-TO] Install OpenSSH as default SSHd Server

Post by ilivlad »

Yes, thanks schumaku, that was the problem ...
kenned88
Starting out
Posts: 22
Joined: Wed Jun 22, 2011 2:23 pm
Location: Denmark
Contact:

Re: [HOW-TO] Install OpenSSH as default SSHd Server

Post by kenned88 »

Hi There,

I got some problems with my qnap not auto running the script.

this is my autorun.sh in /dev/sdx6
#!/bin/sh
/share/MD0_DATA/.qpkg/autorun/autorun.sh &
it has 755 as permissions

and this is my autorun.sh in /share/MD0_DATA/.qpkg/autorun/autorun.sh
#!/bin/sh

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

#Start OpenSSH
/opt/sbin/sshd 2>/dev/null

and this script has 755 as well.

Do you guys have any idea what's wrong? I try to do this on a TS-469L by the way.
User avatar
pwilson
Guru
Posts: 22533
Joined: Fri Mar 06, 2009 11:20 am
Location: Victoria, BC, Canada (UTC-08:00)

Re: [HOW-TO] Install OpenSSH as default SSHd Server

Post by pwilson »

kenned88 wrote:Hi There,

I got some problems with my qnap not auto running the script.

this is my autorun.sh in /dev/sdx6
#!/bin/sh
/share/MD0_DATA/.qpkg/autorun/autorun.sh &
it has 755 as permissions

and this is my autorun.sh in /share/MD0_DATA/.qpkg/autorun/autorun.sh
#!/bin/sh

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

#Start OpenSSH
/opt/sbin/sshd 2>/dev/null

and this script has 755 as well.

Do you guys have any idea what's wrong? I try to do this on a TS-469L by the way.
/opt isn't mounted when "autorun.sh" runs. Try:

Code: Select all

/share/MD0_DATA/.qpkg/Optware/sbin/sshd 2>/dev/null


instead. Also drop the "2>/dev/null" part. Error messages when the script runs are useful to see.

Patrick M. Wilson
Victoria, BC Canada
QNAP TS-470 Pro w/ 4 * Western Digital WD30EFRX WD Reds (RAID5) - - Single 8.1TB Storage Pool FW: QTS 4.2.0 Build 20151023 - Kali Linux v1.06 (64bit)
Forums: View My Profile - Search My Posts - View My Photo - View My Location - Top Community Posters
QNAP: Turbo NAS User Manual - QNAP Wiki - QNAP Tutorials - QNAP FAQs

Please review: When you're asking a question, please include the following.
daron
New here
Posts: 6
Joined: Tue Mar 19, 2013 5:56 am

Re: [HOW-TO] Install OpenSSH as default SSHd Server

Post by daron »

Dear Patrick,

Thank you for this guide.
I followed it through and it worked fine fo me until a minute ago.

i am using the 469l with 3 HDs installed.
OS: win7 and Debian squeeze
FW: 3.8.2 Build 20130301
NW Setup: single Port

it was this section which broke my neck:
When you login via SSH protocol on (default SSH) port 22/TCP via SSH (ie via the OpenSSH Server), it will set your $HOME to the one listed in the /etc/passwd file. (In my configuration it properly sets my $HOME directory, and $HOME variable to "/share/homes/admin" correctly. This means I can customize my ".profile", ".bashrc", & etc and my changes will survive a reboot. This alone makes this modification worth doing!
so, i thought i can modify those files to my needs...
i logged in with putty to the opensshd and changed the default homedir of admin user to "/root" and default shell of admin user to bash.
the result: connection refused on opensshd (22), no admin login on qnap sshd (other users not allowd).
so i guess the following: /bin/bash is not existing, right? shame on me, i didn't check it before editing :(

any suggestions/hints/tipps/tricks howto get into the system again?

is there a way to use FTP/web/whatsoever (i have access to the webgui. so, is it possible to mount the filesystem in a way i have access to it via ftp or similar?) to modify the /etc/passwd file?
your help would be highly appreciated!

EDIT: added some basic information
EDIT2: backup of NAS is running right now :( , cause i fear, i'll have to re-install FW.
br, Ron
Dropnuts
Getting the hang of things
Posts: 70
Joined: Sat Oct 31, 2009 2:09 pm
Location: Australia

Re: [HOW-TO] Install OpenSSH as default SSHd Server

Post by Dropnuts »

Have you tried access via Telnet?

You can enable Telnet via the web gui.
[TS-509] - E7600 C2D CPU, TS-809 firmware on 16GB SSD DOM
daron
New here
Posts: 6
Joined: Tue Mar 19, 2013 5:56 am

Re: [HOW-TO] Install OpenSSH as default SSHd Server

Post by daron »

yes, i did.
same result. :(
unfortunately its not possible to login with telnet either...

tried it with putty and with win command line

Code: Select all

NAS login: admin

Password:
sh: pts/0: No such file or directory
Cannot execute /bin/bash: No such file or directory
.....and back to prompt

anyway...
thank your for your help
User avatar
pwilson
Guru
Posts: 22533
Joined: Fri Mar 06, 2009 11:20 am
Location: Victoria, BC, Canada (UTC-08:00)

Re: [HOW-TO] Install OpenSSH as default SSHd Server

Post by pwilson »

daron wrote:yes, i did.
same result. :(
unfortunately its not possible to login with telnet either...

tried it with putty and with win command line

Code: Select all

NAS login: admin

Password:
sh: pts/0: No such file or directory
Cannot execute /bin/bash: No such file or directory
.....and back to prompt

anyway...
thank your for your help
First line of the Script should be:

Code: Select all

#!/bin/sh
Also check that nothing changed your /etc/passwd file. The last field of all login accounts should be "/bin/sh" rather than "/bin/bash". If you are running Firmware v3.8.1 or higher, /bin/sh will be "Bash" anyway.

Code: Select all

cat /etc/passwd | grep admin
admin:x:0:0:administrator,Administrator,,:/share/homes/admin:/bin/sh
Prove it for yourself:

Code: Select all

sh --version
This produces the following output here:

Code: Select all

sh --version     
GNU bash, version 3.2.0(1)-release (i686-pc-linux-gnu)
Copyright (C) 2005 Free Software Foundation, Inc.
I hope you figure out what is corrupting your /etc/config/passwd file, if we didn't know better we might think you deliberately corrupted this file yourself. :shock:

Patrick M. Wilson
Victoria, BC Canada
QNAP TS-470 Pro w/ 4 * Western Digital WD30EFRX WD Reds (RAID5) - - Single 8.1TB Storage Pool FW: QTS 4.2.0 Build 20151023 - Kali Linux v1.06 (64bit)
Forums: View My Profile - Search My Posts - View My Photo - View My Location - Top Community Posters
QNAP: Turbo NAS User Manual - QNAP Wiki - QNAP Tutorials - QNAP FAQs

Please review: When you're asking a question, please include the following.
daron
New here
Posts: 6
Joined: Tue Mar 19, 2013 5:56 am

Re: [HOW-TO] Install OpenSSH as default SSHd Server

Post by daron »

Patrick,
if we didn't know better we might think you deliberately corrupted this file yourself.
That's what i said in my first post (http://forum.qnap.com/viewtopic.php?p=340682#p340682). i did the changes on purpose but i was not aware about the do's and don'ts for changes. Finally i locked myself out of the system (on shell level) - webgui was still working fine.
First line of the Script should be:
which script? i didn't talk about a script...

and for the rest of your hints: i was not able to login, so no chance to check the things you mentioned :(

Finally i solved it with a little help from Kurt (http://forum.qnap.com/viewtopic.php?p=104402#p104402) but with small changes:
- Shutdown the system and remove the drives
- Boot, login using ssh to port 22 (even though sshd (port 13022) and telnet (port 13131) deamons were enabled in webgui before, telnet was not available and sshd was listening to port 22 instead)
--> login with admin/admin!!!!!
- Hot plug the drives
- Assemble the system RAID partition, e.g. for a 4 HDD system:
# mdadm -A /dev/md9 /dev/sda1 /dev/sdb1 /dev/sdc1 /dev/sdd1
# mkdir /mnt/HDA_ROOT
# mount /dev/md9 /mnt/HDA_ROOT
# cd /mnt/HDA_ROOT
- search for the passwd file with e.g.

Code: Select all

 find . | grep passwd
./.config/passwd-
./.config/smbpasswd
./.config/passwd~
./.config/passwd
[admin@NAS HDA_ROOT]#
# vi .config/passwd
- undo the changes which corrupted the system (in my case: changed back the default shell to /bin/sh)
- write changes to file and
- reboot

after the NAS was up again i was able to login on the qnap sshd on specified port (in webgui) with my admin credentials. 8)
Ron
Post Reply

Return to “Turbo Station Installation & Setup”