Feature request: SSH key on the FAT partition (and bug report)

[ziggurat]

Bug Report
The permissions of /root/.ssh is wrong, so if you push your ssh key using ssh-copy-id it will not work, because you need the correct permissions on both the .ssh folder and the public key so that it is not readable by other users. It has been like this for years I am sorry I didn't report it yet. Permission 600 for the .ssh folder will work. It is especially annoying since this is reset back to stock with every linux image update.

Feature Request
A way to have the ssh keys saved on the FAT partition, maybe configure sshd to also look for autorized_keys in the linux folder? https://www.ssh.com/academy/ssh/authorized_keys/openssh I don't know if the permissions restrictions would make this difficult?

I also would like the bashrc or maybe the whole home folder to be on the fat or in a different partition, but I know thats a big ask, the authorized keys covers, and the current new changes covers almost everything I change in the linux image now. I am super grateful

[boilop]

- I agree that the permissions of /root/.ssh/ are a bug/mistake and it can easily trip people trying to use SSH keys.
- I also concur with your feature request, it would be useful. And not just for this file, but a number of other ones which make sense to change currently and which get clobbered at reboot.

I actually had started fixing this bug and adding this feature a while back myself, but because of the way Linux is present in the repo, it's pretty odd to send a pull request and I ended up not doing it. If it's acceptable to send a PR for rootfs.tar.bz2, I'm happy to do it.

In general it would be good to cleanly separate the "stateless" Linux image, which can be upgraded and some "stateful" set of files which would have to be preserved (of course this is kind of how it works today for Wifi configuration etc). The issue is the more files we add to the "stateful" set, the higher the burden is in terms of backward compatibility whenever one wants to update the "stateless" Linux image.

[Note: my own solution for this is to create a small image in /media/fat/linux/stateful-partition.img for files that should be preserved, loopback mount it and then have symlinks to those files on the main Linux image (this allows having proper file permissions, types, attributes, etc). It's possible that people would prefer "naked" files rather than the loopback image so that they can modify them more easily from a Windows environment - authorized_keys files are pretty unique in being sensitive to file AND path permissions]

P.S.: In the meantime, I added a script in /media/fat/Scripts to restore /root/.ssh permissions, as well as my SSH key (and a few other things which are clobbered when Linux gets updated, such as the device's SSH key [which you have to regenerate if you want MITM security]). Note that since the latest Linux update you could call such a script from /media/fat/linux/user-startup.sh automatically on boot, even after an update to the Linux image.

[OneEightZero]

It's interesting you bring this up, because I remember ssh keys working accurately around a year and a half ago, and suddenly stopped. I never investigated why. Granted, this only resulted in not having to type the super secure default password for the MiSTer (heh), BUT it was pretty handy.

Thank you for figuring this out.

[elvis]

I have a small configuration script sitting on the FAT partition with all my customisations, including SSH keys and permission fixes.

Any time an update clobbers the Linux volume, I SSH in one time with the default password, run the script, and I'm good to go again.

A minor inconvenience, but it's easy enough to set up and only requires running once in a while.

[cursedverses]

I was thinking about adopting an overlay FS in order to use a small SD card for the base system and a (large) USB drive for updates and ROMs (especially as these CD systems start popping up).

Maybe something like that for combining separate system/configuration partitions would work?