Difference between revisions of "Open Stock Firmware LS-VL"

From NAS-Central Buffalo - The Linkstation Wiki
Jump to: navigation, search
m (What is necessary?)
(The guide)
Line 44: Line 44:
  
 
   java -jar acp_commander.jar -t 192.168.172.1 -ip 192.168.172.1 -pw password -c "chmod 600 /root/.ssh/authorized_keys"
 
   java -jar acp_commander.jar -t 192.168.172.1 -ip 192.168.172.1 -pw password -c "chmod 600 /root/.ssh/authorized_keys"
 +
 +
If you have created the file ''authorized_keys'' on a Windows PC, be sure to run the dos2unix command on it. Otherwise you may get a "'''Server refuse our key'''" error.
 +
  java -jar acp_commander.jar -t 192.168.172.1 -ip 192.168.172.1 -pw password -c "dos2unix /root/.ssh/authorized_keys"
  
 
Then we rename sshd_config for backup purposes.  
 
Then we rename sshd_config for backup purposes.  

Revision as of 21:59, 20 March 2011

Contents

Important

The tool acp_commander is used. You can find the readme here: http://downloads.buffalo.nas-central.org/TOOLS/ALL_LS_KB_ARM9/ACP_COMMANDER/README .

The tool itself is here: http://downloads.nas-central.org/TOOLS/ALL_LS_KB_ARM9/ACP_COMMANDER/acp_commander.jar .

Do not use the "-o" option of the acp_commander. It will not work. Do not use "-addons" either, because it will copy incompatible software onto the box.

Is this guide working for the LS-VL only?

No, this should work for all current LS with current firmware (>= 1.36 and maybe even the ones before).
According to the firmware readme of the LS series, the following models all should work the same way:

  LS-CHL-V2
  LS-VL
  LS-WSXL
  LS-WVL
  LS-WXL
  LS-XHL

But you can also use the guide from the LS-XHL, but the one from the LS-XHL is more complicated.
Open Stock Firmware LS-XHL

What will be done?

We will use the "-c" feature of acp_commander. This will execute the command as user root (without a profile loaded).

We will also use the share "share" to copy some files for gaining access.

We will not use telnet but ssh for "opening".

What is necessary?

You need a private/public key pair for ssh conforming with the OpenSSH format.
You can create such a pair using Puttygen.exe on Windows. The private key will be used by Putty and the public key will be transfered to the LS and used by sshd. But be aware that the standard Puttygen export format for the public key is NOT conforming to the OpenSSH format! Use copy and paste from the result window of Puttygen instead.
On Linux you can create the keypair with ssh_keygen.

The guide

Please replace the IP address within the commandlines below against the one from your LS.

Put your public key in a file named authorized_keys and put the file onto the share "share" (do not use a subdirectory).

First we will create the directory for the ssh keys which the box should accept for logins as root.

  java -jar acp_commander.jar -t 192.168.172.1 -ip 192.168.172.1 -pw password -c "mkdir /root/.ssh"
  java -jar acp_commander.jar -t 192.168.172.1 -ip 192.168.172.1 -pw password -c "chmod 700 /root/.ssh"

Then we copy the file containing the keys into the created directory.

  java -jar acp_commander.jar -t 192.168.172.1 -ip 192.168.172.1 -pw password -c "cp /mnt/disk1/share/authorized_keys /root/.ssh/"
  java -jar acp_commander.jar -t 192.168.172.1 -ip 192.168.172.1 -pw password -c "chmod 600 /root/.ssh/authorized_keys"

If you have created the file authorized_keys on a Windows PC, be sure to run the dos2unix command on it. Otherwise you may get a "Server refuse our key" error.

  java -jar acp_commander.jar -t 192.168.172.1 -ip 192.168.172.1 -pw password -c "dos2unix /root/.ssh/authorized_keys"

Then we rename sshd_config for backup purposes.

  java -jar acp_commander.jar -t 192.168.172.1 -ip 192.168.172.1 -pw password -c "mv /etc/sshd_config /etc/sshd_config.ori"

Next we remove all references to PermitRootLogin and create a new sshd_config.

  java -jar acp_commander.jar -t 192.168.172.1 -ip 192.168.172.1 -pw password -c "grep -v PermitRootLogin /etc/sshd_config.ori > /etc/sshd_config"

Finally we add the PermitRootLogin Yes into the new sshd_config file.

  java -jar acp_commander.jar -t 192.168.172.1 -ip 192.168.172.1 -pw password -c "echo PermitRootLogin yes >> /etc/sshd_config"
  java -jar acp_commander.jar -t 192.168.172.1 -ip 192.168.172.1 -pw password -c "chmod 600 /etc/sshd_config"

Last we restart the sshd.

  java -jar acp_commander.jar -t 192.168.172.1 -ip 192.168.172.1 -pw password -c "/etc/init.d/sshd.sh restart"

Note: If you receive the message "Server refuse our key", the possibility is high, that you made a mistake using Puttygen.exe (you used the export key feature instead of copy & paste the public key out of the display window).
To solve this, you can try to copy the key file again using the command (assuming you put the exported file "key.pub" onto the share into the directory authorized_keys):

     java -jar acp_commander.jar -t 192.168.172.1 -ip 192.168.172.1 -pw password -c "ssh-keygen -i -f /mnt/disk1/share/authorized_keys/key.pub >> /root/.ssh/authorized_keys"

If your NAS is configured to use RAID1, you may need to change the path to the share from disk1 to array1 for the copy and ssh-keygen commands to work correctly

The result

Now you can connect as root via "ssh root@192.168.172.1".
You can do whatever you want with your LS, because it is open!

If you want to convert your data partition filesystem from XFS to ext3, look into the guide of the LS-XHL but be aware that there is a small difference explained after the link: Open Stock Firmware LS-XHL
When you did everything mentioned in the guide (which you have to do!), it is still not working due to a coding error by Buffalo.
Yes, they got it wrong again (do they have quality management, in form of code reviews, in their programming department at all?).
They coded their own shell function wrong. The comment says 3 parameters with the third parameter optional and the funtion is testing for "equal 2"??
Inside the function, they indeed use the third parameter to determine which filesystem to mount, with xfs as default. Without the possibility to pass a third parameter, the function will always mount as xfs.
So I had to patch /etc/rc.d/sysinit.d/S25start_data_array.sh line 622 within the section "${SUPPORT_RAID} = off".
Because mount_DataDisks_sub is ignoring the third parameter (that would be the filesystem), I replaced the line with:

  mount -t ${USERLAND_FS} ${DEV1} /mnt/disk1