Troubleshooting
This section covers frequently asked questions about resolving common errors and troubleshooting issues with backups and system operations.
How to resolve the Borg acquire lock in remote backups
If you see the following error when listing, restoring, or taking manual backups for your Borg remote backups:
Failed to create/acquire the lock /root/.cache/borg/f80e5dfd25cb9/lock.exclusive (timeout).
You may simply solve it by following the instructions below:
- You can connect with the VM terminal and run the below command.
borg break-lock BorgRepoName
By using the command, you can determine your BorgRepoName:
cd /opt/borg;
cat backupInfo.sh;
#It will return output like these:
BORG_PASSPHRASE=xxxxxxxxxxxxxxxxx borg info ssh://xxxxxxxxxxxx.repo.borgbase.com/./repo;
The ssh://xxxxxxxxxxxx.repo.borgbase.com/./repo; is your Borg repo name. You can use that in the command above.
Example: borg break-lock ssh://xxxxxxxxxxxx.repo.borgbase.com/./repo;
How to resolve the Borg cache error in remote backups
If you see the following error related to the Borg cache when listing, restoring, or taking manual backups for your Borg remote backups:
Local Exception
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/borg/archiver.py", line 5089, in main
exit_code = archiver.run(args)
File "/usr/lib/python3/dist-packages/borg/archiver.py", line 174, in wrapper
assert_secure(repository, kwargs['manifest'], self.lock_wait)
File "/usr/lib/python3/dist-packages/borg/cache.py", line 209, in assert_secure
sm.assert_secure(manifest, manifest.key, lock_wait=lock_wait)
File "/usr/lib/python3/dist-packages/borg/cache.py", line 174, in assert_secure
with cache_config:
File "/usr/lib/python3/dist-packages/borg/cache.py", line 334, in _check_upgrade
raise Exception('%s does not look like a Borg cache.' % config_path) from None
Exception: /root/.cache/borg/f80e55dff9886465adf97645/config does not look like a Borg cache.
You may simply solve it by following the instructions below:
- You can connect with the VM terminal and run the below command.
borg delete --cache-only BorgRepoName
By using the command, you can determine your BorgRepoName:
cd /opt/borg;
cat backupInfo.sh;
#It will return output like these:
BORG_PASSPHRASE=xxxxxxxxxxxxxxxxx borg info ssh://xxxxxxxxxxxx.repo.borgbase.com/./repo;
The ssh://xxxxxxxxxxxx.repo.borgbase.com/./repo; is your Borg repo name. You can use that in the command above.
Example: borg delete --cache-only ssh://xxxxxxxxxxxx.repo.borgbase.com/./repo;
How to Enable Root Login on Your VM (BYOVM)
Elestio’s BYOVM (Bring Your Own VM) workflow requires direct root-level SSH access to the target host. Many cloud providers disable or restrict root login by default; this document outlines how to safely re-enable it while maintaining a strong security posture.
Architectural Requirement for Root Access
Elestio performs low-level system provisioning and lifecycle management directly on the host. This includes:
- Writing configuration and state under
/root/other privileged paths - Installing and managing system packages and daemons
- Modifying network configuration, firewall rules, and kernel-adjacent settings
- Executing privileged deployment and orchestration tasks
Relying on a non-root user with sudo is intentionally avoided due to
- Inconsistent
sudoavailability and behavior across distributions and cloud images - Hard dependencies on root-owned paths (e.g.,
/root, system-level configs) - Increased operational complexity from privilege escalation (TTY requirements, environment differences, edge cases)
- Higher failure surface during automated provisioning
From an automation and reliability standpoint, direct root access is deterministic and reduces ambiguity.
Security Model: Root Access with SSH Keys
Enabling root login is not inherently insecure when implemented correctly.
Elestio enforces the following security guarantees:
- Password authentication is permanently disabled
- Only SSH key-based authentication is permitted
- Root login is restricted to key-based access (
prohibit-password)
Implications
- No password-based login is possible under any circumstances
- Attack vectors such as brute-force or credential stuffing are eliminated
- Access is strictly limited to holders of the corresponding private key
Blocking the root while allowing SSH access to an enabled user does not materially improve security. Any compromise of such a user trivially escalates to root (sudo su). The true security boundary is the SSH private key, not the username.
Step 1: Remove Provider-Imposed Restrictions
Some providers (notably AWS and GCP) inject a forced command /root/.ssh/authorized_keys to prevent root login:
no-port-forwarding,no-agent-forwarding,no-X11-forwarding,command="echo 'Please login as the user \"ubuntu\" rather than the user \"root\".';echo;sleep 10;exit 142"
This must be removed.
Execute as a privileged non-root user (e.g., ubuntu, ec2-user):
sudo sed -e "s/echo;sleep 10;exit 142//g" -i /root/.ssh/authorized_keys
Validate:
sudo cat /root/.ssh/authorized_keys
Expected state: only raw public key entries, no command="..." prefix.
Step 2: Configure SSH Daemon
Inspect the current configuration:
sudo grep -i PermitRootLogin /etc/ssh/sshd_config
Enforce the correct policy:
sudo sed -i 's/^.*PermitRootLogin.*/PermitRootLogin prohibit-password/' /etc/ssh/sshd_config
Semantics
-
prohibit-password- ✅ (allows) SSH key authentication
- ❌ (blocks) password authentication
This is the recommended and secure baseline configuration.
Step 3: Reload SSH Service
Apply changes without terminating the active session:
sudo systemctl reload sshd || sudo service ssh reload
Step 4: Validate Root Access
From your local environment:
ssh -i /path/to/private_key root@<server_ip>
A successful connection should yield a root shell immediately.
Provider Behavior Matrix
| Provider | Root Access Default | Notes |
|---|---|---|
| AWS EC2 (Ubuntu) | Blocked | Requires authorized_keys fix |
| AWS EC2 (Amazon Linux) | Blocked | Requires authorized_keys fix |
| Google Cloud | Blocked | Requires authorized_keys fix |
| Azure | Blocked | Controlled via sshd_config |
| DigitalOcean | Enabled | No action required |
| Hetzner | Enabled | No action required |
| Vultr | Enabled | No action required |
| Linode (Akamai) | Enabled | No action required |
For AWS and GCP, Step 1 is mandatory in most cases.
Troubleshooting
Root login still denied
Check for override files:
sudo grep -r PermitRootLogin /etc/ssh/sshd_config.d/
Ensure all instances are set to:
PermitRootLogin prohibit-password
Forced “login as ubuntu” message
Indicates the provider-injected restriction is still present.
Re-run Step 1 and re-validate /root/.ssh/authorized_keys.
SSH key not accepted
Ensure the key exists and permissions are correct:
sudo cat /root/.ssh/authorized_keys
If missing:
sudo cp ~/.ssh/authorized_keys /root/.ssh/authorized_keys
sudo chmod 600 /root/.ssh/authorized_keys
sudo chown root:root /root/.ssh/authorized_keys
Consolidated Execution Block
# Remove provider-enforced root restriction
sudo sed -e "s/echo;sleep 10;exit 142//g" -i /root/.ssh/authorized_keys
# Enable root login via SSH key only
sudo sed -i 's/^.*PermitRootLogin.*/PermitRootLogin prohibit-password/' /etc/ssh/sshd_config
# Normalize any drop-in overrides
sudo sed -i 's/^.*PermitRootLogin.*/PermitRootLogin prohibit-password/' /etc/ssh/sshd_config.d/*.conf 2>/dev/null || true
# Reload SSH daemon
sudo systemctl reload sshd || sudo service ssh reload