harden(ssh): scope bulk sync tar extraction to .hermes

[Stark-X]

Summary

Fix a regression in SSH bulk file sync where tar extraction was performed at /, allowing archive path components like home/<user>/... to touch the remote home directory. This can break SSH access after a seemingly successful one-shot command.

The user-visible failure mode is:

• the agent uses the SSH backend for a one-shot command
• that command succeeds
• the bulk sync step widens the remote home directory permissions to something like 775
• the next SSH attempt fails because OpenSSH StrictModes rejects the home directory permissions

This change keeps SSH bulk upload scoped to ~/.hermes:

• stage files relative to the remote .hermes base instead of the absolute remote path
• reject any remote path that falls outside the sync base
• extract the tar stream into ~/.hermes instead of /
• add regression coverage to ensure the staging tree never includes home/<user> path components

Root Cause

The bulk uploader mirrored absolute remote paths in the temporary staging directory and then extracted the archive with tar xf - -C /. That meant the archive could contain parent directories such as home/<user>, and tar would apply those directory entries while unpacking.

If the local staging directories are created under a permissive umask, the archive can carry directory modes like 775 for home/ and home/<user>/. When those entries are extracted at / on the remote host, the existing remote home directory can be widened as a side effect, causing later SSH authentication failures.

Why This May Reproduce Only In Some Environments

This regression depends on both the buggy extraction behavior and the surrounding local/remote permission model.

In the reported environment:

• the local shell umask was 002
• a minimal reproduction showed staging directories being created as 775
• the remote SSH server used OpenSSH StrictModes yes

That combination makes the bug much easier to reproduce:

• local umask=002 means staging directories under home/<user>/... default to group-writable modes like 775
• extracting the archive at / can then apply those modes to the real remote home directory
• OpenSSH with StrictModes yes checks the user's home directory and files before accepting login, so the next SSH attempt may be rejected immediately

This means the bug is still in the code regardless of environment, but hosts with umask=002 locally and StrictModes=yes remotely are much more likely to see it as a hard SSH failure rather than a silent permission drift.

Testing

• source venv/bin/activate && uv run pytest tests/tools/test_ssh_bulk_upload.py tests/tools/test_ssh_environment.py -q

[Stark-X]

Follow-up context after rebasing this PR onto latest main:

The original #17767 failure mode has already been addressed upstream by #17898, which added --no-overwrite-dir to the remote tar extract command. That protects existing remote directory metadata from being clobbered and closes the main StrictModes lockout bug.

This PR is now intended as a narrower security hardening follow-up rather than the primary #17767 fix. Current main still builds the local tar staging tree from absolute remote paths via remote_path.lstrip("/") and still extracts the archive at /, so the archive can contain path components such as home/<user>/.hermes/.... With #17898 this should no longer overwrite existing directory modes, but it still leaves the bulk sync operation broader than necessary.

The change here scopes the tar stream to the remote Hermes directory itself:

• stage paths relative to $HOME/.hermes
• reject paths that escape that sync base
• extract into $HOME/.hermes instead of /
• keep the existing --no-overwrite-dir guard from fix(ssh): prevent tar from overwriting remote home dir permissions (#17767) #17898
• add regression coverage that the staging tree never contains a home prefix

So the remaining value is defense-in-depth: avoid archiving or extracting parent home-directory path components at all, and constrain bulk upload to the directory Hermes owns.

[kevhardy]

I am seeing this issue in my logs and this PR looks like the solution.

WARNING tools.environments.file_sync: file_sync: sync failed, rolled back state:
tar extract over SSH failed (rc=2):
tar: .: Cannot change mode to rwxr-xr-x: Operation not permitted
tar: ./home: Cannot change mode to rwxr-xr-x: Operation not permitted
tar: Exiting with failure status due to previous errors

[teknium1]

Merged via PR #30172 — your commit was cherry-picked onto current main with authorship preserved (commit eb51fb6). Thanks @Stark-X! Both the .hermes-scoped extraction and the path-escape rejection are now on main.