Locked out of SSH by Security Keys!

Hi Guy’s

I’ve got myself in a bit of a problem. I noticed that I was getting lots of attacks on my “MyBookLive” from external IP addresses so I decided to only allow SSH connectivity via security key’s, unfortunately I’m now locked out of the drive. I’ve tried resetting but that does not work, do you have any other ideas of how I can get back in without loosing data?

Thanks
Kevin

My only guess is that you’ll need to back up the data to another unit, then do a factory restore via the Web UI.

How is your MBL getting “attacked” from the outside?    Do you have SSH port-forwarded on your router or something?

Yes I’m using this NAS as a remote backup for an identical NAS located at my office. I saw the attempted SSH logings comming from China and Brazil, and thought I would tighten up the security. As I was using key encryption over SSH for the “rsync” command I assumed it would be no problem, but after restarting the SSH daemon I’m no longer able to access the backup NAS. The problem is that if I delete all the data on the backup NAS I will have to rebuild it and then re-sync all the data with the working NAS at the office. Many hours/days of work during which time I have no backup! So I’m still hoping someone has a better alternative. I’m on the latest FW, and am wondering that if I downgrade and then upgrade the FW on the backup this would reset the SSH access rights without deleting all my data, but I’m not sure if I’m able to do manual FW changes without SSH access? Any help would be greatly appreciated. Kevin

Hi Guy’s

OK so I backed up all my data and did a full factory restore, but I’m still unable to login with SSH.

I get the following message from “PuTTY”

"Disconnected: No supported authenication methods available (server sent: publickey)

I need to replace the SSH conf file that I edited with the default one, but obviously that’s not done with a full factory restore.

Anyone have any ideas on how I can get back in?

Thanks

Kevin

It’s a bit of a guess, but possibly an upgrade procedure of the firmware, even if it’s the same version as the current on, rewrites the config file. I’ve done a single upgrade (and won’t ever risk it again unless strictly necessary) and I remember that something changed with SSH, but I can’t remember what exactly. You might be lucky.

Best of luck!

Hi rjm05,

I was thinking exactly the same, so I re-installed the latest FW (02.09.11-053) and that has fixed the problem on one of my NAS systems!

The problem with the other NAS is that it was upgraded to FW 02.11.12-006, which has been withdrawn by WD and is no longer available for download, when I tried to use the 02.09.11-053 FW the load failed, I assume because it thinks it is a FW downgrade and won’t allow it.

So now i need to either get hold of the 02.11.12-006 FW or make the 02.09.11-053 FW look like an upgrade.

Does anyone know where I can download this now withdraw FW, or how to do the FW downgrade?

All help would be much appreciated!

Thanks

Kevin

Hi there!

Im quite a newbie to all this, but as I recently acquired a MBL 3GB, I wanted to ask you this. (I have Featurepack installed, and am successfully running Transmission). I wondered how you actually learned about the attempted logins from unwanted clients. Is there freeware that allows me to check this? As I have enabled SSH, I do feel this is quite a risk. I would therefore like to hear your advises on how to keep the device as secure as possible. Is it for instance possible to allow SSH traffic only from within the network, combined with a strong password? What are the other main security liabilities?

Best,

Bart

Logins can be logged in /var/log.

Thanks! I managed to open the file form PuTTY and didnt see any activity from unknown IP addresses. Managed to change the root password too, so all in all guess it should be fine now. Is there, by the way, not any software that shows me the logged on clients on the NAS? both external and internal? haven’t seen this feature in the WG2Go package.

oh a final question, I read somehweere that the root password is stored under a standard file with the .txt extension. Is this true, so in that case, it is almost useless to change it since it can easily be read out by advanced users?