lhumina_code/hero_compute

Fork 0

VM deploy: SSH login fails because /root, /root/.ssh, and authorized_keys are owned by `ubuntu` instead of `root` #100

New issue

Closed

opened 2026-04-22 09:51:42 +00:00 by rawan · 3 comments

rawan commented

2026-04-22 09:51:42 +00:00

Member

Summary

After deploying a VM via hero_compute, SSH into root@<vm-ip> with a provisioned key fails with Permission denied (publickey). Root cause is that the VM's /root tree (including /root/.ssh/authorized_keys) is owned by the ubuntu user/group instead of root, so sshd refuses to read the keys when logging in as root.

Reproduction

Deploy a VM through hero_compute.
Attempt ssh root@<vm-ip> with the SSH key that was injected during provisioning.

Observed permissions inside the VM

root@new:~# ls -ld /root /root/.ssh /root/.ssh/authorized_keys
drwx------ 3 ubuntu ubuntu 4096 Mar 26 12:53 /root
drwx------ 2 ubuntu ubuntu 4096 Mar 26 12:53 /root/.ssh
-rw------- 1 ubuntu ubuntu   96 Apr 21 21:52 /root/.ssh/authorized_keys

Modes are correct (700 / 600) but the owner/group is ubuntu:ubuntu. sshd's StrictModes check requires /root/.ssh and authorized_keys to be owned by root when logging in as root.

ssh -v output

debug1: Authentications that can continue: publickey
debug1: Offering public key: RawanMostafa08 ED25519 SHA256:8wDIjG+oaxM0Z800MNkjY84zGY0MvkMMuCN5L2jtdlo agent
debug1: Authentications that can continue: publickey
debug1: Offering public key: rawan@hero-test ED25519 SHA256:xNPAtOIsbFGHo1d1ikhfXZ1ip0BQ6pwdgUJVzSscinM agent
debug1: Authentications that can continue: publickey
debug1: Trying private key: /home/rawan/.ssh/id_rsa
debug1: Authentications that can continue: publickey
debug1: Trying private key: /home/rawan/.ssh/id_ecdsa
debug1: Trying private key: /home/rawan/.ssh/id_ecdsa_sk
debug1: Trying private key: /home/rawan/.ssh/id_ed25519_sk
debug1: Trying private key: /home/rawan/.ssh/id_xmss
debug1: Trying private key: /home/rawan/.ssh/id_dsa
debug1: No more authentication methods to try.
root@44f:1db8:de24:7601:f2f9:ae0e:443c:eb69: Permission denied (publickey).

Expected

After deployment, /root, /root/.ssh, and /root/.ssh/authorized_keys should be owned by root:root so that ssh root@<vm-ip> using the injected key works out of the box.

Likely cause

The cloud-init / provisioning step that writes the root user's authorized_keys is running as the ubuntu user (or mounts the image as that UID), leaving /root and its contents owned by ubuntu:ubuntu.

Workaround

Inside the VM (via console or as ubuntu + sudo):

sudo chown -R root:root /root

Suggested fix

In the VM provisioning path in hero_compute_server (cloud / cloud-init setup), ensure that when we inject the root SSH key we also chown root:root /root /root/.ssh /root/.ssh/authorized_keys (or run the write step as root), and that no part of the pipeline leaves /root owned by ubuntu.

## Summary After deploying a VM via `hero_compute`, SSH into `root@<vm-ip>` with a provisioned key fails with `Permission denied (publickey)`. Root cause is that the VM's `/root` tree (including `/root/.ssh/authorized_keys`) is owned by the `ubuntu` user/group instead of `root`, so `sshd` refuses to read the keys when logging in as `root`. ## Reproduction 1. Deploy a VM through `hero_compute`. 2. Attempt `ssh root@<vm-ip>` with the SSH key that was injected during provisioning. ## Observed permissions inside the VM ``` root@new:~# ls -ld /root /root/.ssh /root/.ssh/authorized_keys drwx------ 3 ubuntu ubuntu 4096 Mar 26 12:53 /root drwx------ 2 ubuntu ubuntu 4096 Mar 26 12:53 /root/.ssh -rw------- 1 ubuntu ubuntu 96 Apr 21 21:52 /root/.ssh/authorized_keys ``` Modes are correct (`700` / `600`) but the owner/group is `ubuntu:ubuntu`. sshd's `StrictModes` check requires `/root/.ssh` and `authorized_keys` to be owned by `root` when logging in as `root`. ## ssh -v output ``` debug1: Authentications that can continue: publickey debug1: Offering public key: RawanMostafa08 ED25519 SHA256:8wDIjG+oaxM0Z800MNkjY84zGY0MvkMMuCN5L2jtdlo agent debug1: Authentications that can continue: publickey debug1: Offering public key: rawan@hero-test ED25519 SHA256:xNPAtOIsbFGHo1d1ikhfXZ1ip0BQ6pwdgUJVzSscinM agent debug1: Authentications that can continue: publickey debug1: Trying private key: /home/rawan/.ssh/id_rsa debug1: Authentications that can continue: publickey debug1: Trying private key: /home/rawan/.ssh/id_ecdsa debug1: Trying private key: /home/rawan/.ssh/id_ecdsa_sk debug1: Trying private key: /home/rawan/.ssh/id_ed25519_sk debug1: Trying private key: /home/rawan/.ssh/id_xmss debug1: Trying private key: /home/rawan/.ssh/id_dsa debug1: No more authentication methods to try. root@44f:1db8:de24:7601:f2f9:ae0e:443c:eb69: Permission denied (publickey). ``` ## Expected After deployment, `/root`, `/root/.ssh`, and `/root/.ssh/authorized_keys` should be owned by `root:root` so that `ssh root@<vm-ip>` using the injected key works out of the box. ## Likely cause The cloud-init / provisioning step that writes the `root` user's `authorized_keys` is running as the `ubuntu` user (or mounts the image as that UID), leaving `/root` and its contents owned by `ubuntu:ubuntu`. ## Workaround Inside the VM (via console or as `ubuntu` + sudo): ``` sudo chown -R root:root /root ``` ## Suggested fix In the VM provisioning path in `hero_compute_server` (cloud / cloud-init setup), ensure that when we inject the root SSH key we also `chown root:root /root /root/.ssh /root/.ssh/authorized_keys` (or run the write step as root), and that no part of the pipeline leaves `/root` owned by `ubuntu`.

rawan self-assigned this

2026-04-22 10:44:39 +00:00

rawan commented

2026-04-22 11:00:58 +00:00

Author

Member

Implementation Spec for Issue #100

Objective

Ensure that after deploy_vm and every subsequent SSH key injection, the VM's /root, /root/.ssh, and /root/.ssh/authorized_keys are owned by root:root, so sshd accepts root logins with the provisioned keys (currently they are owned by ubuntu:ubuntu, causing Permission denied (publickey) under sshd's StrictModes).

Requirements

After deploy_vm completes successfully, ssh root@<vm-ip> must succeed for every key in vm.ssh_keys.
/root must be mode 0700 and owned by root:root.
/root/.ssh must be mode 0700 and owned by root:root.
/root/.ssh/authorized_keys must be mode 0600 and owned by root:root.
The fix must also apply to the inject_ssh_keys RPC (on-demand injection on a running VM).
Fix must be idempotent: repeated calls keep ownership correct.
No shell-escape risk: keys are already validated by is_valid_ssh_key.
Must not regress the existing behavior of overwriting authorized_keys so disabled keys are actually removed.

Root Cause Summary

inject_ssh_keys_to_vm in crates/hero_compute_server/src/cloud/rpc.rs runs a shell script via HypervisorDriver::vm_exec. In practice, inside the Ubuntu cloud image the exec channel runs under the default ubuntu user (UID 1000). When the mkdir/cat runs as ubuntu, the resulting files end up owned by ubuntu:ubuntu. sshd's StrictModes then refuses the keys when logging in as root.

The correct fix is to (a) invoke the script with root privilege inside the guest via sudo -n and (b) explicitly chown -R root:root /root after writing.

Files to Modify/Create

crates/hero_compute_server/src/cloud/rpc.rs - Update inject_ssh_keys_to_vm to build the authorized_keys script via root (sudo inside the guest) and append a chown -R root:root /root step; also update set_vm_hostname for consistency.
crates/hero_compute_server/src/cloud/tests.rs - Add unit tests that pin the shape of the generated injection script.

Implementation Plan

Step 1: Rewrite `inject_ssh_keys_to_vm` so the guest-side script runs as root and fixes ownership

Files: crates/hero_compute_server/src/cloud/rpc.rs

Extract the script body into a pure, testable helper build_inject_ssh_keys_script(keys_content: &str) -> String.
The returned script must:
1. Create /root/.ssh with mode 700.
2. Write the keys via a quoted heredoc << 'HEROKEYS'.
3. chmod 600 /root/.ssh/authorized_keys.
4. chown -R root:root /root/.ssh /root.
5. mkdir -p /run/sshd.
Invoke the script via sudo -n sh -c '<body>' with a fallback to plain sh -c '<body>' for images lacking sudo.
Keep the existing 3-attempt retry loop and tracing logs.

Dependencies: none

Step 2: Mirror the same root-privilege wrapping in `set_vm_hostname`

Files: crates/hero_compute_server/src/cloud/rpc.rs

Wrap the hostname script identically: (sudo -n sh -c '...') || sh -c '...'.
safe hostname is already filtered to [a-zA-Z0-9.-] so splicing is safe.
Keep retry loop and logging unchanged.

Dependencies: Step 1

Step 3: Add unit tests for the generated script shape

Files: crates/hero_compute_server/src/cloud/tests.rs

test_build_inject_ssh_keys_script_contains_chown_root_root - asserts chown -R root:root /root.
test_build_inject_ssh_keys_script_writes_mode_600 - asserts chmod 600 /root/.ssh/authorized_keys.
test_build_inject_ssh_keys_script_writes_mode_700 - asserts chmod 700 /root/.ssh.
test_build_inject_ssh_keys_script_uses_quoted_heredoc - asserts << 'HEROKEYS'.
test_build_inject_ssh_keys_script_embeds_keys_verbatim - asserts the supplied key appears verbatim.
Expose the helper via a pub(crate) mod pattern mirroring hypervisor_probe.

Dependencies: Step 1

Step 4: Manual verification plan (no code change)

Build: cargo build --features cloud -p hero_compute_server.
Unit: cargo test --features cloud -p hero_compute_server.
Integration: deploy a fresh VM, ssh root@<mycelium-ip> should succeed; verify stat -c '%U:%G %n' /root /root/.ssh /root/.ssh/authorized_keys returns root:root on all three.
Regression: re-run inject_ssh_keys on a live VM; ownership must remain root:root.

Dependencies: Steps 1-3

Acceptance Criteria

stat -c '%U:%G' /root inside a newly-deployed VM returns root:root.
stat -c '%U:%G' /root/.ssh returns root:root, mode 700.
stat -c '%U:%G' /root/.ssh/authorized_keys returns root:root, mode 600.
ssh root@<vm-ip> with any of the provisioned keys succeeds.
Re-running the inject_ssh_keys RPC on a live VM still yields root:root ownership.
cargo test --features cloud -p hero_compute_server passes including the new tests.
No regression in the host-side my_hypervisor doas/chown-back behavior introduced on the fix_ssh_perm branch.

Notes

The branch fix_ssh_perm already has a host-side permission fix (my_hypervisor state dir ownership). This issue is a separate, guest-side fix; do not revert that work.
sudo may be absent on minimal images; the || sh -c '<body>' fallback preserves existing behavior.
The wrapping relies on is_valid_ssh_key rejecting ', `, $, ;, |, &, \n, \r. Cross-reference that coupling in both functions.
There is no cloud-init user-data in this repo; the hypervisor handles image provisioning directly. The fix belongs in the post-boot vm_exec path.

## Implementation Spec for Issue #100 ### Objective Ensure that after `deploy_vm` and every subsequent SSH key injection, the VM's `/root`, `/root/.ssh`, and `/root/.ssh/authorized_keys` are owned by `root:root`, so `sshd` accepts root logins with the provisioned keys (currently they are owned by `ubuntu:ubuntu`, causing `Permission denied (publickey)` under `sshd`'s `StrictModes`). ### Requirements - After `deploy_vm` completes successfully, `ssh root@<vm-ip>` must succeed for every key in `vm.ssh_keys`. - `/root` must be mode `0700` and owned by `root:root`. - `/root/.ssh` must be mode `0700` and owned by `root:root`. - `/root/.ssh/authorized_keys` must be mode `0600` and owned by `root:root`. - The fix must also apply to the `inject_ssh_keys` RPC (on-demand injection on a running VM). - Fix must be idempotent: repeated calls keep ownership correct. - No shell-escape risk: keys are already validated by `is_valid_ssh_key`. - Must not regress the existing behavior of overwriting `authorized_keys` so disabled keys are actually removed. ### Root Cause Summary `inject_ssh_keys_to_vm` in `crates/hero_compute_server/src/cloud/rpc.rs` runs a shell script via `HypervisorDriver::vm_exec`. In practice, inside the Ubuntu cloud image the exec channel runs under the default `ubuntu` user (UID 1000). When the `mkdir`/`cat` runs as `ubuntu`, the resulting files end up owned by `ubuntu:ubuntu`. sshd's `StrictModes` then refuses the keys when logging in as `root`. The correct fix is to (a) invoke the script with root privilege inside the guest via `sudo -n` and (b) explicitly `chown -R root:root /root` after writing. ### Files to Modify/Create - `crates/hero_compute_server/src/cloud/rpc.rs` - Update `inject_ssh_keys_to_vm` to build the authorized_keys script via root (sudo inside the guest) and append a `chown -R root:root /root` step; also update `set_vm_hostname` for consistency. - `crates/hero_compute_server/src/cloud/tests.rs` - Add unit tests that pin the shape of the generated injection script. ### Implementation Plan #### Step 1: Rewrite `inject_ssh_keys_to_vm` so the guest-side script runs as root and fixes ownership Files: `crates/hero_compute_server/src/cloud/rpc.rs` - Extract the script body into a pure, testable helper `build_inject_ssh_keys_script(keys_content: &str) -> String`. - The returned script must: 1. Create `/root/.ssh` with mode 700. 2. Write the keys via a quoted heredoc `<< 'HEROKEYS'`. 3. `chmod 600 /root/.ssh/authorized_keys`. 4. `chown -R root:root /root/.ssh /root`. 5. `mkdir -p /run/sshd`. - Invoke the script via `sudo -n sh -c '<body>'` with a fallback to plain `sh -c '<body>'` for images lacking sudo. - Keep the existing 3-attempt retry loop and tracing logs. Dependencies: none #### Step 2: Mirror the same root-privilege wrapping in `set_vm_hostname` Files: `crates/hero_compute_server/src/cloud/rpc.rs` - Wrap the hostname script identically: `(sudo -n sh -c '...') || sh -c '...'`. - `safe` hostname is already filtered to `[a-zA-Z0-9.-]` so splicing is safe. - Keep retry loop and logging unchanged. Dependencies: Step 1 #### Step 3: Add unit tests for the generated script shape Files: `crates/hero_compute_server/src/cloud/tests.rs` - `test_build_inject_ssh_keys_script_contains_chown_root_root` - asserts `chown -R root:root /root`. - `test_build_inject_ssh_keys_script_writes_mode_600` - asserts `chmod 600 /root/.ssh/authorized_keys`. - `test_build_inject_ssh_keys_script_writes_mode_700` - asserts `chmod 700 /root/.ssh`. - `test_build_inject_ssh_keys_script_uses_quoted_heredoc` - asserts `<< 'HEROKEYS'`. - `test_build_inject_ssh_keys_script_embeds_keys_verbatim` - asserts the supplied key appears verbatim. - Expose the helper via a `pub(crate) mod` pattern mirroring `hypervisor_probe`. Dependencies: Step 1 #### Step 4: Manual verification plan (no code change) - Build: `cargo build --features cloud -p hero_compute_server`. - Unit: `cargo test --features cloud -p hero_compute_server`. - Integration: deploy a fresh VM, `ssh root@<mycelium-ip>` should succeed; verify `stat -c '%U:%G %n' /root /root/.ssh /root/.ssh/authorized_keys` returns `root:root` on all three. - Regression: re-run `inject_ssh_keys` on a live VM; ownership must remain `root:root`. Dependencies: Steps 1-3 ### Acceptance Criteria - [ ] `stat -c '%U:%G' /root` inside a newly-deployed VM returns `root:root`. - [ ] `stat -c '%U:%G' /root/.ssh` returns `root:root`, mode `700`. - [ ] `stat -c '%U:%G' /root/.ssh/authorized_keys` returns `root:root`, mode `600`. - [ ] `ssh root@<vm-ip>` with any of the provisioned keys succeeds. - [ ] Re-running the `inject_ssh_keys` RPC on a live VM still yields `root:root` ownership. - [ ] `cargo test --features cloud -p hero_compute_server` passes including the new tests. - [ ] No regression in the host-side `my_hypervisor` doas/chown-back behavior introduced on the `fix_ssh_perm` branch. ### Notes - The branch `fix_ssh_perm` already has a host-side permission fix (my_hypervisor state dir ownership). This issue is a separate, guest-side fix; do not revert that work. - `sudo` may be absent on minimal images; the `|| sh -c '<body>'` fallback preserves existing behavior. - The wrapping relies on `is_valid_ssh_key` rejecting `'`, `` ` ``, `$`, `;`, `|`, `&`, `\n`, `\r`. Cross-reference that coupling in both functions. - There is no cloud-init user-data in this repo; the hypervisor handles image provisioning directly. The fix belongs in the post-boot `vm_exec` path.

rawan commented

2026-04-22 11:21:26 +00:00

Author

Member

Test Results

Build: cargo build --features cloud -p hero_compute_server — pass
Tests: cargo test --features cloud -p hero_compute_server — pass

Total: 46
Passed: 46
Failed: 0
Ignored: 2

New tests added for this fix

test_build_inject_ssh_keys_script_contains_chown_root_root
test_build_inject_ssh_keys_script_writes_mode_600
test_build_inject_ssh_keys_script_writes_mode_700
test_build_inject_ssh_keys_script_uses_quoted_heredoc
test_build_inject_ssh_keys_script_embeds_keys_verbatim
test_build_inject_ssh_keys_script_creates_run_sshd
test_build_set_hostname_script_writes_etc_hostname
test_build_set_hostname_script_calls_hostname_cmd

## Test Results **Build:** `cargo build --features cloud -p hero_compute_server` — pass **Tests:** `cargo test --features cloud -p hero_compute_server` — pass - Total: 46 - Passed: 46 - Failed: 0 - Ignored: 2 ### New tests added for this fix - test_build_inject_ssh_keys_script_contains_chown_root_root - test_build_inject_ssh_keys_script_writes_mode_600 - test_build_inject_ssh_keys_script_writes_mode_700 - test_build_inject_ssh_keys_script_uses_quoted_heredoc - test_build_inject_ssh_keys_script_embeds_keys_verbatim - test_build_inject_ssh_keys_script_creates_run_sshd - test_build_set_hostname_script_writes_etc_hostname - test_build_set_hostname_script_calls_hostname_cmd

rawan commented

2026-04-22 11:22:39 +00:00

Author

Member

Implementation Summary

Root cause

The guest-side shell script that writes /root/.ssh/authorized_keys and /etc/hostname runs under the default ubuntu user inside the Ubuntu cloud image (the exec channel is not rooted). The resulting files end up owned by ubuntu:ubuntu, and sshd's StrictModes then refuses the keys when logging in as root, producing Permission denied (publickey).

Fix

Wrap the guest-side script with a sudo -n sh-then-plain-sh fallback and explicitly chown -R root:root /root/.ssh /root after writing the keys. The script body is base64-encoded at the Rust layer so no shell-quoting conflicts arise when routing the heredoc through two layers of sh -c.

Files changed

crates/hero_compute_server/Cargo.toml — added base64 = "0.22".
crates/hero_compute_server/src/cloud/rpc.rs
- Added pub(crate) fn build_inject_ssh_keys_script(keys_content: &str) -> String.
- Added pub(crate) fn build_set_hostname_script(safe_hostname: &str) -> String.
- Rewrote inject_ssh_keys_to_vm to invoke the script via echo <b64> | base64 -d | sudo -n sh 2>/dev/null || echo <b64> | base64 -d | sh and to run chown -R root:root /root/.ssh /root.
- Rewrote set_vm_hostname to use the same wrapping for consistency.
- Preserved: the 3-attempt retry loop, 2-second backoff, tracing::{info,warn}! log messages, ssh_keys.is_empty() early return, is_valid_ssh_key filtering.
crates/hero_compute_server/src/cloud/tests.rs — added 8 unit tests pinning the shape of the generated scripts.

Test results

cargo build --features cloud -p hero_compute_server — pass.
cargo test --features cloud -p hero_compute_server — 46/46 passed, 2 doctests ignored, 0 failed.

New tests

test_build_inject_ssh_keys_script_contains_chown_root_root
test_build_inject_ssh_keys_script_writes_mode_600
test_build_inject_ssh_keys_script_writes_mode_700
test_build_inject_ssh_keys_script_uses_quoted_heredoc
test_build_inject_ssh_keys_script_embeds_keys_verbatim
test_build_inject_ssh_keys_script_creates_run_sshd
test_build_set_hostname_script_writes_etc_hostname
test_build_set_hostname_script_calls_hostname_cmd

Manual verification (still pending on TFGrid)

After deploy, stat -c '%U:%G' /root /root/.ssh /root/.ssh/authorized_keys should all return root:root.
ssh root@<vm-ip> with any provisioned key should succeed without Permission denied (publickey).
Re-running inject_ssh_keys on a running VM should keep ownership root:root.

Notes

The pre-existing host-side my_hypervisor state-dir permission fix (commit 225e3f2 on fix_ssh_perm) is untouched; this change is complementary and stays on the same branch.
The sudo -n path is the happy path; the bare sh fallback preserves existing (buggy) behavior only on images that ship without sudo, which is no worse than the status quo.
base64 (the crate) is only used at the Rust layer; base64 (the binary) is in coreutils/util-linux and is present on every Ubuntu cloud image.

## Implementation Summary ### Root cause The guest-side shell script that writes `/root/.ssh/authorized_keys` and `/etc/hostname` runs under the default `ubuntu` user inside the Ubuntu cloud image (the exec channel is not rooted). The resulting files end up owned by `ubuntu:ubuntu`, and `sshd`'s `StrictModes` then refuses the keys when logging in as `root`, producing `Permission denied (publickey)`. ### Fix Wrap the guest-side script with a `sudo -n sh`-then-plain-`sh` fallback and explicitly `chown -R root:root /root/.ssh /root` after writing the keys. The script body is base64-encoded at the Rust layer so no shell-quoting conflicts arise when routing the heredoc through two layers of `sh -c`. ### Files changed - `crates/hero_compute_server/Cargo.toml` — added `base64 = "0.22"`. - `crates/hero_compute_server/src/cloud/rpc.rs` - Added `pub(crate) fn build_inject_ssh_keys_script(keys_content: &str) -> String`. - Added `pub(crate) fn build_set_hostname_script(safe_hostname: &str) -> String`. - Rewrote `inject_ssh_keys_to_vm` to invoke the script via `echo <b64> | base64 -d | sudo -n sh 2>/dev/null || echo <b64> | base64 -d | sh` and to run `chown -R root:root /root/.ssh /root`. - Rewrote `set_vm_hostname` to use the same wrapping for consistency. - Preserved: the 3-attempt retry loop, 2-second backoff, `tracing::{info,warn}!` log messages, `ssh_keys.is_empty()` early return, `is_valid_ssh_key` filtering. - `crates/hero_compute_server/src/cloud/tests.rs` — added 8 unit tests pinning the shape of the generated scripts. ### Test results - `cargo build --features cloud -p hero_compute_server` — pass. - `cargo test --features cloud -p hero_compute_server` — 46/46 passed, 2 doctests ignored, 0 failed. ### New tests - `test_build_inject_ssh_keys_script_contains_chown_root_root` - `test_build_inject_ssh_keys_script_writes_mode_600` - `test_build_inject_ssh_keys_script_writes_mode_700` - `test_build_inject_ssh_keys_script_uses_quoted_heredoc` - `test_build_inject_ssh_keys_script_embeds_keys_verbatim` - `test_build_inject_ssh_keys_script_creates_run_sshd` - `test_build_set_hostname_script_writes_etc_hostname` - `test_build_set_hostname_script_calls_hostname_cmd` ### Manual verification (still pending on TFGrid) - After deploy, `stat -c '%U:%G' /root /root/.ssh /root/.ssh/authorized_keys` should all return `root:root`. - `ssh root@<vm-ip>` with any provisioned key should succeed without `Permission denied (publickey)`. - Re-running `inject_ssh_keys` on a running VM should keep ownership `root:root`. ### Notes - The pre-existing host-side `my_hypervisor` state-dir permission fix (commit `225e3f2` on `fix_ssh_perm`) is untouched; this change is complementary and stays on the same branch. - The `sudo -n` path is the happy path; the bare `sh` fallback preserves existing (buggy) behavior only on images that ship without `sudo`, which is no worse than the status quo. - `base64` (the crate) is only used at the Rust layer; `base64` (the binary) is in `coreutils`/`util-linux` and is present on every Ubuntu cloud image.

rawan referenced this issue

2026-04-22 13:01:00 +00:00

Fixing ssh Permissions #101

rawan closed this issue

2026-04-23 09:31:03 +00:00