Buffalo NAS-Central Forums

Welcome to the Linkstation Wiki community
It is currently Mon May 28, 2018 10:58 am

All times are UTC+01:00




Post new topic  Reply to topic  [ 26 posts ]  Go to page Previous 1 2
Author Message
PostPosted: Wed Mar 03, 2010 6:24 pm 
Offline
Moderator

Joined: Fri Jun 29, 2007 10:39 am
Posts: 2604
Did you tried the script for enabling ssh via emergency.sh also?
The current firmware uses a flag from flash to determine if the
sshd should get started. enablesshd.sh sets this flag.

Btw. what fails if you try a "su -" when logged in via telnet and
user admin?

According to your /etc/shadow the root password IS empty.

_________________
Please do not use private mail (PN/M) to ask questions. Use the proper forum instead. (me)

If there is no verified backup of a dataset, the dataset, by definition, is unimportant. (c't 2012)

RAID (no matter which level) never ever substitutes a backup. (me)


Top
   
PostPosted: Thu Mar 04, 2010 9:46 am 
Offline
Total Newbie

Joined: Wed Mar 03, 2010 4:48 pm
Posts: 2
kenatonline wrote:
Did you tried the script for enabling ssh via emergency.sh also?
The current firmware uses a flag from flash to determine if the
sshd should get started. enablesshd.sh sets this flag.

Btw. what fails if you try a "su -" when logged in via telnet and
user admin?

According to your /etc/shadow the root password IS empty.


I did not try to enable ssh since it was up and running, just used reset psw script.
The answer was in wrong authentication, it was the same ether via ssh session or su command being in telnet session.

By now problem is solved, I did one more upgrade by using Shonk fw.

Thank you for your feedback,
Alexander


Top
   
PostPosted: Sun Mar 14, 2010 4:25 pm 
Offline
Newbie

Joined: Fri May 08, 2009 1:39 am
Posts: 7
In my experience the current Wiki instructions are not working for 1.24 f/w. I had a very similar outcome to Alexander. Let me give a few more details, and hopefully this will help someone understand what's going wrong.

    * The instructions appeared to work fine as far running the shell script to modify the stock firmware and flashing it to the LS-XHL.
    * Once the LS-XHL rebooted I could get in via telnet as admin, but could not su to anyone else one there. I was also getting "no default realm" messages on each login via telnet.
    * The root password was not clear when I got in as admin, but I could clear it with an emergency.sh script.
    * However, once the root password was cleared I still could not su to it, not could I su to any other unpriviledged user that I might create in the Webui
    * I tried setting the suid bit on /bin/su, but that only changed the error message when using su to "unable to create/modify session"
    * I tried adding a pts/0, pts/1.. pts/9 as addition lines to /etc/securetty to let me login as root from telnet but I still got authentication errors from the root login, even though I think I had a valid password for root.

I notice that the open_firmware.sh script on the Wiki is still changing, and the latest one has additional lines commented out regarding the ssh startup scripts. I'm not sure if these changes would make a difference to the experience that I had with the current instructions.

Any help in understanding the above scenario would be appreciated.


Top
   
PostPosted: Mon Mar 15, 2010 11:46 am 
Offline
Moderator

Joined: Fri Jun 29, 2007 10:39 am
Posts: 2604
I can't explain why, but something changed since the time I verified
the open_firmware.sh script on my spare XHL.
I could replicate the su failure with a current downloaded firmware
1.24 of Buffalos european page.
So I made a fix to the script open_firmware.sh which should solve
the problem not being able to switch to root via su. At least it solves
the problem on my spare XHL with the current 1.24.
If you do not want to delete the user config, you have to use the
freerootpw.sh as emergency.sh to reset roots password.

@crazzell:
Could you please test this?

_________________
Please do not use private mail (PN/M) to ask questions. Use the proper forum instead. (me)

If there is no verified backup of a dataset, the dataset, by definition, is unimportant. (c't 2012)

RAID (no matter which level) never ever substitutes a backup. (me)


Top
   
PostPosted: Mon Mar 15, 2010 4:09 pm 
Offline
Newbie

Joined: Fri May 08, 2009 1:39 am
Posts: 7
I will test this when I get home from work. Expect a reply in 24 hours. Thanks!


Top
   
PostPosted: Mon Mar 15, 2010 10:27 pm 
Offline
Newbie

Joined: Fri May 08, 2009 1:39 am
Posts: 7
I tried again with your modified open_firmware.sh. I had some success, but also some failures as reported below:

1) sshd is not started, can only use telnet
2) I can telnet as an ordinary user but I see that /etc/shadow is still populated with users and passwords from a previous life. The root password is not cleared, even though I did check the box to clear the user config when flashing the new firmware with debug enabled. Note that I only updated the hddrootfs.img, having unchecked the boxes to update BOOT, KERNEL and initrd. I totally don't understand where it is caching the old password file, but there it is.
3) I managed to become root because I knew the old root password su - root works from telnet. I don't know whether clearing root password out with emergency.sh would have worked as well, since I didn't need to try.
4) I tried to start sshd using /etc/rc.d/extensions.d/S40sshd.sh start, but I immediately got an error message where the script tries to redirect output to /dev/console. /dev/console is a non-existent device on my machine so that is why the startup script doesn't get very far. If I remove that redirection from the script, sshd starts and generates a bunch of keys, but also some warning messages.
5) Tried to use Putty from a windows machine to get in via ssh. This warns me that keyboard direct verification by password is being used, but I can't get any of my known passwords accepted.
6) Tried to use ssh root@192.168.1.xx from a Ubuntu laptop. It asks me for a password, but if I just press return three times it then asks me for root's password and I can log in via ssh.

In essence this is a great improvement because I can get a root shell, assuming that clearing out the root password would be effective (I didn't try that since I would risk losing root access).

Something is still very strange about the way sshd is authenticating. I've never seen this before.


Top
   
PostPosted: Tue Mar 16, 2010 3:48 am 
Offline
Newbie

Joined: Fri May 08, 2009 1:39 am
Posts: 7
I was able to get ssh working by using ssh-keygen on my Ubuntu laptop, and copy/pasting the public key into ~root/.ssh/authorized_keys. Users who habitually use ssh with password-less authentication would not notice any issues, but many of us never bother generating public/private key pairs, and so would tend to conclude the ssh is not working.

I was able to confirm that "passwd -d root" allows a null password to be used for "su - " for someone logging in via telnet.

I still don't understand I don't get an empty root password when flashing the firmware. If this not just my issue, I would suggest an init script that will do the job on first boot and then delete itself.


Top
   
PostPosted: Tue Mar 16, 2010 11:31 am 
Offline
Moderator

Joined: Fri Jun 29, 2007 10:39 am
Posts: 2604
The startup failure of sshd is somewhat related to a new way Buffalo
handles the configuration.
There is a check for an environment variable named SUPPORT_SFTP.
This one is set in some kind of NAND flash.
That is the reason for the enablessh.sh script. Look into the script and
you will see what to do, or start the script while logged in as root via
telnet.
After a reboot (or a restart via the sshd script), sshd should get started.
The creation of the keys is intended. Each server has to have its own keys.
So Buffalo can NOT provide pregenerated keys but has to create them on
first start of sshd (and exactly that is done in their sshd.sh).

I do not use password authentication via ssh, so I did not test this.
Maybe I can find some time next weekend to solve this too.

My assumption for the "restore" of the original /etc/shadow is the initrd
doing some "magic". And since you did not replaced the initrd, this could
be the reason (but this is just a guess).
I will try to analyse this next weekend too.

_________________
Please do not use private mail (PN/M) to ask questions. Use the proper forum instead. (me)

If there is no verified backup of a dataset, the dataset, by definition, is unimportant. (c't 2012)

RAID (no matter which level) never ever substitutes a backup. (me)


Top
   
PostPosted: Tue Mar 16, 2010 5:21 pm 
Offline
Newbie

Joined: Fri May 08, 2009 1:39 am
Posts: 7
Thanks,

I already removed the redirect to /dev/console and the following exit 0

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


==>

Code:
if [ "${SUPPORT_SFTP}" = "0" ] ; then
        echo "Not support sftp on this model."
fi


I guess the nice way to have done this would have been using your script as follows:

Code:
#!/bin/sh
/usr/local/bin/dumpnf > /mnt/disk1/share/nas_feature
if [ -f /mnt/disk1/share/nas_feature ] && /bin/grep -q "SUPPORT_SFTP=0";
then
  /bin/sed -i 's/SUPPORT_SFTP=0/SUPPORT_SFTP=1/' /mnt/disk1/share/nas_feature
  /usr/local/bin/setnf < /mnt/disk1/share/nas_feature
fi


Again, thanks for your excellent work here. :D


Top
   
PostPosted: Fri Mar 19, 2010 8:51 am 
Offline
Moderator

Joined: Fri Jun 29, 2007 10:39 am
Posts: 2604
I found the reason, why it is impossible to login via ssh
as user root using password authentication.
The PAM on the LS is configured to deny authentication
for all users contained in file /etc/ftpusers. "root" is part
of this group of users.

To investigate the problem regarding the "etc/shadow"
magic, I haven't had enough time yet.

_________________
Please do not use private mail (PN/M) to ask questions. Use the proper forum instead. (me)

If there is no verified backup of a dataset, the dataset, by definition, is unimportant. (c't 2012)

RAID (no matter which level) never ever substitutes a backup. (me)


Top
   
PostPosted: Mon Mar 22, 2010 6:30 am 
Offline
Newbie

Joined: Fri May 08, 2009 1:39 am
Posts: 7
I can confirm that commenting root out of the list of the list of ftpusers helps, and that change seems to survive between reboots.

I also found that other users were getting shut out of ssh by means of a file called /etc/sftponly_config, which contains lines like the following:

Code:
user admin
allowssh no


But this file is being regenerated every time "nas_configgen -c sftp" is called from the sshd.sh startup script. This one had me chasing my tail for a while.


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 26 posts ]  Go to page Previous 1 2

All times are UTC+01:00


Who is online

Users browsing this forum: No registered users and 6 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Powered by phpBB® Forum Software © phpBB Limited