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)
(18 intermediate revisions by 3 users not shown)
Line 8: Line 8:
 
=Is this guide working for the LS-VL only?=
 
=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).<br>
 
No, this should work for all current LS with current firmware (>= 1.36 and maybe even the ones before).<br>
According to the firmware readme of the LS series, the following models all should work the same way:
+
According to the [http://opensource.buffalo.jp/ls-x-140.html firmware readme] of the LS series, the following models all should work the same way:
  LS-CHL-V2
+
LS-AVL
  LS-VL
+
LS-CHL-V2
  LS-WSXL
+
LS-QVL
  LS-WVL
+
LS-SL
  LS-WXL
+
LS-VL
  LS-XHL
+
LS-WSXL
But you can also use the guide from the LS-XHL, but the one from the LS-XHL is more complicated.<br>
+
LS-WVL
[[Open Stock Firmware LS-XHL]]
+
LS-WXL
 +
LS-XHL
 +
 
 +
Alternatively you can use the guide from the [[Open Stock Firmware LS-XHL|LS-XHL]], which is more complicated.<br>
 +
See the last chapter for a speciality of the LS-CHL-V2.
  
 
=What will be done?=
 
=What will be done?=
Line 30: Line 34:
 
On Linux you can create the keypair with ssh_keygen.
 
On Linux you can create the keypair with ssh_keygen.
  
=The guide=
+
= 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).
+
Basic steps are:
 +
# Generate a SSH public key (if you not already have one)
 +
# Put the SSH public key into /root/.ssh/authorized_keys on your LS
 +
# Enable root login in /etc/sshd_config
 +
# Start sshd on the LS
  
First we will create the directory for the ssh keys which the box should accept for logins as root.
+
For that you will
  java -jar acp_commander.jar -t 192.168.172.1 -ip 192.168.172.1 -pw password -c "mkdir /root/.ssh"
+
# Generate a SSH public key (if you not already have one)
 +
# Create a text-file/script ''open-ls.txt''
 +
# Copy both your SSH public key and this script to your LS
 +
# Run the script remote on your LS using acp_commander
 +
# Finished :-)
  
  java -jar acp_commander.jar -t 192.168.172.1 -ip 192.168.172.1 -pw password -c "chmod 700 /root/.ssh"
+
Look below for a Linux/Unix script easing the next three steps.
  
Then we copy the file containing the keys into the created directory.
+
# Put your public key in a file named ''authorized_keys'' and put the file into the share "share" (do not use a subdirectory to make this guide work).
  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/"
+
# Put the lines below into a a file named ''open-ls.txt'' and put it in the same place.
 +
#!/bin/bash
 +
# open-ls.txt -- This script will be executed on the LS
 +
 +
# DIR is where we are
 +
DIR=$( cd $(dirname $0) ; pwd)
 +
 +
# Create the directory for the ssh keys and copy the pubkey there
 +
mkdir /root/.ssh
 +
chmod 700 /root/.ssh
 +
cp $DIR/authorized_keys /root/.ssh/
 +
chmod 600 /root/.ssh/authorized_keys
 +
# Required if 'authorized_keys' have een written on a Windows PC
 +
dos2unix /root/.ssh/authorized_keys
 +
 +
### Enable root login for SSH
 +
# Backup sshd_config
 +
cp -p /etc/sshd_config /etc/sshd_config.orig
 +
# Replace all "PermitRootLogin no" by "PermitRootLogin yes"
 +
sed -i '/PermitRootLogin/s/no/yes/' /etc/sshd_config
 +
chmod 600 /etc/sshd_config
 +
# Verify
 +
grep PermitRootLogin /etc/sshd_config
 +
 +
# Last we restart the sshd.
 +
/etc/init.d/sshd.sh restart
 +
# Run the script remote on your LS using acp_commander
 +
: In the next command-lines please replace the ''$IPADDR'' by the IP-address of your LS. If your NAS is configured to use RAID1, you may need to change the path to the share from ''disk1'' to ''array1''.
  
  java -jar acp_commander.jar -t 192.168.172.1 -ip 192.168.172.1 -pw password -c "chmod 600 /root/.ssh/authorized_keys"
+
:* Check whether both files are there (replace "disk1" with "array1" if you are running in RAID mode!):
 +
java -jar acp_commander.jar -t $IPADDR -ip $IPADDR -pw password -c 'ls /mnt/disk1/share/'
 +
:* Now let acp_commander execute the script on your LS
 +
java -jar acp_commander.jar -t $IPADDR -ip $IPADDR -pw password -c 'sh -x /mnt/disk1/share/open-ls.txt'
  
Then we rename sshd_config for backup purposes.  
+
As an alternative, here is a Unix/Linux script to ease copying the files and execute the copied script. There is no need to save it onto a file, simply copy and paste line by line into you shell, while adapting to your needs.
  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.
+
IPADDR=192.168.110.4
  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"
+
DISK=disk1
 +
PASSWD=password
 +
ACP="java -jar acp_commander.jar -t $IPADDR -ip $IPADDR -pw $PASSWD"
 +
 +
smbclient '\\'$IPADDR'\share' '' -c "put $HOME/.ssh/authorized_keys authorized_keys"
 +
smbclient '\\'$IPADDR'\share' '' -c "put open-ls.txt open-ls.txt"
 +
smbclient '\\'$IPADDR'\share' '' -c "dir"
 +
 +
$ACP -c "ls /mnt/$DISK/share/"
 +
$ACP -c "sh -x /mnt/$DISK/share/open-ls.txt"
 +
ssh root@$IPADDR
  
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).<br>
 
'''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).<br>
 
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):
 
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"
+
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
 
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
 +
 +
=== Firmware 1.42 Specialities ===
 +
If you have problems establishing a ssh connection, it could be possible that this is caused by a missing file of the PAM configuration.<br>
 +
By comparing 1.42 with 1.36, there is no "/etc/pam.d/sshd" anymore.<br>
 +
You can add this file yourself by copying this content (1:1 copy of 1.36) to the file:
 +
  auth    required  pam_listfile.so item=user sense=deny file=/etc/ftpusers onerr=succeed
 +
  #auth    required  pam_smb_auth.so debug
 +
  #auth    required  pam_unix.so nullok
 +
  auth    required  pam_unix.so
 +
  #auth    required  pam_winbind.so debug
 +
  account  required  pam_unix.so
 +
  #account required  pam_winbind.so
 +
  session  required  pam_unix.so
 +
Assuming that you put the content into a file named "sshd" on your share "share", you can use this command to copy the file to its final destination:
 +
  java -jar acp_commander.jar -t $IPADDR -ip $IPADDR -pw password -c 'cp /mnt/disk1/share/sshd /etc/pam.d/sshd'
  
 
=The result=
 
=The result=
Now you can connect as root via "ssh root@192.168.172.1".<br>
+
You can now connect as root via "ssh root@192.168.172.1".<br>
You can do whatever you want with your LS, because it is '''open'''!<br><br>
+
If you are using PuTTY on a Windows PC, remember to browse for the private key file under "Connection -> SSH -> Auth -> Private key file for authentication". <br>
 +
Now you can do whatever you want with your LS, because it is '''open'''!<br><br>
 
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]]<br>
 
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]]<br>
 
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.<br>
 
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.<br>
Line 77: Line 136:
 
   mount -t ${USERLAND_FS} ${DEV1} /mnt/disk1
 
   mount -t ${USERLAND_FS} ${DEV1} /mnt/disk1
  
 +
=Speciality of the LS-CHL-V2=
 +
For some reasons, the LS-CHL-V2 is excluded (by Buffalo) from the boxes supporting SSH connections.<br>
 +
The "exclusion" is done via the sanity application and prevents us from changing the SUPPORT_SFTP variable in the file "nas_feature" (and it doesn't matter if we patch the flash environment or not).<br>
 +
Therefore one needs to remove the following lines from the /etc/init.d/sshd.sh:
 +
  if [ "${SUPPORT_SFTP}" = "0" ] ; then
 +
    echo "Not support sftp on this model." > /dev/console
 +
    exit 0
 +
  fi
 +
And one needs to link the /etc/init.d/sshd.sh into the /etc/rc.d/extensions.d directory for automatic start at bootup (do '''not''' mess around with /etc/init.d/rcS):
 +
  ln -s /etc/init.d/sshd.sh /etc/rc.d/extensions.d/S99sshd
  
 +
[[Category:LS-AVL]]
 +
[[Category:LS-CHLv2]]
 +
[[Category:LS-QVL]]
 +
[[Category:LS-SL]]
 
[[Category:LS-VL]]
 
[[Category:LS-VL]]
 +
[[Category:LS-WSXL]]
 +
[[Category:LS-WVL]]
 +
[[Category:LS-WXL]]
 +
[[Category:LS-XHL]]

Revision as of 19:55, 24 March 2012

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-AVL
LS-CHL-V2
LS-QVL
LS-SL
LS-VL
LS-WSXL
LS-WVL
LS-WXL
LS-XHL

Alternatively you can use the guide from the LS-XHL, which is more complicated.
See the last chapter for a speciality of the LS-CHL-V2.

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

Basic steps are:

  1. Generate a SSH public key (if you not already have one)
  2. Put the SSH public key into /root/.ssh/authorized_keys on your LS
  3. Enable root login in /etc/sshd_config
  4. Start sshd on the LS

For that you will

  1. Generate a SSH public key (if you not already have one)
  2. Create a text-file/script open-ls.txt
  3. Copy both your SSH public key and this script to your LS
  4. Run the script remote on your LS using acp_commander
  5. Finished :-)

Look below for a Linux/Unix script easing the next three steps.

  1. Put your public key in a file named authorized_keys and put the file into the share "share" (do not use a subdirectory to make this guide work).
  2. Put the lines below into a a file named open-ls.txt and put it in the same place.
#!/bin/bash
# open-ls.txt -- This script will be executed on the LS

# DIR is where we are
DIR=$( cd $(dirname $0) ; pwd)

# Create the directory for the ssh keys and copy the pubkey there
mkdir /root/.ssh
chmod 700 /root/.ssh
cp $DIR/authorized_keys /root/.ssh/
chmod 600 /root/.ssh/authorized_keys
# Required if 'authorized_keys' have een written on a Windows PC
dos2unix /root/.ssh/authorized_keys

### Enable root login for SSH
# Backup sshd_config
cp -p /etc/sshd_config /etc/sshd_config.orig
# Replace all "PermitRootLogin no" by "PermitRootLogin yes"
sed -i '/PermitRootLogin/s/no/yes/' /etc/sshd_config
chmod 600 /etc/sshd_config
# Verify
grep PermitRootLogin /etc/sshd_config

# Last we restart the sshd.
/etc/init.d/sshd.sh restart
  1. Run the script remote on your LS using acp_commander
In the next command-lines please replace the $IPADDR by the IP-address of your LS. If your NAS is configured to use RAID1, you may need to change the path to the share from disk1 to array1.
  • Check whether both files are there (replace "disk1" with "array1" if you are running in RAID mode!):
java -jar acp_commander.jar -t $IPADDR -ip $IPADDR -pw password -c 'ls /mnt/disk1/share/'
  • Now let acp_commander execute the script on your LS
java -jar acp_commander.jar -t $IPADDR -ip $IPADDR -pw password -c 'sh -x /mnt/disk1/share/open-ls.txt'

As an alternative, here is a Unix/Linux script to ease copying the files and execute the copied script. There is no need to save it onto a file, simply copy and paste line by line into you shell, while adapting to your needs.

IPADDR=192.168.110.4
DISK=disk1
PASSWD=password
ACP="java -jar acp_commander.jar -t $IPADDR -ip $IPADDR -pw $PASSWD"

smbclient '\\'$IPADDR'\share'  -c "put $HOME/.ssh/authorized_keys authorized_keys"
smbclient '\\'$IPADDR'\share'  -c "put open-ls.txt open-ls.txt"
smbclient '\\'$IPADDR'\share'  -c "dir"

$ACP -c "ls /mnt/$DISK/share/"
$ACP -c "sh -x /mnt/$DISK/share/open-ls.txt"
ssh root@$IPADDR


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

Firmware 1.42 Specialities

If you have problems establishing a ssh connection, it could be possible that this is caused by a missing file of the PAM configuration.
By comparing 1.42 with 1.36, there is no "/etc/pam.d/sshd" anymore.
You can add this file yourself by copying this content (1:1 copy of 1.36) to the file:

 auth     required   pam_listfile.so item=user sense=deny file=/etc/ftpusers onerr=succeed
 #auth    required   pam_smb_auth.so debug
 #auth    required   pam_unix.so nullok
 auth     required   pam_unix.so
 #auth    required   pam_winbind.so debug
 account  required   pam_unix.so
 #account required   pam_winbind.so
 session  required   pam_unix.so

Assuming that you put the content into a file named "sshd" on your share "share", you can use this command to copy the file to its final destination:

 java -jar acp_commander.jar -t $IPADDR -ip $IPADDR -pw password -c 'cp /mnt/disk1/share/sshd /etc/pam.d/sshd'

The result

You can now connect as root via "ssh root@192.168.172.1".
If you are using PuTTY on a Windows PC, remember to browse for the private key file under "Connection -> SSH -> Auth -> Private key file for authentication".
Now 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

Speciality of the LS-CHL-V2

For some reasons, the LS-CHL-V2 is excluded (by Buffalo) from the boxes supporting SSH connections.
The "exclusion" is done via the sanity application and prevents us from changing the SUPPORT_SFTP variable in the file "nas_feature" (and it doesn't matter if we patch the flash environment or not).
Therefore one needs to remove the following lines from the /etc/init.d/sshd.sh:

 if [ "${SUPPORT_SFTP}" = "0" ] ; then
    echo "Not support sftp on this model." > /dev/console
    exit 0
 fi

And one needs to link the /etc/init.d/sshd.sh into the /etc/rc.d/extensions.d directory for automatic start at bootup (do not mess around with /etc/init.d/rcS):

 ln -s /etc/init.d/sshd.sh /etc/rc.d/extensions.d/S99sshd