Ssh id_rsa and authorized_keys persistence

[ghormoon]

Hi,

I’ve found a workaround how to set cronjob in /usr/local/config/config.xml to rsync backup to remote location (another my cloud)
though I’ve found out after reboot, it also removes ssh keys and authorized_keys files, can I make them persistent too somehow?

thanks,
Gh.

[Wierd_w]

If you look closely, the key files are symlinked to the /usr/local/config folder. (Will give specifics soon when I go home and can look.) That is a writable, persistent location. Replacing the files that get symlinks will result in persistently replaced keys. It is one of the first things I did with my Gen2 mycloud. (Did it because my linux box consistently refused to connect to the MyCloud over ssh, due to depreciated DSA keys being on the device. Replaced them with proper RSA style keys, and all was peachy keen.)

As for other things used by rsync (Secrets, allowed hosts, etc… you are going to need a user script to run to fix all that automagically.)

[ghormoon]

well, server keys are one thing, but that/s not the issue,
the issue is /root/.ssh folder, either I somehow find out where it came from, of I’ll have to do some hack to copy the id_rsa and authorized_keys from somewhere

[Wierd_w]

It gets generated on the fly by the web GUI, and the init script spaghetti.

That is why I said you will need to have some kind of user-init that runs last, that cleans house and sets everything right. That way your secrets file and pals are always what YOU want them to be.

WD made this device very difficult to properly administer. They went out of their way to make it that way, needlessly. (If what I am seeing from Fox_exe’s work is true, there is precisely ZERO reason for this huge ramdisk based root filesystem bologna, other than to hamfistedly try to enforce system policies on users. It apparently boots just fine with a real root filesystem, when you decide to screw the warranty coverage and take matters into your own hands.)

(sarcasm) The reason the files get created from scratch every time is because of the ramdisk based root filesystem. They did not feel that the secrets file, the allowed hosts, etc— needed to be modified by end users, so persistence was not necessary. After all, this is a consumer device, what are you doing trying to do real administrator type things with it, like doing scheduled rsync with a remote host? You are supposed to use this thing to watch all those movie files from! (that’s why it prioritizes their ■■■■■■■■ media scanner daemon!) (/sarcasm)

I wont bother trying to defend their bull on this, because it is indefensible in my opinion. Instead, I will just point out that you need some kind of user init script. If you dont mind voiding your warranty, you can use Fox_exe’s wdcrack package. It works great for that.

There are other things, like hijacking the config.xml, which you already mentioned, to add a cron job. One thing you could do would be to have the cron job md5 the files in question, and if the hash return is the same as the stock generic’s, it fires off the replacement process, otherwise does nothing.

How you would choose to go about that scripted replacement is entirely up to you, just that is what you will need to do.

(Changing the GUI so that it does not bootstomp your changes all the time is a wasted effort; WD made sure that they are in a read only cramfs container, so you cant just fix their stuff to not be arrogant without fully repackaging the container, etc. Like I said, they went out of their way to make it hard to actually administer.)

[ghormoon]

ok, just to confirm, is there some less hacky way to run the script than a cronjob (with the means we have currently. if it was my device, not my parents, I’d go for firmware replacement, or better, don’t buy this type of device at all :))? my idea was just to rsync it from the data area to /root/.ssh two minutes before the nightly rsync job, assuming it won’t manage to delete them in between. hopefully

[Wierd_w]

WDcrack is basically leveraging how WD did “User installable applications”. It works by making the MyCloud pretend that it is a model that actually supports this feature, because the GUI code is exactly the same as that used on the more expensive models, and literally an ID flag in a config file controls the behavior.

The way WD does it, is it treats these applications’ start-stop script like a user-level init script, and these live on the persistent data volume.

The wdcrack package is an installable package that contains a script that does exactly one thing:
It replaces the afore mentioned config file found in the ram-backed root file system, with a symbolic link pointing to a persistent copy of the doctored config file, which then “naturally” enables you to install more applications.

At its core, it is, again-- JUST a user init script. You can put ANYTHING inside it. You can treat it as if it were /etc/rc.local

If you want to completely replace the OS, Fox_Exe has your back again— He has created a minimalist deployment of Debian, and instructions for installation, that completely replaces the WD software and runs straight up off the spinny disk. It even has a much more modern kernel.

To give you an idea of what I have it doing… Here is my version of the script wdcrack runs.

#!/bin/sh

INSTALL_DIR=$1
ORIGINAL_FILE=/usr/local/model/web/pages/function/define.js

rm $ORIGINAL_FILE
ln -sf $INSTALL_DIR/define.js $ORIGINAL_FILE
ln -sf $INSTALL_DIR/web /var/www/WDCrack

## Save old reboot command with new name
mv /usr/sbin/reboot /usr/sbin/reboot_old

#
# Begin binary copy hijack; Place missing/needed binaries in proper places
cp -R /mnt/HD/HD_a2/extras/* /
## End binary copy hijack

## Initialize iSCSI ■■■■
iscsictl --init

## Initialize virtual volume manager ■■■■
vvctl --init


## Do the needful for software raid over iscsi
##

## Sleep a few seconds for iscsi LUNs to mount
sleep 2

## Do the needful to make this silly thing let go of the USB device
umount /dev/sdb1
usbumount /dev/sdb

## Forcibly create new md device node
echo md_1 > /sys/module/md_mod/parameters/new_array

## Use mdadm to assemble our array
mdadm --assemble /dev/md_1 /dev/sdb /dev/sdc

## Use static partx to update available partitions on /dev/md* device
partx -u /dev/md_1

## Mount the discovered partition at our share mountpoint.
mount -t ext4 /dev/md_1p1 /mnt/HD/HD_a2/RaidTest

## End doing the needful
##