Attaching accounts to sftp

WD Legacy Products My Book Live Duo
1

In short: How do I set up sftp access to the NAS shares?

So I can ftp into my MBLD with no problems using a created (non-admin) account, and I can ssh in as ‘root’, and I can sftp in as ‘root’.

What I’d like to be able to do is sftp in with the created account ID, ideally restricted to the shares configured through the web interface - so the same as the FTP access, but with the added security of SFTP rather than FTP.

Anybody tried setting this up yet and able to offer some hints? A quick Google suggests creating a separate folder structure for those users and modifying the SSH config, but I’m not sure how to do that without breaking the existing setup with users matched to shares.

I could have a play, but as this is my only NAS I’m keen not to need to reflash it :slight_smile:

2

bumping on this one dude

try talking to Myron since he’s more acquainted with SSH

3

I’ve sort of looked at this one too but am too scared of changing the SSH configuration in case I do something wrong what kills the SSH daemon or messes up the configuration that SSH access is no longer possible.

My guess is that you will need to add users to the line that starts with AllowUsers within the file  /etc/ssh/sshd_config.

WD has configured it so the only allowed user is root.  I guess you can add additional users to this line, restart the SSHD and aditional users will be allowed to connect via Telnet and SFTP.

1 Like
4

DISCLAIMER : Messing up the stuff below can and will prevent you using SSH to access your My Book Live Duo. It’s your own fault, go buy a new one.

Ok, I’ve had a play. First up, cheat like **bleep** in case I break it:

ssh root@<MBLD-IP-address>
cd /shares/tmp
cp /etc/ssh/sshd_config ./sshd_config_bak
ln -s /etc/ssh/sshd_config

I can now use the shared drive “tmp” to edit and update the sshd_config file, without needing to ssh into the box. (Obviously this is a foolish thing to enable, which is why it’s only on a temporary share.) I’ve also taken the precaution of backing up the current file.

Next, editing the sshd_config file. I’m using vi so that I can edit on the NAS itself, rather than trusting CR-LF conversions via the network share (and because the NAS doesn’t have emacs installed - but that’s a whole other flamewar). As suggested by Myron, found the line

AllowUsers root

 Changed it to

AllowUsers root pc-backup

(where pc-backup is the user ID I’ll configured into my sftp client on the PC)

Finally enter the command

/etc/init.d/ssh restart

 I didn’t log out from that ssh session in case I’d broken it all. Instead I opened a new ssh and tried to log in as pc-backup: ssh access working perfectly. Logged on, home directory is /shares, standard unix permissions are preventing me from access shares (and other files) to which I shouldn’t have access.
Try to log in with sftp: Working perfectly.

Happy :slight_smile:

So now that I’ve enabled SSH for non-root, I decided to disable it for root. If I need root access, I can just ssh in as pc-backup (or create another account) and sudo/su to get root. Technically this is no more secure than logging in directly as root, but I don’t like leaving remote root login enabled anywhere. Before I disable root login though, I need to make sure I can use sudo as pc-backup.

So alt-tab back to the ssh session in which I’m still logged on as root, find and edit the file /etc/sudoers
After the line

root ALL=(ALL) NOPASSWD: ALL

 I added the line

pc-backup ALL=(ALL) ALL

Saved, exited, tested on my pc-backup ssh session before doing anything else. (This is unix, I know how badly it’ll go wrong if I don’t test everything every time I touch it) :slight_smile:

Now back to /etc/ssh/sshd_config and the two lines

PermitRootLogin yes
AllowUsers root pc-backup

 become

PermitRootLogin no
AllowUsers pc-backup

Another quick test, and I’m no longer able to ssh in as root, but I can ssh (and sftp) in as pc-backup, and if I need to I can use sudo to perform actions as root.

Sensible next step that I haven’t tried yet:
http://blog.zioup.org//2008/iptables_recent/

I need to learn more about iptables first…

Final step: clear the backup and the symbolic link from the ‘tmp’ share.

All done :slight_smile:

1 Like
5

I am waiting for my Rasberry PI (  http://www.raspberrypi.org/ ) to arrive so I can put Debian Linux image on a 4Gb SD card and play with Linux.  It’ll be perfect because I can try all sorts of stuff and I’m sure my exotic experemtation I plan will destroy the Linux OS many times over for me to just resurrect by just writing a factory default image back onto the 4Gb SD card.

I can try things on there before even begin to think about trying anything on the Duo, but to be honest I would prefer to leave the Duo’s OS alone.  I’ll kust make sure that root’s password is very difficult to guess.  Like impossible to guess!

6

Very sensible - I’ve been playing with Linux since the early 90s so although I don’t necessarily know specific tools (e.g. OpenSSH and iptables) I’m confident about messing with the internals to a fair extent. Your approach is far more prudent and I wish I had that patience :slight_smile:

Regarding root passwords, it would be trivial to disable root access via password and force use of an SSH key exchange. I decided against that as I’m at far higher risk of losing the key than I am of having my root password hacked. I’m also not going to post how to achieve it, partly because I can’t test it (without doing it) and partly because it’s so much more likely to leave the device unaccessible via ssh.

7

Exactly.  Me thinks it’s better to practice and experiment on a sactificial installation of Linux and once proven and fully understood, to implement on the device that can be easily trashed and a wonderful thing about the Rasbery PI…  There is a downloadable image of Debian Linux.  :smiley: