đź“ť Originally published (in Japanese) at forge.workstyle.tech.
TL;DR Tailscale SSH was enabled on the Linux video source, while the client was a Mac. The video-only key used rrsync -ro, but the home .bashrc was still fetched. Tailscale SSH used tailscaled instead of sshd, so the authorized_keys restrictions did not apply.
Creating a Key Just for Fetching Videos
The machine generating the video content runs on Linux. I need to fetch the completed videos from a separate Mac. Since the sole purpose is to retrieve the videos, I decided to restrict the key used on the video machine to only allow read access to the output folder.
In the authorized_keys file on the video machine, I specified the rrsync read-only option -ro and the target folder for this key. Here’s a generalized example of the configuration:
command="rrsync -ro /path/to/deliver",restrict ssh-ed25519 AAAA...
Here, rrsync is used to restrict access via rsync. The -ro option ensures read-only access, and the following argument specifies the target folder. The restrict keyword adds additional constraints to the key.
On the Mac side, I configured ~/.ssh/config to use only the dedicated key for connecting to the video source (the name is just an example):
Host video-source
IdentitiesOnly yes
IdentityFile ~/.ssh/id_ed25519_video
I included IdentitiesOnly yes to prevent the system from selecting a different key, which could bypass the intended restrictions. With this setup, I’m ready to fetch videos using rsync with the specified key.
I Restricted Access, But Still Got Home
First, I tried retrieving a video from the target folder. This worked as expected. So far, so good.
Next, to test the restrictions, I attempted to fetch the .bashrc file from the home directory. This operation should have been denied. However, I was able to retrieve the file.
Despite setting read-only access, why could I read from the home directory? I questioned the rrsync configuration and key selection, but the decisive factor turned out to be the Tailscale SSH settings on the video side.
The connection was not being handled by sshd
On the video side, Tailscale SSH was enabled. In the Tailscale settings, RunSSH: true was configured.
Connections using Tailscale SSH are handled by tailscaled rather than the standard sshd. This connection followed that same path. The authorized_keys file is a configuration read by sshd. In other words, since sshd was not involved in the connection, the command= restrictions defined in the keys were not being applied.
This was the root cause. No matter how much you restrict the contents of authorized_keys, those restrictions will not work unless the connection is being handled by sshd, which actually reads that file.
When Tailscale SSH is enabled, SSH traffic via Tailscale does not pass through sshd. Therefore, authorized_keys restrictions do not take effect.
Handing Off to sshd
In my setup, I disabled Tailscale SSH on the remote (server) side.
tailscale set --ssh=false
Once this is configured, connections are handled by the regular sshd. This is when the command="rrsync ..." restriction defined in your authorized_keys file actually takes effect.
After making the configuration change, verify that the key restrictions work as intended. Don't just skim through the configuration file—sake points is actually executing both the permitted operations and the operations you intend to deny.
Checking 3 Points
We will verify the following three points:
- Accessing the target folder works: We will ensure that completed videos can be retrieved from the Mac side.
-
The home directory is denied: We will specify a file outside the target folder, such as
.bashrc, and verify that it cannot be retrieved. - Command execution is denied: We will attempt to run an arbitrary command on the remote connection and verify that it is rejected.
Simply being able to access the target folder is not evidence that read-range or command restrictions are actually being enforced. We must test both the permitted operations and the operations that should be denied.
Sometimes macOS's Built-in Rsync Fails
After fixing my configuration, I hit another snag. macOS's built-in rsync, which is based on openrsync, was rejected by rrsync. Using Homebrew's rsync worked fine.
Since rsync can fail even after fixing connection issues, if the same settings don't work, also check the client-side rsync version.
The Pitfall of Re-enabling Restrictions on Re-login
When you re-login to Tailscale with the --ssh flag, Tailscale SSH becomes active again. This changes the connection path, and the restrictions you set in authorized_keys for sshd will no longer be applied.
Don't stop after fixing it once; verify the Tailscale SSH settings even after re-logging in. You need to separately confirm that restrictions have been set on the key and that the connection path is using those restrictions.
Key takeaways
- Set the dedicated key to use rrsync -ro with the target folder in authorized_keys.
- Set IdentitiesOnly yes and the dedicated key in the Mac's ~/.ssh/config.
- If Tailscale SSH is enabled, run tailscale set --ssh=false on the video source.
- Check that the target folder can be fetched, while home files and command execution are denied.
- Check the Mac's rsync if rrsync rejects it, and verify Tailscale SSH remains disabled after logging in with --ssh.
Top comments (0)