linux-timemachine icon indicating copy to clipboard operation
linux-timemachine copied to clipboard

Restricted ssh commands compatibility (rrsync)

Open Jip-Hop opened this issue 2 years ago • 5 comments

I have restricted the commands SSH users can run to only rrsync using the command options in the SSH authorized_keys file. With rrsync I can allow access to only a certain directory (and optionally provide read-only access) and block shell access.

With this setup linux-timemachine fails:

timemachine user@server:/rsynctest ~/rsynctest/ -- --verbose
/usr/bin/rrsync: SSH_ORIGINAL_COMMAND='test -d /rsynctest' is not rsync

I have commented out these lines: https://github.com/cytopia/linux-timemachine/blob/2fe23f3402404edaa947a27811a72b0d97fcfb3a/timemachine#L371-L375 Now the backup seems to complete successfully.

Would it be possible to not use test -d in this case? Perhaps the rsync command itself could be used to check if the source directory exists? Else if skipping this test doesn't cause issues, perhaps a new cli flag could be added?

Jip-Hop avatar May 15 '22 14:05 Jip-Hop

Now the backup seems to complete successfully.

This is because there is no dir check on an existing directory. Try to play around with edge cases, where the directory does not exist, or is a file or a symlink, etc.

Besides, a little bit later down the lines, there is also a test -L check required for incremental backups. I guess this might also be an issue on your side.

The test command currently works well and keeps the source simple. I honestly don't see a way of replacing them. Feel free though to make suggestions and always keep edge cases in mind.

On the other hand, why don't you just allow the test command as well?

cytopia avatar May 15 '22 15:05 cytopia

keeps the source simple

One of the great things about linux-timemachine :)

If I were to allow the test command, users could probe for files outside their restricted directory. Besides, test alongside rrsync would require writing a wrapper script.

The test -L check would be an issue if my destination is accessed via SSH. But I'm only using my SSH server as source (made it read-only with rrsync). So that's not a problem in this case.

I was thinking maybe instead of test something like this:

if [[ $(rsync "${directory}" . --dry-run 2>/dev/null) == "skipping directory"* ]];then echo "It is a directory"; fi

Tested with a file, directory, symlink and nonexistent file.

I know it's ugly, but does not require another command besides rsync and works with rrsync xD

Jip-Hop avatar May 16 '22 08:05 Jip-Hop

If I were to allow the test command, users could probe for files outside their restricted directory.

Isn't that something you could do with a shell anyways?

if [ -f ./some_file ]; then echo "some_file exists"; fi

cytopia avatar Jun 07 '22 16:06 cytopia

~~You can also use the sed command (also used in the script) to probe for files:~~ Nvm, sed is only run locally

> sed -i'' 's///' file
sed: -e expression #1, char 0: no previous regular expression

> sed -i'' 's///' fileno
sed: can't read fileno: No such file or directory

cytopia avatar Jun 07 '22 16:06 cytopia

Isn't that something you could do with a shell anyways?

Yes, but my plan was to block shell access and only allow rrsync over SSH. So users won't be able to run the commands you suggested (which is good) and can't probe or access files outside of their restricted directory.

However then they also won't be able to run the test command and linux-timemachine won't work.

So that's why I suggested to not rely on test, or find a way to replace test with an rsync command (which rrsync would allow).

For the time being I'm chrooting SSH users to their home directory, so they can't use rsync at all...

Jip-Hop avatar Jun 07 '22 18:06 Jip-Hop