Skip to main content

SSH Key Management

Borg UI provides a centralized system for managing SSH keys to access remote repositories securely. This eliminates the need to manually configure SSH keys on the host.

Overview

Borg UI uses a single system SSH key for all remote connections. This simplifies management and ensures consistent authentication across all SSH repositories.

Key Features

  • Centralized Management: One system key for all SSH connections
  • Encrypted Storage: Private keys encrypted in database using SECRET_KEY
  • Automatic Deployment: Keys deployed to filesystem (/home/borg/.ssh) on startup
  • Multiple Key Types: RSA, ED25519, ECDSA support
  • Connection Testing: Verify SSH connectivity before use
  • Storage Monitoring: Track remote storage usage via SSH

How It Works

  1. Generate or Import: Create a new key or import existing one
  2. Deploy to Servers: Use Quick Setup or manual deployment
  3. Automatic Use: Borg automatically uses the system key for SSH operations
  4. Persistent Storage: Keys survive container restarts

Quick Setup

1

Navigate to SSH Keys

Go to Settings → SSH Keys in the Borg UI.
2

Generate System Key

Click Quick Setup and choose:
  • Name: Descriptive name (e.g., “Borg System Key”)
  • Key Type: ed25519 (recommended) or rsa
  • Description: Optional notes
3

Deploy to Remote Server

Enter remote server credentials:
  • Host: Remote server hostname/IP
  • Username: SSH username
  • Port: SSH port (default: 22)
  • Password: One-time password for deployment
  • Use SFTP Mode: Enable for Hetzner, disable for Synology
Click Deploy to automatically copy the public key.
4

Test Connection

Click Test Connection to verify SSH access works.
The password is only used once to deploy the public key. After deployment, all authentication uses the SSH key.

Generating SSH Keys

Generate New Key

Key Type Comparison:
Only one system key can exist at a time. Delete the existing key first to generate a new one.

Response

Importing Existing Keys

Import from Filesystem

Request
If public_key_path is omitted, Borg UI looks for {private_key_path}.pub
Supported Key Formats:
  • OpenSSH format (modern, recommended)
  • PEM format (legacy)
Key Detection: The key type (RSA, ED25519, ECDSA) is automatically detected from the public key.

Deploying Keys to Remote Servers

Request
This performs three actions:
  1. Generates a new SSH key
  2. Deploys it to the remote server using ssh-copy-id
  3. Creates and tests the SSH connection

Manual Deployment

If you already have a key and want to deploy it:
Request
boolean
default:"true"
SFTP Mode Compatibility:
  • true: Hetzner Storage Box, most modern servers
  • false: Synology NAS, older SSH servers
Determines whether to use SFTP (-s flag) for ssh-copy-id.
string
default:"/"
Default starting directory for SSH file browsing.Examples:
  • Hetzner: / (root of storage box)
  • Synology: /volume1/backup
  • Generic: /home/username/backup
string
default:"none"
Path prefix prepended to SSH commands (not SFTP).Use case: Synology NAS requires /volume1 prefix for SSH but not SFTP.
string
default:"none"
Logical mount point name for UI display.Examples:
  • /hetzner
  • /synology
  • /backup-server

Redeploying Keys

If you need to redeploy the system key to an existing connection:
Request
Use cases:
  • Server was rebuilt and lost authorized_keys
  • Generated a new system key
  • Public key was removed from server

Managing SSH Connections

List Connections

Response

Test Connection

Verifies:
  • SSH connection succeeds
  • Authentication works
  • Server is reachable
Response

Refresh Storage Information

Runs df -k on the remote server to collect storage statistics.
Response

Update Connection

Request

Delete Connection

Deleting a connection does NOT remove repositories or data. It only removes the connection record from Borg UI.

Key Storage and Security

Encryption

Private keys are encrypted using Fernet symmetric encryption:
  • Encryption key: First 32 bytes of SECRET_KEY
  • Algorithm: Fernet (AES-128-CBC + HMAC-SHA256)
  • Storage: Database (ssh_keys table)
Decryption happens only when:
  • Deploying keys to remote servers
  • Writing keys to /home/borg/.ssh on startup
  • Testing SSH connections

Filesystem Deployment

On container startup, the system SSH key is automatically deployed: Location: /home/borg/.ssh/
Deployment script: /app/app/scripts/deploy_ssh_key.py Process:
  1. Read encrypted private key from database
  2. Decrypt using SECRET_KEY
  3. Write to /home/borg/.ssh/id_{key_type}
  4. Set proper permissions (600 for private, 644 for public)
  5. Set ownership to borg:borg

Key Rotation

1

Generate New Key

Delete existing system key, then generate a new one.
2

Deploy to All Servers

Use Redeploy on each SSH connection to update the authorized_keys.
3

Remove Old Key

Manually remove the old public key from ~/.ssh/authorized_keys on each server.

Troubleshooting

Permission Denied

Symptoms:
Solutions:
  1. Verify key deployed: Check /home/borg/.ssh/ in container
  2. Test manually:
  3. Check remote ~/.ssh/authorized_keys:
  4. Verify SFTP mode setting matches server capabilities

Connection Timeout

Symptoms:
Solutions:
  1. Check firewall rules
  2. Verify port (default: 22)
  3. Test connectivity:

Storage Info Unavailable

Symptoms: Storage information shows as unavailable or null. Causes:
  • Server restricts df command
  • Limited shell environment (e.g., Hetzner Storage Box)
  • Path doesn’t exist
Solutions:
  1. Verify default_path exists on server
  2. Test manually:
  3. Check server’s SSH restrictions (some providers limit commands)

Hetzner Storage Box Issues

Restricted shell environment:
  • Use use_sftp_mode: true
  • Set default_path: "/"
  • Storage info may fail due to command restrictions

Synology NAS Issues

Path prefix required:
Old SSH version:
  • Disable SFTP mode: use_sftp_mode: false
  • May need to manually copy public key

Best Practices

ED25519 keys are faster, more secure, and smaller than RSA keys. Only use RSA for legacy system compatibility.
Borg UI enforces a single system key for simplicity. This is sufficient for most use cases and simplifies key rotation.
The SECRET_KEY encrypts all private keys. Back it up securely:
Always test SSH connections before creating repositories. Use the Test Connection button to verify.
Regularly refresh storage information to track remote disk usage and prevent out-of-space errors.
On remote servers:
  • Disable password authentication after deploying keys
  • Use non-standard SSH ports if exposed to internet
  • Enable fail2ban for brute force protection

API Reference

Endpoints

Next Steps

Create SSH Repository

Set up a repository on a remote SSH server

Environment Variables

Configure SSH-related environment variables

Troubleshooting

Resolve common SSH connection issues

API Reference

Complete API documentation