Containers don’t exist in isolation. They need to talk to each other, reach external services, and accept incoming connections. Understanding container networking is essential for building multi-service applications.

This guide covers networking concepts that apply to both Docker and Podman, with practical examples you can test immediately.

Network Drivers Overview

Both Docker and Podman support several network drivers:

Bridge (Default)

Creates a private network on the host. Containers on the same bridge can communicate.

docker run -d --name web nginx
docker run -d --name api myapp
# Both containers are on the default 'bridge' network

Host

Container shares the host’s network stack. No isolation.

docker run -d --network host nginx
# Nginx binds directly to host's port 80

None

No network access. Useful for batch jobs or security isolation.

docker run --network none alpine ping google.com
# Fails: no network

Custom Networks

User-defined bridges with specific configurations.

docker network create --subnet 172.20.0.0/16 mynet
docker run -d --network mynet --ip 172.20.0.10 nginx

Bridge Networking: The Default

When you start a container without specifying a network, it joins the default bridge network.

How It Works

Host Machine
├── docker0 (bridge interface: 172.17.0.1)
│   ├── Container A (172.17.0.2)
│   ├── Container B (172.17.0.3)
│   └── Container C (172.17.0.4)

The docker0 bridge acts as a virtual switch. Containers get IPs from the bridge’s subnet.

Inspecting the Network

docker network inspect bridge

Output shows connected containers, their IPs, and network settings.

Container-to-Container Communication

On the default bridge, containers can only communicate by IP:

docker exec -it container-a ping 172.17.0.3
# Works: ping container-b by IP

docker exec -it container-a ping container-b
# Fails: DNS not available on default bridge

Custom Bridge: Enable DNS

Create a custom bridge network to enable DNS-based communication:

docker network create mynet

docker run -d --name web --network mynet nginx
docker run -d --name api --network mynet myapp

docker exec -it web ping api
# Works! DNS resolution via container name

Custom bridges provide:

• Automatic DNS resolution by container name
• Better isolation (containers on different networks can’t communicate)
• Configurable subnet, gateway, and IP range

Port Mapping: Exposing Services

Containers have their own network namespace. To access a container’s service from outside, you must map ports.

Basic Port Mapping

docker run -d -p 8080:80 nginx

Syntax: -p <host_port>:<container_port>

Now access Nginx at http://localhost:8080. Traffic flows:

Browser → Host:8080 → Docker Proxy → Container:80

Specify Binding Address

# Bind to localhost only (not accessible from other machines)
docker run -d -p 127.0.0.1:8080:80 nginx

# Bind to specific interface
docker run -d -p 192.168.1.100:8080:80 nginx

Port Ranges

# Map a range of ports
docker run -d -p 8000-8010:8000-8010 myapp

Random Port Assignment

docker run -d -p 80 nginx
docker port <container_id>
# Shows assigned random port, e.g., 0.0.0.0:32768->80/tcp

View Mapped Ports

docker ps
# PORTS column shows mappings

docker port <container_name>
# Shows all port mappings for a container

Host Networking: Maximum Performance

Host networking removes the network isolation layer.

docker run -d --network host nginx

Advantages:

• No port mapping needed (container uses host ports directly)
• Slightly better performance (no NAT overhead)
• Simpler configuration

Disadvantages:

• No port isolation (container can bind to any host port)
• Security risk (container has full network access)
• Port conflicts (can’t run two containers on same port)

Use cases:

• Performance-critical applications
• Network monitoring tools
• When container needs to bind to privileged ports (< 1024)

Inter-Container Communication

Multi-service applications require containers to communicate.

Method 1: Shared Network (Recommended)

docker network create appnet

docker run -d --name db --network appnet postgres
docker run -d --name api --network appnet myapi
docker run -d --name web --network appnet nginx

# In API code, connect to database:
# DATABASE_URL=postgresql://user:pass@db:5432/mydb

Containers resolve each other by name via built-in DNS.

Method 2: Legacy Links (Deprecated)

docker run -d --name db postgres
docker run -d --name api --link db myapi

Links are deprecated. Use custom networks instead.

Method 3: Host Networking

All containers share the host network, so they communicate via localhost.

docker run -d --network host postgres
docker run -d --network host myapi
# API connects to postgresql://localhost:5432

Not recommended for production (no isolation).

Network Troubleshooting

Check Container IP

docker inspect -f '{{range.NetworkSettings.Networks}}{{.IPAddress}}{{end}}' <container>
# Output: 172.18.0.2

Test Connectivity

# From host to container
curl http://<container_ip>:80

# From container to container
docker exec -it container-a ping container-b

# From container to external
docker exec -it container-a ping google.com

Check Network Rules

# List iptables rules
sudo iptables -L -n -v | grep docker

# List NAT rules
sudo iptables -t nat -L -n -v | grep docker

Debug DNS Resolution

docker exec -it container nslookup other-container
# Should resolve to container's IP

Common Issues

Problem: Can’t connect to container by name.

Fix: Ensure both containers are on the same custom network (not default bridge).

Problem: Port mapping doesn’t work.

Fix: Check if another process is using the host port:

lsof -i :8080

Problem: Container can’t reach internet.

Fix: Check Docker daemon network config:

cat /etc/docker/daemon.json
# Ensure no restrictive DNS settings

Advanced: Macvlan Networks

Macvlan allows containers to get IPs from your physical network.

docker network create -d macvlan \
  --subnet=192.168.1.0/24 \
  --gateway=192.168.1.1 \
  -o parent=eth0 \
  mymacvlan

docker run -d --network mymacvlan --ip 192.168.1.100 nginx

Now the container appears as a separate device on your LAN with its own IP.

Use cases:

• Legacy applications that expect direct LAN access
• Network monitoring appliances
• When you need containers to be reachable by other LAN devices

Caveat: Not all WiFi adapters support macvlan.

Pod-Specific Networking (Podman)

Podman introduces pods: groups of containers sharing the same network namespace.

podman pod create --name mypod -p 8080:80

podman run -d --pod mypod nginx
podman run -d --pod mymypod myapi

# Both containers share the same network namespace
# API can reach Nginx at localhost:80

This mirrors Kubernetes pods, making migration easier.

Network Security

Restrict Inter-Container Traffic

By default, containers on the same network can communicate freely. Restrict this with firewall rules:

# Create network
docker network create securenet

# Add iptables rule to block traffic between specific containers
iptables -I DOCKER-USER -s 172.18.0.2 -d 172.18.0.3 -j DROP

Encrypt Container Traffic

For sensitive data, encrypt traffic between containers:

• Use TLS/SSL in application protocols (HTTPS, PostgreSQL SSL)
• Use service meshes (Istio, Linkerd) for automatic mTLS
• Use WireGuard or IPSec tunnels between hosts

Network Policies (Kubernetes)

If you’re moving to Kubernetes, network policies provide fine-grained control:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

FoxTerm Container Networking UI

FoxTerm visualizes container networking:

Network List

View all networks and connected containers:

• Network name and driver
• Subnet and gateway
• Connected containers with IPs

Port Mapping Display

For each container, see active port mappings:

• Host port → Container port
• Protocol (TCP/UDP)
• Binding address

One-Click Port Forward

Need to access a container’s internal service? Click “Forward Port” and FoxTerm sets up SSH local port forwarding automatically:

Your Machine → SSH Tunnel → Server → Container:port

No manual ssh -L commands needed.

Conclusion

Container networking seems complex at first, but the fundamentals are straightforward: bridge networks for isolation, port mapping for external access, and custom networks for DNS-based communication. Whether you use Docker or Podman, these concepts apply universally.

Master these basics, and you’ll build robust multi-container applications with confidence.

FoxTerm Pro manages Docker and Podman containers visually. Download at foxterm.app.

In a world where developers juggle multiple devices — MacBook at the desk, iPad in meetings, iPhone on the go — having a consistent toolchain matters. FoxTerm is built from the ground up for all Apple platforms, delivering the same core experience everywhere.

Shared Foundation

FoxTerm uses SwiftUI as its primary UI framework, which enables:

• Single codebase — Most UI code runs identically on macOS, iPadOS, and iOS
• Native performance — No cross-platform abstraction layers slowing things down
• Platform adaptations — Subtle differences where they matter (touch vs. trackpad, screen size)

Platform-Specific Optimizations

While the core is shared, FoxTerm adapts to each platform’s strengths:

macOS

NavigationSplitView with sidebar (host list) and detail (workspace):

• Chrome-style tab bar with close buttons
• Inspector panel toggle (Cmd+R)
• Toolbar with SSH keygen, settings, system stats
• Keyboard shortcuts for power users
• Multi-window support

iPadOS

Same NavigationSplitView layout as macOS:

• Chrome tab bar visible (unlike iPhone)
• Split-screen multitasking support
• Stage Manager compatibility
• External display support
• Mouse/trackpad input

iOS (iPhone)

Adaptive NavigationStack with push navigation:

• Simplified interface for smaller screens
• Touch-optimized controls
• Haptic feedback for actions
• No tab bar (uses bottom navigation)
• Deep link support for quick access

Feature Parity

Every major feature works on all platforms:

Continuity Workflows

FoxTerm enables seamless transitions between devices:

Start on Mac, Continue on iPad

Working on a complex deployment from your MacBook? Step away to a meeting, pick up your iPad, and resume the same SSH session. Connection state syncs via iCloud (encrypted).

Quick Checks on iPhone

Need to verify a container is running or check server load? Open FoxTerm on your iPhone, authenticate with Face ID, and get instant access.

Universal Clipboard

Copy a command on your Mac, paste it into FoxTerm on your iPad. Apple’s Universal Clipboard works seamlessly.

Sync & Backup

FoxTerm supports optional iCloud sync for:

• Host configurations — Server addresses, usernames, key references
• Saved sessions — Favorite connections for quick access
• Themes — Custom terminal themes
• Key mappings — Keyboard shortcuts (macOS only)

Sensitive data (private keys, passwords) is never synced. These stay device-local, protected by Secure Enclave or Keychain.

Performance Across Devices

FoxTerm maintains consistent performance regardless of device:

• MacBook Pro M3: 120fps terminal rendering
• iPad Pro M2: 120fps with touch gestures
• iPhone 15 Pro: 60fps optimized for mobile

The Ghostty terminal engine scales gracefully, using Metal on all devices for GPU-accelerated rendering.

Offline Mode

FoxTerm works offline for:

• Viewing saved host configurations
• Editing local files before upload
• Preparing commands for later execution
• Reading documentation

Of course, SSH connections require network access — but the app itself doesn’t.

Accessibility

FoxTerm supports Apple’s accessibility features on all platforms:

• VoiceOver — Screen reader support
• Switch Control — Alternative input methods
• Dynamic Type — Adjustable text sizes
• Reduce Motion — Disable animations
• High Contrast — Enhanced visibility

The Bottom Line

FoxTerm isn’t just “available” on multiple platforms — it’s designed for them. Whether you’re at your desk, in a coffee shop, or traveling, your SSH workflow stays consistent, secure, and productive.

Download FoxTerm on the App Store for macOS, iPadOS, and iOS. Visit foxterm.app.

Docker Compose is fantastic for development: define your services in a YAML file, run docker compose up, and everything starts. But using Compose in production requires more discipline. You need health checks, resource limits, proper networking, secret management, and restart policies.

This guide covers everything you need to run Docker Compose reliably in production environments.

Basic vs Production Compose Files

Development Compose (Simple)

version: '3'
services:
  web:
    build: .
    ports:
      - "80:80"
  db:
    image: postgres
    environment:
      POSTGRES_PASSWORD: password123

This works for local development but is unsafe for production.

Production Compose (Hardened)

version: '3.8'

services:
  web:
    build:
      context: .
      dockerfile: Dockerfile.prod
    ports:
      - "127.0.0.1:8080:80"
    restart: unless-stopped
    deploy:
      resources:
        limits:
          cpus: '1.0'
          memory: 512M
        reservations:
          cpus: '0.25'
          memory: 128M
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost/health"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 40s
    depends_on:
      db:
        condition: service_healthy
    networks:
      - frontend
      - backend
    env_file:
      - .env.production
    read_only: true
    tmpfs:
      - /tmp:size=100M
    user: "1000:1000"

  db:
    image: postgres:16-alpine
    restart: unless-stopped
    volumes:
      - pgdata:/var/lib/postgresql/data
    environment:
      POSTGRES_PASSWORD_FILE: /run/secrets/db_password
    secrets:
      - db_password
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 10s
      timeout: 5s
      retries: 5
    networks:
      - backend
    deploy:
      resources:
        limits:
          cpus: '2.0'
          memory: 1G

volumes:
  pgdata:
    driver: local

networks:
  frontend:
    driver: bridge
  backend:
    driver: bridge
    internal: true

secrets:
  db_password:
    file: ./secrets/db_password.txt

Let’s break down each production improvement.

Health Checks: Detect Failures Automatically

Health checks let Docker determine if a service is actually working, not just running.

Basic Health Check

healthcheck:
  test: ["CMD", "curl", "-f", "http://localhost/health"]
  interval: 30s
  timeout: 10s
  retries: 3
  start_period: 40s

Fields:

• test: Command to run (must exit 0 for healthy, 1 for unhealthy)
• interval: How often to check (default: 30s)
• timeout: Max time for check to complete (default: 30s)
• retries: Failed checks before marking unhealthy (default: 3)
• start_period: Grace period for container startup (default: 0s)

Common Health Check Patterns

HTTP endpoint:

healthcheck:
  test: ["CMD", "curl", "-f", "http://localhost:8080/health"]

Database connection:

healthcheck:
  test: ["CMD-SHELL", "pg_isready -U postgres"]

Custom script:

healthcheck:
  test: ["CMD", "/app/healthcheck.sh"]

Process check:

healthcheck:
  test: ["CMD-SHELL", "pidof nginx || exit 1"]

Using Health Checks

Depend on healthy services:

services:
  api:
    depends_on:
      db:
        condition: service_healthy
      redis:
        condition: service_healthy

Monitor health status:

docker compose ps
# Shows health status for each service

docker inspect --format='{{.State.Health.Status}}' <container>

Resource Limits: Prevent Resource Exhaustion

Without limits, a single container can consume all host resources.

CPU and Memory Limits

deploy:
  resources:
    limits:
      cpus: '1.0'
      memory: 512M
    reservations:
      cpus: '0.25'
      memory: 128M

Limits: Maximum resources the container can use Reservations: Minimum resources guaranteed to the container

Find the Right Limits

1. Monitor actual usage:

   docker stats
   

2. Set limits slightly above peak usage:

   • If app uses 400MB RAM normally, set limit to 512MB
   • Add headroom for traffic spikes

3. Test under load:

   # Simulate high traffic
   ab -n 10000 -c 100 http://localhost/
   
   # Monitor resource usage
   docker stats
   

OOM Kill Prevention

If a container exceeds its memory limit, it’s killed (OOM killed). Prevent this:

deploy:
  resources:
    limits:
      memory: 512M

Monitor for OOM kills:

dmesg | grep -i "out of memory"
docker inspect <container> | grep OOMKilled

Restart Policies: Automatic Recovery

When containers crash, restart them automatically.

Available Policies

restart: no              # Never restart (default)
restart: on-failure      # Restart only if exit code != 0
restart: unless-stopped  # Always restart unless manually stopped
restart: always          # Always restart, even after daemon restart

Recommendation

restart: unless-stopped

This restarts containers after crashes and host reboots, but respects manual stops.

Exponential Backoff

Docker uses exponential backoff for restart delays:

• First restart: immediate
• Second restart: 100ms delay
• Third restart: 200ms delay
• Fourth restart: 400ms delay
• Maximum delay: 1 minute

Secret Management: Secure Credentials

Never hardcode passwords in compose files.

Docker Secrets

Create a secret file:

mkdir -p secrets
echo "supersecretpassword" > secrets/db_password.txt
chmod 600 secrets/db_password.txt

Reference in compose:

services:
  db:
    image: postgres
    environment:
      POSTGRES_PASSWORD_FILE: /run/secrets/db_password
    secrets:
      - db_password

secrets:
  db_password:
    file: ./secrets/db_password.txt

The secret is mounted at /run/secrets/db_password inside the container.

Environment Files

For non-sensitive config, use .env files:

services:
  web:
    env_file:
      - .env.production

# .env.production
NODE_ENV=production
LOG_LEVEL=info
API_URL=https://api.example.com

Add to .gitignore:

# .gitignore
.env.production
secrets/

External Secret Managers

For enterprise deployments, integrate with:

• HashiCorp Vault: Dynamic secrets, audit logging
• AWS Secrets Manager: Cloud-native secret storage
• Azure Key Vault: Microsoft cloud secrets
• Google Secret Manager: GCP secret storage

Networking: Isolation and Security

Separate services into different networks for security.

Frontend and Backend Networks

networks:
  frontend:
    driver: bridge
  backend:
    driver: bridge
    internal: true  # No external access

Assign services:

services:
  web:
    networks:
      - frontend  # Accessible from outside
      - backend   # Can reach backend services
  
  api:
    networks:
      - backend   # Only accessible via web
  
  db:
    networks:
      - backend   # Only accessible via api

Traffic flow:

Internet → web (frontend+backend) → api (backend) → db (backend)

The internal: true flag prevents backend network from accessing the internet.

Port Binding

Bind to localhost unless external access is needed:

ports:
  - "127.0.0.1:8080:80"  # Localhost only

For public services, use a reverse proxy (Nginx, Traefik) instead of direct port exposure.

Volume Management: Persistent Data

Use named volumes for data that must persist.

Named Volumes

volumes:
  pgdata:
    driver: local

services:
  db:
    volumes:
      - pgdata:/var/lib/postgresql/data

Named volumes are managed by Docker, stored in /var/lib/docker/volumes/.

Bind Mounts (Development Only)

volumes:
  - ./config:/etc/app/config:ro  # Read-only mount

Avoid bind mounts in production (path dependencies, permission issues).

Volume Backups

Backup named volumes:

docker run --rm \
  -v pgdata:/source:ro \
  -v $(pwd):/backup \
  alpine tar czf /backup/pgdata-backup.tar.gz -C /source .

Restore:

docker run --rm \
  -v pgdata:/dest \
  -v $(pwd):/backup \
  alpine tar xzf /backup/pgdata-backup.tar.gz -C /dest

Logging: Capture and Rotate Logs

Prevent logs from filling up disk space.

Log Driver Configuration

services:
  web:
    logging:
      driver: json-file
      options:
        max-size: "10m"
        max-file: "3"

• max-size: Maximum size per log file (10 MB)
• max-file: Maximum number of log files to keep (3)

Total disk usage: 30 MB per service.

View Logs

# All services
docker compose logs

# Specific service
docker compose logs web

# Follow logs
docker compose logs -f web

# Last 100 lines
docker compose logs --tail=100 web

Centralized Logging

Forward logs to external systems:

logging:
  driver: syslog
  options:
    syslog-address: "tcp://logs.company.com:514"
    tag: "myapp-{{.Name}}"

Deployment Workflow

Step 1: Validate Compose File

docker compose config
# Shows resolved configuration

Step 2: Build Images

docker compose build --no-cache

Step 3: Test Locally

docker compose up -d
docker compose ps
docker compose logs

Step 4: Deploy to Server

Upload compose file and secrets:

scp docker-compose.prod.yml user@server:/opt/myapp/
scp -r secrets/ user@server:/opt/myapp/

On server:

cd /opt/myapp
docker compose -f docker-compose.prod.yml up -d

Step 5: Verify Deployment

# Check all services running
docker compose ps

# Check health
docker compose ps --format "table {{.Name}}\t{{.Status}}\t{{.Ports}}"

# Test endpoints
curl http://localhost:8080/health

Step 6: Update Strategy

Zero-downtime updates:

# Pull new images
docker compose pull

# Recreate services one at a time
docker compose up -d --no-deps --build web
docker compose up -d --no-deps --build api

# Remove old images
docker image prune -f

FoxTerm Compose Integration

FoxTerm simplifies Compose deployments.

Visual Stack Management

View all Compose stacks:

• Service status and health
• Resource usage per container
• Port mappings
• Volume mounts

One-Click Deploy

1. Paste or upload docker-compose.yml
2. Configure environment variables via UI
3. Click “Deploy”
4. FoxTerm uploads files, runs docker compose up -d, and shows real-time logs

Monitoring Dashboard

Monitor all services:

• CPU/memory usage graphs
• Log viewer with filtering
• Health check status
• Restart history

Stack Templates

Save common stacks as templates:

• LAMP stack (Linux, Apache, MySQL, PHP)
• MEAN stack (MongoDB, Express, Angular, Node)
• Monitoring stack (Prometheus, Grafana, Alertmanager)

Deploy with one click.

Conclusion

Docker Compose in production requires attention to health checks, resource limits, secrets, networking, and logging. Apply these best practices, and you’ll have reliable, secure multi-service deployments.

FoxTerm makes managing Compose stacks visual and straightforward, whether you’re running one service or twenty.

FoxTerm Pro includes Docker Compose management. Download at foxterm.app.

Docker health checks let containers report their status automatically. When a container becomes unhealthy, Docker can restart it, notify monitoring systems, or remove it from load balancers.

Why Health Checks Matter

Without health checks:

• Container running but app crashed
• Database accepting connections but can’t execute queries
• Web server up but returning 500 errors
• Manual intervention required

With health checks:

• Automatic failure detection
• Self-healing (auto-restart)
• Load balancer integration
• Monitoring alerts

Basic Health Check

Simple HTTP Check

# Dockerfile
FROM nginx:latest

# Add health check
HEALTHCHECK --interval=30s --timeout=10s --retries=3 \
  CMD curl -f http://localhost/ || exit 1

Or in compose:

# docker-compose.yml
services:
  web:
    image: nginx
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost/"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 40s

Health Check Fields

• test — Command to run (exit 0 = healthy, 1 = unhealthy)
• interval — Time between checks (default: 30s)
• timeout — Max time for check (default: 30s)
• retries — Failed checks before unhealthy (default: 3)
• start_period — Grace period for startup (default: 0s)

Common Health Check Patterns

Pattern 1: HTTP Endpoint

healthcheck:
  test: ["CMD", "curl", "-f", "http://localhost:8080/health"]
  interval: 30s
  timeout: 10s
  retries: 3

Application should return 200 OK when healthy:

// Node.js example
app.get('/health', (req, res) => {
  // Check dependencies
  if (db.connected && cache.connected) {
    res.status(200).json({ status: 'healthy' });
  } else {
    res.status(503).json({ status: 'unhealthy' });
  }
});

Pattern 2: Database Connection

healthcheck:
  test: ["CMD-SHELL", "pg_isready -U postgres"]
  interval: 10s
  timeout: 5s
  retries: 5

Pattern 3: Process Check

healthcheck:
  test: ["CMD-SHELL", "pidof nginx || exit 1"]
  interval: 30s
  timeout: 5s
  retries: 3

Pattern 4: Custom Script

healthcheck:
  test: ["CMD", "/app/healthcheck.sh"]
  interval: 30s
  timeout: 10s
  retries: 3

#!/bin/bash
# /app/healthcheck.sh

# Check database
if ! pg_isready -h db -U postgres; then
  echo "Database not ready"
  exit 1
fi

# Check cache
if ! redis-cli -h cache ping | grep -q PONG; then
  echo "Cache not ready"
  exit 1
fi

# Check disk space
if [ $(df /data | tail -1 | awk '{print $5}' | sed 's/%//') -gt 90 ]; then
  echo "Disk space low"
  exit 1
fi

echo "All checks passed"
exit 0

Advanced Health Checks

Multi-Stage Health Check

healthcheck:
  test: |
    bash -c '
      # Check if process is running
      pidof node || exit 1
      
      # Check HTTP endpoint
      curl -f http://localhost:3000/health || exit 1
      
      # Check database connection
      node -e "require('./db').check().then(() => process.exit(0)).catch(() => process.exit(1))"
    '
  interval: 30s
  timeout: 15s
  retries: 3

Gradual Health Check

healthcheck:
  test: |
    bash -c '
      # First 5 minutes: just check process
      if [ $$(ps -p 1 -o etimes=) -lt 300 ]; then
        pidof node || exit 1
      else
        # After 5 minutes: full health check
        curl -f http://localhost:3000/health || exit 1
      fi
    '
  interval: 10s
  timeout: 5s
  retries: 5
  start_period: 60s

Using Health Checks

View Health Status

# Check container health
docker ps
# Shows (healthy), (unhealthy), or (health: starting)

# Detailed health info
docker inspect --format='{{.State.Health.Status}}' container_name

# View health check logs
docker inspect --format='{{json .State.Health}}' container_name | jq

Auto-Restart Unhealthy Containers

services:
  web:
    image: myapp
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost/health"]
      interval: 30s
      retries: 3
    restart: on-failure

Load Balancer Integration

Nginx upstream with health checks:

upstream backend {
    server backend1:8080;
    server backend2:8080;
    
    # Requires nginx plus
    health_check interval=5s fails=3 passes=2;
}

HAProxy with health checks:

backend app
    balance roundrobin
    option httpchk GET /health
    server app1 app1:8080 check inter 5s fall 3 rise 2
    server app2 app2:8080 check inter 5s fall 3 rise 2

Docker Compose with Health Checks

Complete Example

version: '3.8'

services:
  db:
    image: postgres:16
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 10s
      timeout: 5s
      retries: 5
    volumes:
      - pgdata:/var/lib/postgresql/data

  cache:
    image: redis:7
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]
      interval: 10s
      timeout: 5s
      retries: 5

  web:
    image: myapp:latest
    depends_on:
      db:
        condition: service_healthy
      cache:
        condition: service_healthy
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:3000/health"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 40s
    restart: unless-stopped
    ports:
      - "80:3000"

volumes:
  pgdata:

The depends_on with condition: service_healthy ensures web starts only after db and cache are healthy.

Monitoring Health Checks

Prometheus Metrics

services:
  web:
    image: myapp
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost/health"]
    labels:
      - "prometheus-job=myapp"

Alerting

# docker-compose.yml
services:
  web:
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost/health"]
    restart: on-failure
    logging:
      driver: syslog
      options:
        syslog-address: "tcp://logs.example.com:514"

FoxTerm Health Check Support

FoxTerm makes health checks visual and manageable:

Health Dashboard

• Real-time health status for all containers
• Health check history and trends
• Failure notifications
• Quick restart actions

Health Check Editor

• Visual health check configuration
• Test health checks before deploying
• Template library for common patterns
• Validation and best practices

Integration

• Auto-detect health check status
• Alert on unhealthy containers
• One-click restart
• Health check logs viewer

Best Practices

1. Implement health endpoints — /health should check all dependencies
2. Set appropriate intervals — Don’t check too frequently (overhead) or too slowly (delayed detection)
3. Use start_period — Give apps time to initialize
4. Check dependencies — Health check should verify database, cache, etc.
5. Log health check results — Debug failures easily
6. Test health checks — Verify they work before production
7. Monitor trends — Track health check failures over time

Conclusion

Docker health checks enable self-healing containers that detect and recover from failures automatically. Combined with proper restart policies and monitoring, they significantly improve application reliability.

FoxTerm makes health checks visual and manageable, with real-time status and one-click actions.

FoxTerm Pro includes health check monitoring and management. Download at foxterm.app.

For years, the standard workflow for container management has been: install Docker Desktop on your Mac, connect to remote registries, and manage local containers. But what if your containers aren’t running locally? What if they’re on production servers, staging environments, or cloud instances?

FoxTerm offers a different approach: manage remote containers over SSH through a native interface. No local Docker daemon, no resource-heavy virtualization, no licensing fees.

The Traditional Workflow

Here’s how most developers manage remote containers today:

1. SSH into the server
2. Run docker ps to see running containers
3. Run docker logs <container> to check output
4. Run docker stop <container> to stop it
5. Repeat for each operation

This works, but it’s tedious. You’re constantly switching between terminal commands, remembering syntax, and parsing text output.

The FoxTerm Approach

Connect to your server once, and FoxTerm automatically detects if Docker or Podman is installed. If so, a full container management interface appears:

Visual Container List

See all running containers with:

• Status indicators (running, stopped, paused)
• Resource usage (CPU, memory)
• Port mappings
• Creation time

One click to view logs, stats, or take action.

One-Click Operations

• Start / Stop / Restart — No command memorization
• Pause / Unpause — Suspend without stopping
• Kill — Force stop unresponsive containers
• Remove — Clean up with confirmation dialogs

Real-Time Statistics

Monitor each container’s resource usage:

• CPU percentage with per-core breakdown
• Memory usage vs. limit
• Network I/O (bytes/sec)
• Disk I/O (read/write throughput)

No need to run docker stats manually — the data updates in real-time.

Compose Stack Deployment

This is where FoxTerm really shines. Deploying a Docker Compose stack traditionally involves:

1. Writing the YAML file locally
2. SCP/SFTP uploading it to the server
3. SSH-ing in to run docker compose up
4. Checking logs to verify everything started

FoxTerm streamlines this into a guided workflow:

Step 1: Define the Stack

Paste or write your docker-compose.yml in FoxTerm’s built-in editor (with syntax highlighting).

Step 2: Configure Environment

Add .env variables through a visual interface — no manual file editing.

Step 3: Deploy

FoxTerm creates the project directory, uploads files via SFTP, and runs docker compose up -d. You see real-time logs during deployment.

Step 4: Monitor

Once deployed, monitor all services in the container list. View aggregated logs or drill into individual services.

Podman Support

Everything that works with Docker works with Podman. FoxTerm auto-detects the runtime and uses appropriate commands. Rootless Podman containers are fully supported.

Why This Matters

Resource Efficiency: No local Docker daemon consuming RAM and CPU. Your Mac stays fast.

Security: Containers run on servers, not your laptop. Reduced attack surface.

Consistency: Manage dev, staging, and production environments through the same interface.

Simplicity: No need to remember complex Docker CLI commands. Everything is visual.

Advanced Features

Image Management

• List all images with size and creation date
• Pull images with progress tracking
• Remove unused images
• Prune dangling images

Volume & Network Management

• Create, list, and remove volumes
• Monitor volume disk usage
• Manage Docker networks (bridge, overlay, macvlan)
• Prune unused networks

System Operations

• Analyze disk usage (docker system df)
• Full system prune (containers, images, volumes, networks)
• View what will be removed before executing

The Bottom Line

FoxTerm transforms container management from a CLI chore into a visual workflow. Whether you’re deploying a single container or a multi-service Compose stack, everything happens through an intuitive interface — over SSH, on your terms.

Download FoxTerm at foxterm.app.

Hardcoding passwords in Docker images or compose files is a security disaster waiting to happen. Proper secrets management keeps credentials secure, rotatable, and auditable.

The Problem: Insecure Secrets

Bad Practice 1: Hardcoded in Dockerfile

# ❌ NEVER DO THIS
ENV DB_PASSWORD=supersecret123
ENV API_KEY=sk-1234567890abcdef

Why it’s bad:

• Secrets in image layers (visible with docker history)
• Pushed to registries with secrets exposed
• Can’t rotate without rebuilding image

Bad Practice 2: Hardcoded in Compose File

# ❌ NEVER DO THIS
services:
  db:
    image: postgres
    environment:
      POSTGRES_PASSWORD: supersecret123

Why it’s bad:

• Compose file in version control
• Secrets visible to anyone with repo access
• Same password across all environments

Bad Practice 3: .env File in Repo

# ❌ .env in git repo
DB_PASSWORD=supersecret123
API_KEY=sk-1234567890abcdef

Why it’s bad:

• Accidentally committed to git
• Visible in pull requests
• Shared with entire team

Docker Secrets (Swarm Mode)

Docker Swarm provides native secrets management.

Creating Secrets

# Create secret from string
echo "supersecret123" | docker secret create db_password -

# Create secret from file
docker secret create api_key ./api_key.txt

# List secrets
docker secret ls

# Inspect secret (metadata only, not value)
docker secret inspect db_password

Using Secrets in Services

# docker-compose.yml (Swarm mode)
version: '3.8'

services:
  db:
    image: postgres
    environment:
      POSTGRES_PASSWORD_FILE: /run/secrets/db_password
    secrets:
      - db_password

  api:
    image: myapp
    environment:
      API_KEY_FILE: /run/secrets/api_key
    secrets:
      - api_key

secrets:
  db_password:
    external: true
  api_key:
    external: true

Deploy:

docker stack deploy -c docker-compose.yml myapp

How Secrets Work

1. Secrets stored encrypted in Raft log
2. Only sent to nodes running services that need them
3. Mounted in memory at /run/secrets/<secret_name>
4. Not written to disk
5. Not visible in docker inspect

Accessing Secrets in Code

# Python example
def get_secret(secret_name):
    secret_path = f'/run/secrets/{secret_name}'
    with open(secret_path, 'r') as f:
        return f.read().strip()

db_password = get_secret('db_password')
api_key = get_secret('api_key')

// Node.js example
const fs = require('fs');

function getSecret(secretName) {
    return fs.readFileSync(`/run/secrets/${secretName}`, 'utf8').trim();
}

const dbPassword = getSecret('db_password');

Docker Compose Secrets (Non-Swarm)

Docker Compose supports secrets without Swarm.

File-Based Secrets

# docker-compose.yml
version: '3.8'

services:
  db:
    image: postgres
    environment:
      POSTGRES_PASSWORD_FILE: /run/secrets/db_password
    secrets:
      - db_password

secrets:
  db_password:
    file: ./secrets/db_password.txt

Create the secret file:

mkdir -p secrets
echo "supersecret123" > secrets/db_password.txt
chmod 600 secrets/db_password.txt

Add to .gitignore:

# .gitignore
secrets/

External Secrets

version: '3.8'

services:
  db:
    image: postgres
    secrets:
      - db_password

secrets:
  db_password:
    external: true

Create secret first:

docker secret create db_password ./secrets/db_password.txt

Environment Variables (Better Than Nothing)

If you can’t use Docker secrets, use environment variables with .env files.

.env File

# .env (NOT in git)
DB_PASSWORD=supersecret123
API_KEY=sk-1234567890abcdef

Compose File

# docker-compose.yml
version: '3'

services:
  db:
    image: postgres
    environment:
      POSTGRES_PASSWORD: ${DB_PASSWORD}
  
  api:
    image: myapp
    environment:
      API_KEY: ${API_KEY}

Security Measures

# Restrict .env file permissions
chmod 600 .env

# Add to .gitignore
echo ".env" >> .gitignore

# Verify not in git
git check-ignore .env
# Should output: .env

Podman Secrets

Podman provides similar secrets management.

Creating Secrets

# Create secret
echo "supersecret123" | podman secret create db_password -

# List secrets
podman secret ls

# Inspect
podman secret inspect db_password

Using Secrets

# containers.conf or compose file
version: '3.8'

services:
  db:
    image: postgres
    environment:
      POSTGRES_PASSWORD_FILE: /run/secrets/db_password
    secrets:
      - source: db_password
        target: db_password

External Secret Managers

For production, integrate with dedicated secret managers.

HashiCorp Vault

# Start Vault server
vault server -dev

# Store secret
vault kv put secret/myapp/db password=supersecret123

# Retrieve secret
vault kv get secret/myapp/db

Integration with Docker:

import hvac

client = hvac.Client(url='http://vault:8200', token='your-token')
secret = client.secrets.kv.v2.read_secret_version(path='myapp/db')
db_password = secret['data']['data']['password']

AWS Secrets Manager

import boto3

client = boto3.client('secretsmanager')
response = client.get_secret_value(SecretId='myapp/db-password')
db_password = response['SecretString']

Azure Key Vault

from azure.keyvault.secrets import SecretClient
from azure.identity import DefaultAzureCredential

credential = DefaultAzureCredential()
client = SecretClient(vault_url='https://myvault.vault.azure.net/', credential=credential)
db_password = client.get_secret('db-password').value

Google Secret Manager

from google.cloud import secretmanager

client = secretmanager.SecretManagerServiceClient()
name = f'projects/my-project/secrets/db-password/versions/latest'
response = client.access_secret_version(name=name)
db_password = response.payload.data.decode('UTF-8')

Secret Rotation

Rotate secrets regularly without downtime.

Manual Rotation

# 1. Create new secret
echo "newpassword123" | docker secret create db_password_v2 -

# 2. Update service to use new secret
docker service update \
  --secret-rm db_password \
  --secret-add db_password_v2 \
  myapp_db

# 3. Remove old secret
docker secret rm db_password

# 4. Rename new secret (optional)
docker secret create db_password - <<EOF
newpassword123
EOF

Automated Rotation

#!/bin/bash
# rotate-secrets.sh

# Generate new password
new_password=$(openssl rand -base64 32)

# Create new secret
echo "$new_password" | docker secret create db_password_new -

# Update service
docker service update \
  --secret-rm db_password \
  --secret-add db_password_new \
  myapp_db

# Wait for rollout
sleep 10

# Remove old secret
docker secret rm db_password

# Rename
docker secret create db_password - <<< "$new_password"
docker secret rm db_password_new

FoxTerm Secrets Management

FoxTerm simplifies secrets management for Docker/Podman.

Visual Secrets Editor

• View all secrets in Compose stacks
• Edit secret values securely
• Rotate secrets with one click
• Audit log of secret access

Secure Storage

• Secrets stored in macOS Keychain
• Encrypted at rest
• Biometric authentication required
• Never logged or displayed in plain text

Integration

• Auto-detect secret references in compose files
• Prompt to create missing secrets
• Validate secret permissions
• Sync secrets across environments

Best Practices

1. Never hardcode secrets — Use Docker secrets or external managers
2. Rotate regularly — Change passwords every 90 days
3. Limit access — Only grant secrets to services that need them
4. Audit access — Log who accessed what secrets when
5. Use strong secrets — 32+ characters, random generation
6. Separate environments — Different secrets for dev/staging/prod
7. Encrypt at rest — Use encrypted storage for secret files
8. Use secret managers — Vault, AWS Secrets Manager, etc. for production

Conclusion

Secure secrets management is non-negotiable for production containers. Docker secrets, Podman secrets, and external vaults provide the tools you need to keep credentials secure.

FoxTerm makes secrets management visual and secure, with Keychain integration and one-click rotation.

FoxTerm Pro includes secrets management for Docker/Podman. Download at foxterm.app.

Every developer’s desktop eventually looks the same: a terminal emulator here, an SFTP client there, a VNC viewer somewhere else, a Docker dashboard in yet another window. Four apps, four different UIs, four separate licenses, and a dozen tabs of context-switching every time you touch a remote server.

FoxTerm for macOS collapses all of that into one native application. SSH terminal, SFTP file manager, Metal-accelerated VNC desktop, and Docker/Podman management — unified under a single interface, with zero telemetry and one purchase that covers both macOS and iOS.

This is not another Electron wrapper. This is a ground-up native build for Apple silicon.

High-Performance SSH Terminal with Real-Time System Monitoring

The terminal is the heart of any remote workflow, and FoxTerm’s SSH engine is built for speed. Powered by the Ghostty terminal engine, it delivers GPU-accelerated rendering at 120fps on ProMotion displays — the kind of smoothness you feel before you measure it.

But what sets FoxTerm apart is the integrated system monitoring sidebar. While you work in your terminal, a live dashboard tracks:

• CPU usage with per-core breakdown
• Memory allocation and swap pressure
• Temperature sensors across all cores
• Network throughput with upload/download separation
• Disk I/O with read/write metrics

No more htop in a split pane. No more SSH-ing into a second session just to check load. The sidebar pulls metrics over the same SSH connection using lightweight system calls, so there’s zero additional latency or resource cost on the remote host.

The terminal itself supports full ANSI 256-color and true-color output, ligatures, custom keybindings, and seamless copy-paste with the macOS system clipboard. It runs OpenWrt, Ubuntu, Alpine, RHEL — anything with an SSH daemon.

SFTP File Manager: Your Server’s Filesystem, Native Feel

Browsing remote files shouldn’t require a separate application. FoxTerm’s SFTP file manager gives you a native macOS file browser experience against any SSH server.

Key capabilities:

• Tree-based navigation with grouped connections — organize servers by environment (production, staging, development) or geography
• Detailed file inspection — permissions, UID/GID, owner, group, and timestamps at a glance
• Drag-and-drop transfers between local and remote filesystems
• Multi-protocol support — works with OpenSSH, Dropbear, and any SFTP-compatible server
• Instant file stats — total, used, and available disk space displayed inline

The file manager shares the same SSH connection as your terminal session. Switch between terminal and SFTP without re-authenticating, without opening a new connection, without losing context. When you edit a remote file, it opens in your preferred local editor and syncs back on save.

For teams managing dozens of servers across multiple regions, the grouped sidebar becomes indispensable. Hong Kong nodes, Singapore clusters, Japan instances, US-East production — all organized, all one click away.

Metal-Accelerated VNC Desktop: Remote GUI at Native Frame Rates

Sometimes you need a full desktop, not just a terminal. FoxTerm’s VNC client is built on Apple’s Metal graphics framework, delivering hardware-accelerated remote desktop rendering that traditional VNC clients simply cannot match.

The difference is immediately visible:

• 40+ FPS on a 1280×800 remote desktop, even over moderate-latency connections
• H.264-style compression via efficient frame differencing — only changed pixels travel over the wire
• Metal shader pipeline for decoding and display, bypassing CPU bottlenecks entirely
• Full clipboard integration — copy text and images between local and remote desktops

The VNC viewer supports XFCE, GNOME, KDE, and any VNC-compatible desktop environment. Whether you’re managing a headless Ubuntu server with a lightweight XFCE session or administering a full GNOME workstation, the experience feels like a local window.

The status bar shows real-time metrics: current FPS, resolution, bandwidth usage, and connection latency. You always know exactly how your remote session is performing.

Docker & Podman Management: Container Ops Without Docker Desktop

Managing containers on remote servers typically means SSH-ing in and typing docker ps over and over. FoxTerm brings container management into a visual dashboard that works with both Docker and Podman.

The dashboard provides:

• Cluster overview — total containers, volumes, networks, and images at a glance
• Engine details — version, OS, architecture, CPU count, and memory allocation
• Per-container metrics — CPU%, memory usage, network I/O, and disk I/O with live sparkline graphs
• Tabbed interface — switch between containers, compose, images, networks, and data volumes
• Real-time system monitoring — the same sidebar from the SSH terminal, now showing the Docker host’s resource utilization

Whether you’re running Docker 24.x LTS on Ubuntu or Podman with Quadlet services, FoxTerm connects over SSH and speaks the native API. No exposed TCP ports, no Docker Desktop license, no cloud dependency. Your containers stay on your infrastructure, managed from your Mac.

The container list shows everything: timemachine backups, Gitea instances, SSH gateways, KDC servers, VNC servers — each with live resource metrics updating in real time.

One App, Zero Telemetry, One Purchase

Every feature above runs in a single application. No plugin ecosystem to manage, no compatibility matrix between tools, no conflicting keyboard shortcuts between your terminal and your file manager.

More importantly: FoxTerm sends zero telemetry. No analytics, no crash reports to third parties, no usage tracking, no account required. Your server credentials, connection logs, and workflow patterns never leave your machine. This isn’t a marketing claim — it’s an architectural guarantee. The app has no network calls beyond the SSH/VNC connections you explicitly initiate.

The pricing is straightforward — one purchase covers both macOS and iOS. No per-seat licensing, no enterprise tiers, no feature gates. Every feature described above is included in every license.

Built for Apple Silicon, Not Ported to It

FoxTerm was not an Electron app wrapped in a native shell. It was not a Java application running on the JVM. It was built from day one with:

• Swift for the application layer
• Metal for GPU-accelerated rendering (terminal and VNC)
• Secure Enclave integration for SSH key storage
• Native macOS UI — window management, tabbing, split views, and keyboard shortcuts that match system conventions
• iOS parity — the same codebase adapts to touch input and smaller screens without compromise

The result is an app that launches in under a second, uses a fraction of the memory of Electron-based alternatives, and renders at the full refresh rate of your display.

Who Is FoxTerm For?

• DevOps engineers managing fleets of servers across multiple cloud providers
• System administrators who need SSH, file transfer, and remote desktop in one workflow
• Full-stack developers running Docker containers on remote build servers
• Security-conscious professionals who refuse to use tools that phone home
• Apple ecosystem users who want the same tool on Mac, iPad, and iPhone

If you currently have Terminal.app (or iTerm2), FileZilla, RealVNC, and Portainer open at the same time — FoxTerm replaces all four.

Get Started

FoxTerm is available on the Mac App Store and at foxterm.app. Download the trial, connect to your first server, and see what a unified remote workflow feels like.

Every great product starts with a problem. For FoxTerm, that problem was simple: existing SSH clients weren’t good enough.

The Frustration

Like many developers, we spent hours every day SSH-ing into servers. We tried dozens of clients:

• Terminal.app — Too basic, no tabs, limited customization
• iTerm2 — Powerful but bloated, slow startup, Electron-like resource usage
• Tabby — Web-based, sluggish, frequent crashes
• Warp — Interesting AI features, but heavy and proprietary
• Electron-based clients — Slow, memory-hungry, disconnected from the OS

None felt right. They were either too simple (missing features we needed) or too complex (buried under layers of abstraction).

The Decision

In early 2024, we made a decision: build our own SSH client. Not as a business plan, but as a craft project. We wanted something that:

• Felt native on macOS and iOS
• Was fast and responsive
• Respected our privacy
• Looked beautiful
• Actually enjoyed using

The Architecture

We started with a blank slate and clear principles:

1. Native First

Swift and SwiftUI for UI. No Electron, no WebView, no cross-platform abstractions. If it runs on Apple platforms, it should feel like an Apple app.

2. Modular Design

Instead of a monolithic codebase, we organized features into modules: SSH, VNC, SFTP, Terminal, Crypto, etc. Each module has a single responsibility and clear boundaries.

3. Best-of-Breed Dependencies

We didn’t reinvent everything:

• Ghostty for terminal emulation (GPU-accelerated)
• libssh for SSH protocol
• libvncclient for VNC
• OpenSSL for cryptography

But we wrapped them carefully, adding our own optimizations and security layers.

4. Security by Default

Secure Enclave support for SSH keys. App Sandbox containment. Zero telemetry. These aren’t afterthoughts — they’re foundational.

The Development Process

Phase 1: Core SSH (Months 1-3)

Basic SSH terminal with:

• Password and key authentication
• PTY allocation
• Basic terminal rendering

We used Ghostty early, which saved months of terminal emulation work.

Phase 2: SFTP & File Management (Months 4-6)

Added:

• SFTP file browser
• Drag-and-drop upload/download
• Remote file editing

This transformed FoxTerm from a terminal into a workflow tool.

Phase 3: VNC Remote Desktop (Months 7-9)

Integrated libvncclient with:

• SSH tunneling
• Touch gestures for iOS
• Performance optimizations

Now FoxTerm could handle graphical remote access.

Phase 4: Docker/Podman UI (Months 10-12)

Added container management:

• Visual container list
• Compose stack deployment
• Real-time monitoring

This was the feature that surprised users most — an SSH client managing containers?

Phase 5: Polish & Launch (Months 13-15)

Refined the UI, added themes, improved performance, and prepared for launch.

The Launch

We launched on the Mac App Store in mid-2025 with:

• macOS 14.0+ support
• iOS/iPadOS 17.0+ support
• Free core features
• Pro upgrade for advanced features

Response was overwhelming. Within weeks, we had thousands of users and hundreds of reviews.

What Users Said

“Finally, an SSH client that doesn’t feel like it was built in 2005.”

“The VNC integration is genius. I manage headless servers visually now.”

“Zero telemetry? In 2025? This is the app I’ve been waiting for.”

“Docker management over SSH is a game-changer. No more CLI gymnastics.”

The Business Model

FoxTerm is free for core features:

• SSH terminal
• SFTP file manager
• Basic VNC
• Port forwarding

Pro features (starting at $1.99/month, or $29.99 lifetime):

• Unlimited SSH/VNC/SFTP/Docker connections
• Advanced VNC (JPEG compression, certificate auth)
• Docker/Podman UI with visual management
• Real-time system monitoring
• Zero telemetry, complete privacy
• Priority support
• Instant license key delivery

We chose affordable pricing because we believe professional tools should be accessible. Visit pay.foxterm.app for all pricing options.

What’s Next

The roadmap includes:

• SSH certificates — Enterprise-scale key management
• Team sharing — Share connections securely
• Custom themes — User-created theme marketplace
• Plugin system — Extend FoxTerm with custom features
• Linux support — Yes, really (via Flatpak)

The Philosophy

FoxTerm isn’t trying to be everything to everyone. It’s a tool for developers who care about:

• Craftsmanship — Well-built software that respects your time
• Privacy — No surveillance, no data collection
• Performance — Fast, responsive, efficient
• Beauty — Tools should be pleasant to use

We’re not a venture-backed startup chasing growth. We’re craftspeople building tools we want to use ourselves.

Join Us

FoxTerm is available on the Mac App Store for macOS, iPadOS, and iOS. Try it free, upgrade if you love it.

And if you have ideas, bug reports, or just want to say hi — we’re listening. Email us at support@foxterm.app or find us on GitHub.

Thanks for being part of the journey.

Download FoxTerm at foxterm.app.

Most terminal emulators are stuck in the past: CPU-rendered text, sluggish scrolling, and frame drops during heavy output. FoxTerm takes a different approach by integrating Ghostty, a modern terminal engine that leverages GPU acceleration for buttery-smooth 120fps rendering.

Why Ghostty?

When we evaluated terminal engines, we tested everything:

xterm.js (Web-based):

• ❌ Canvas rendering limited to 30-60fps
• ❌ JavaScript overhead for escape sequence parsing
• ❌ No native macOS/iOS integration
• ❌ Memory bloat from DOM manipulation

Terminal.app framework (Apple):

• ❌ Closed source, limited customization
• ❌ No GPU acceleration
• ❌ Stuck at 60fps even on ProMotion displays
• ❌ Poor ANSI 24-bit color support

Alacritty (Rust):

• ✅ GPU-accelerated
• ❌ No library interface (standalone app only)
• ❌ Can’t embed in SwiftUI apps
• ❌ Linux/Windows focused

Ghostty (Zig):

• ✅ GPU-accelerated with Metal
• ✅ Library interface for embedding
• ✅ Native macOS/iOS support
• ✅ 120fps on ProMotion displays
• ✅ Full ANSI/VT100/VT220 support
• ✅ True color (24-bit) support
• ✅ Ligature support
• ✅ Minimal memory footprint

Architecture Overview

FoxTerm’s terminal architecture:

┌─────────────────────────────────────────────┐
│           SwiftUI Terminal View             │
│  (Native macOS/iOS UI, Tab Management)      │
└──────────────────┬──────────────────────────┘
                   │
┌──────────────────▼──────────────────────────┐
│         Ghostty Terminal Engine             │
│  ┌──────────────────────────────────────┐  │
│  │  Metal Renderer (GPU-Accelerated)    │  │
│  │  - Text rendering via Metal shaders  │  │
│  │  - Ligature support                  │  │
│  │  - Subpixel antialiasing             │  │
│  └──────────────────────────────────────┘  │
│  ┌──────────────────────────────────────┐  │
│  │  VT Parser (ANSI/VT100/VT220)        │  │
│  │  - Escape sequence state machine     │  │
│  │  - CSI/OSC/DCS handler               │  │
│  │  - UTF-8 validation                  │  │
│  └──────────────────────────────────────┘  │
│  ┌──────────────────────────────────────┐  │
│  │  Grid Manager                        │  │
│  │  - Cell buffer (scrollback)          │  │
│  │  - Dirty rect tracking               │  │
│  │  - Selection & cursor                │  │
│  └──────────────────────────────────────┘  │
└──────────────────┬──────────────────────────┘
                   │
┌──────────────────▼──────────────────────────┐
│           PTY (Pseudo-Terminal)             │
│  - fork/exec or SSH channel                 │
│  - Input/output buffering                   │
│  - Signal handling (SIGWINCH)               │
└─────────────────────────────────────────────┘

Metal Rendering Pipeline

Text Rendering with Metal Shaders

Ghostty uses Metal shaders to render text at GPU speed:

// Simplified Metal shader for text rendering
vertex VertexOut text_vertex(uint vertex_id [[vertex_id]]) {
    // Generate fullscreen quad
    float2 positions[4] = {
        float2(-1, -1), float2(1, -1),
        float2(-1, 1),  float2(1, 1)
    };
    
    VertexOut out;
    out.position = float4(positions[vertex_id], 0, 1);
    out.tex_coord = (positions[vertex_id] + 1) / 2;
    return out;
}

fragment float4 text_fragment(VertexOut in [[stage_in]],
                              texture2d<float> glyph_atlas [[texture(0)]],
                              sampler samp [[sampler(0)]]) {
    float4 color = glyph_atlas.sample(samp, in.tex_coord);
    // Subpixel antialiasing for crisp text
    return color;
}

Glyph Atlas

Instead of rendering each character individually, Ghostty pre-renders glyphs into a texture atlas:

// Glyph atlas management
class GlyphAtlas {
    private var texture: MTLTexture
    private var glyphs: [GlyphKey: GlyphRect] = [:]
    
    func getGlyph(codepoint: UInt32, style: FontStyle) -> GlyphRect {
        let key = GlyphKey(codepoint: codepoint, style: style)
        
        if let rect = glyphs[key] {
            return rect  // Cache hit
        }
        
        // Render new glyph to atlas
        let rect = renderGlyphToAtlas(codepoint, style)
        glyphs[key] = rect
        return rect
    }
}

Benefits:

• Single texture bind per frame
• Batch rendering of all text
• 10x faster than per-character rendering

Dirty Rect Optimization

Not every frame needs full redraw. Ghostty tracks “dirty rects” — regions that changed:

struct DirtyRect {
    var x: Int
    var y: Int
    var width: Int
    var height: Int
}

class GridManager {
    private var dirtyRects: [DirtyRect] = []
    
    func markDirty(x: Int, y: Int, width: Int, height: Int) {
        dirtyRects.append(DirtyRect(x: x, y: y, width: width, height: height))
    }
    
    func render() {
        // Only re-render dirty regions
        for rect in dirtyRects {
            renderRegion(rect)
        }
        dirtyRects.removeAll()
    }
}

Result: Typing a single character only re-renders one cell, not the entire screen.

PTY Management

macOS PTY

On macOS, FoxTerm uses forkpty() to create pseudo-terminals:

import Darwin

func createPTY() -> (master: Int32, slave: Int32) {
    var master: Int32 = 0
    var slave: Int32 = 0
    
    var winSize = winsize(
        ws_row: UInt16(24),
        ws_col: UInt16(80),
        ws_xpixel: 0,
        ws_ypixel: 0
    )
    
    let result = forkpty(&master, nil, nil, &winSize)
    
    if result == 0 {
        // Child process
        execl("/bin/zsh", "zsh", nil)
        exit(1)
    }
    
    slave = result
    return (master, slave)
}

SSH Channel PTY

For SSH connections, FoxTerm creates a PTY over the SSH channel:

func openSSHPTY(session: SSHSession) -> SSHChannel {
    let channel = session.openChannel(type: "session")
    
    // Request PTY
    channel.requestPTY(
        term: "xterm-256color",
        columns: 80,
        rows: 24,
        pixelWidth: 640,
        pixelHeight: 480,
        modes: terminalModes
    )
    
    // Request shell
    channel.requestShell()
    
    return channel
}

Window Resize Handling

When the terminal window resizes, FoxTerm sends SIGWINCH to the child process:

func handleResize(newSize: NSSize) {
    let columns = Int(newSize.width / cellWidth)
    let rows = Int(newSize.height / cellHeight)
    
    // Update PTY size
    var winSize = winsize(
        ws_row: UInt16(rows),
        ws_col: UInt16(columns),
        ws_xpixel: UInt16(newSize.width),
        ws_ypixel: UInt16(newSize.height)
    )
    
    ioctl(masterFD, TIOCSWINSZ, &winSize)
    
    // Notify child process
    kill(childPID, SIGWINCH)
}

ANSI Escape Sequence Parsing

State Machine Parser

Ghostty uses a state machine to parse ANSI escape sequences:

enum ParserState {
    case ground
    case escape
    case escapeIntermediate
    case csiEntry
    case csiParam
    case csiIntermediate
    case oscString
    case dcsEntry
}

class VTParser {
    private var state: ParserState = .ground
    private var params: [Int] = []
    
    func feed(byte: UInt8) {
        switch state {
        case .ground:
            if byte == 0x1B {  // ESC
                state = .escape
            } else if byte >= 0x20 && byte <= 0x7E {
                // Printable character
                emitCharacter(Character(UnicodeScalar(byte)))
            }
            
        case .escape:
            if byte == UInt8(ascii: "[") {
                state = .csiEntry
                params.removeAll()
            } else if byte == UInt8(ascii: "]") {
                state = .oscString
            }
            
        case .csiEntry:
            if byte >= UInt8(ascii: "0") && byte <= UInt8(ascii: "9") {
                state = .csiParam
                params.append(Int(byte - UInt8(ascii: "0")))
            }
            
        case .csiParam:
            if byte == UInt8(ascii: ";") {
                params.append(0)
            } else if byte >= UInt8(ascii: "0") && byte <= UInt8(ascii: "9") {
                let last = params.count - 1
                params[last] = params[last] * 10 + Int(byte - UInt8(ascii: "0"))
            } else if byte >= 0x40 && byte <= 0x7E {
                // Final byte - execute CSI sequence
                executeCSI(params: params, finalByte: byte)
                state = .ground
            }
            
        default:
            break
        }
    }
    
    private func executeCSI(params: [Int], finalByte: UInt8) {
        switch finalByte {
        case UInt8(ascii: "m"):
            // SGR - Select Graphic Rendition
            handleSGR(params)
        case UInt8(ascii: "H"):
            // CUP - Cursor Position
            setCursorPosition(row: params[0], col: params[1])
        case UInt8(ascii: "J"):
            // ED - Erase Display
            eraseDisplay(mode: params[0])
        default:
            break
        }
    }
}

SGR (Select Graphic Rendition)

SGR sequences control text formatting:

func handleSGR(_ params: [Int]) {
    var i = 0
    while i < params.count {
        let code = params[i]
        
        switch code {
        case 0:  // Reset
            currentStyle = TextStyle()
        case 1:  // Bold
            currentStyle.bold = true
        case 3:  // Italic
            currentStyle.italic = true
        case 4:  // Underline
            currentStyle.underline = true
        case 30...37:  // Foreground color (standard)
            currentStyle.foreground = Color.ansi(code - 30)
        case 38:  // Extended foreground
            if i + 1 < params.count && params[i + 1] == 5 {
                // 256-color: 38;5;n
                currentStyle.foreground = Color.ansi256(params[i + 2])
                i += 2
            } else if i + 1 < params.count && params[i + 1] == 2 {
                // True color: 38;2;r;g;b
                currentStyle.foreground = Color.rgb(
                    r: params[i + 2],
                    g: params[i + 3],
                    b: params[i + 4]
                )
                i += 4
            }
        case 40...47:  // Background color (standard)
            currentStyle.background = Color.ansi(code - 40)
        default:
            break
        }
        
        i += 1
    }
}

Performance Benchmarks

Frame Rate Comparison

Test: Output 10,000 lines of text, measure frame rate:

Memory Usage

Test: Open 10 terminal tabs, each with 10,000 lines of scrollback:

FoxTerm Enhancements

Ligature Support

FoxTerm supports programming ligatures (Fira Code, JetBrains Mono):

func renderLigatures(text: String) -> [GlyphSequence] {
    var sequences: [GlyphSequence] = []
    var i = 0
    
    while i < text.count {
        // Check for ligature patterns
        if let ligature = matchLigature(text, at: i) {
            sequences.append(GlyphSequence(
                glyphs: ligature.glyphs,
                width: ligature.width,
                isLigature: true
            ))
            i += ligature.charCount
        } else {
            sequences.append(GlyphSequence(
                glyphs: [text[i]],
                width: cellWidth,
                isLigature: false
            ))
            i += 1
        }
    }
    
    return sequences
}

Subpixel Antialiasing

On macOS, FoxTerm uses subpixel antialiasing for crisp text:

fragment float4 subpixel_fragment(VertexOut in [[stage_in]]) {
    float3 rgb = glyph_atlas.sample(samp, in.tex_coord).rgb;
    
    // Apply subpixel rendering
    float alpha = (rgb.r + rgb.g + rgb.b) / 3.0;
    
    // Blend with background
    float3 blended = mix(bg_color.rgb, text_color.rgb, alpha);
    
    return float4(blended, 1.0);
}

Retina Display Support

FoxTerm automatically scales for Retina displays:

let scale = window.backingScaleFactor  // 2.0 for Retina
let cellWidth = baseCellWidth * scale
let cellHeight = baseCellHeight * scale

// Render at 2x resolution
texture = device.makeTexture(
    width: Int(gridWidth * scale),
    height: Int(gridHeight * scale),
    ...
)

Conclusion

Ghostty brings modern GPU-accelerated terminal rendering to native macOS and iOS apps. By leveraging Metal shaders, dirty rect optimization, and efficient escape sequence parsing, FoxTerm delivers 120fps terminal performance with minimal resource usage.

The result: a terminal that feels as fast as the hardware allows, whether you’re on a MacBook Pro with ProMotion or an iPad with Apple Silicon.

FoxTerm Pro includes the Ghostty terminal engine with GPU acceleration. Download at foxterm.app.

Imagine this scenario: You have a PostgreSQL database running on a production server. It’s bound to localhost:5432 for security — not exposed to the public internet. How do you connect to it from your local development machine?

Option 1: Temporarily modify the server’s firewall rules (risky). Option 2: Set up a VPN (overkill for a one-off task). Option 3: Use SSH local port forwarding (the right way).

FoxTerm makes option 3 effortless.

What Is Local Port Forwarding?

Local port forwarding creates a secure tunnel through your SSH connection:

Local Machine          SSH Tunnel           Remote Server
┌─────────────┐                           ┌──────────────────┐
│             │   Encrypted SSH Connection │                  │
│ localhost   │◄─────────────────────────►│ Remote Service   │
│ :8080       │                           │ :5432            │
└─────────────┘                           └──────────────────┘

You connect to localhost:8080 on your Mac, and the traffic is forwarded through SSH to remote-server:5432.

FoxTerm’s Implementation

FoxTerm uses Apple’s Network framework (NWListener) combined with libssh’s forwarding API to create robust, high-performance tunnels.

TCP Forwarding

Forward any TCP port:

# Traditional SSH command
ssh -L 8080:localhost:5432 user@server

# FoxTerm: Just click "Forward Port" in the UI

Use cases:

• Database access — Connect local pgAdmin/DBeaver to remote databases
• Admin panels — Access web interfaces bound to localhost
• APIs — Test internal APIs from your local environment
• Redis/MongoDB — Connect local clients to remote instances

Unix Socket Forwarding

This is where FoxTerm gets interesting. It can forward Unix domain sockets:

# Forward remote Docker socket to local path
ssh -L /var/run/docker.sock:/var/run/docker.sock user@server

# Now local Docker CLI manages remote containers
docker ps  # Shows containers on the remote server!

This enables powerful workflows:

• Remote Docker management — Use local Docker CLI to control remote daemons
• Systemd socket access — Interact with systemd services remotely
• Application sockets — Connect to apps that expose Unix sockets

Bidirectional Streaming

FoxTerm implements bidirectional stream bridging with 64KB buffers for maximum throughput. Data flows seamlessly in both directions:

• Local → Remote: Your requests reach the remote service
• Remote → Local: Responses return to your local client

No buffering delays, no connection drops.

Multiple Forwards

Create multiple forwarding rules simultaneously:

• Forward localhost:8080 → remote:80 (web server)
• Forward localhost:5432 → remote:5432 (PostgreSQL)
• Forward localhost:6379 → remote:6379 (Redis)

Manage all forwards from a single interface. Enable/disable individually without reconnecting.

Security Benefits

Encryption

All forwarded traffic is encrypted within the SSH tunnel. Even on public Wi-Fi, your database credentials and API tokens are safe.

No Firewall Changes

Since the connection originates from inside the server (via SSH), you don’t need to open inbound ports. The server’s firewall remains locked down.

Temporary Access

Forwards exist only while the SSH session is active. Disconnect, and the tunnel closes automatically. No lingering exposure.

Use Cases

Database Administration

Connect local database tools (TablePlus, Postico, DBeaver) to remote databases without exposing them to the internet.

Web Development

Access staging environments bound to localhost. Test APIs, debug webhooks, or preview internal dashboards.

Microservices Debugging

Forward ports to individual microservices running on remote Kubernetes nodes or Docker Swarm clusters.

IoT Device Management

SSH into a gateway device, then forward ports to IoT devices on the local network that aren’t directly accessible.

CI/CD Pipeline Testing

Forward ports to CI runners to test deployment scripts or inspect build artifacts.

Advanced Features

Automatic Reconnection

If the SSH connection drops, FoxTerm attempts to re-establish forwards automatically. No manual intervention needed.

Traffic Statistics

Monitor bytes sent/received through each forward. Identify high-bandwidth tunnels or unexpected activity.

Custom Bind Addresses

Bind forwards to specific interfaces:

• localhost — Only accessible from your Mac
• 0.0.0.0 — Accessible from other devices on your network (use with caution)

The Bottom Line

Local port forwarding is one of SSH’s most powerful features — and FoxTerm makes it accessible to everyone. No command-line memorization, no complex configuration. Just point, click, and connect.

Download FoxTerm at foxterm.app.

In enterprise networks, internal servers aren’t directly accessible from the internet. You must chain SSH connections through bastion hosts (jump servers) to reach them. This guide covers secure multi-hop SSH patterns.

Why Multi-Hop SSH?

Network architecture:

Internet → Bastion Host → Internal Server

Benefits:

• ✅ Single entry point (easier to secure)
• ✅ Audit all access centrally
• ✅ Internal servers not exposed to internet
• ✅ Centralized key management

Method 1: ProxyJump (Recommended)

ProxyJump is the modern, clean way to chain SSH connections.

Basic ProxyJump

# ~/.ssh/config
Host bastion
    HostName bastion.example.com
    User admin
    IdentityFile ~/.ssh/bastion_key

Host internal
    HostName internal-server.local
    User deploy
    ProxyJump bastion

Usage:

ssh internal
# Automatically connects: you → bastion → internal

Multiple Jump Hosts

Host region-bastion
    HostName bastion.region.example.com

Host zone-bastion
    HostName bastion.zone.example.com
    ProxyJump region-bastion

Host server
    HostName server.internal
    ProxyJump zone-bastion

Connection path: you → region-bastion → zone-bastion → server

ProxyJump with Different Users

Host bastion
    HostName bastion.example.com
    User admin

Host internal
    HostName internal.local
    User deploy
    ProxyJump admin@bastion.example.com

Method 2: ProxyCommand (Legacy)

ProxyCommand is the older method, still useful for complex scenarios.

Basic ProxyCommand with nc

Host internal
    HostName internal.local
    User deploy
    ProxyCommand ssh bastion nc %h %p 2>/dev/null

ProxyCommand with -W flag

Host internal
    HostName internal.local
    User deploy
    ProxyCommand ssh -W %h:%p bastion

The -W flag is cleaner than nc.

ProxyCommand with Custom Port

Host internal
    HostName internal.local
    Port 2222
    ProxyCommand ssh -W %h:%p bastion

Method 3: Agent Forwarding

Agent forwarding lets you use your local SSH key on intermediate hosts.

Enable Agent Forwarding

# ~/.ssh/config
Host bastion
    HostName bastion.example.com
    ForwardAgent yes

Host internal
    HostName internal.local
    ProxyJump bastion

⚠️ Security warning: Only enable ForwardAgent on trusted hosts.

How It Works

Your Mac (SSH key) → Bastion (uses your key) → Internal Server

Your private key never leaves your Mac, but bastion can authenticate to internal servers using it.

Practical Examples

Example 1: AWS VPC Access

# Bastion in public subnet
Host aws-bastion
    HostName bastion.ap-southeast-1.compute.amazonaws.com
    User ec2-user
    IdentityFile ~/.ssh/aws_key.pem

# EC2 instance in private subnet
Host aws-internal
    HostName ip-10-0-1-100.ec2.internal
    User ec2-user
    IdentityFile ~/.ssh/aws_key.pem
    ProxyJump aws-bastion

Example 2: Corporate Network

# Corporate bastion
Host corp
    HostName bastion.corp.example.com
    User $USER
    CertificateFile ~/.ssh/corp-cert.pub

# Development server
Host dev
    HostName dev.internal.corp.example.com
    User developer
    ProxyJump corp

# Production server
Host prod
    HostName prod.internal.corp.example.com
    User deploy
    ProxyJump corp

Example 3: Multi-Region Setup

# US bastion
Host us-bastion
    HostName bastion.us.example.com

# EU bastion via US
Host eu-bastion
    HostName bastion.eu.example.com
    ProxyJump us-bastion

# EU server via both bastions
Host eu-server
    HostName server.eu.internal
    ProxyJump eu-bastion

Port Forwarding Through Bastions

Local Port Forwarding

# Forward internal PostgreSQL to local port
ssh -L 5432:internal-db:5432 bastion

# Or with ProxyJump
ssh -L 5432:localhost:5432 internal

Now connect to localhost:5432 to reach internal database.

Dynamic Port Forwarding (SOCKS)

# Create SOCKS proxy through bastion
ssh -D 1080 bastion

# Configure browser to use SOCKS proxy at localhost:1080
# All traffic routes through bastion

Remote Port Forwarding

# Expose local service to internal network
ssh -R 8080:localhost:3000 internal

Now internal server can access your local port 3000 via its port 8080.

Security Best Practices

1. Restrict Bastion Access

# /etc/ssh/sshd_config on bastion
AllowUsers admin deploy
AllowGroups ssh-users
PasswordAuthentication no

2. Use Certificates

# ~/.ssh/config
Host bastion
    CertificateFile ~/.ssh/id_ed25519-cert.pub
    IdentityFile ~/.ssh/id_ed25519

3. Limit Agent Forwarding

# Only forward to specific hosts
Host bastion
    ForwardAgent yes

Host *
    ForwardAgent no

4. Enforce Key-Only Auth

Host bastion
    PreferredAuthentications publickey
    PasswordAuthentication no

5. Audit Logging

# /etc/ssh/sshd_config on bastion
LogLevel VERBOSE

Troubleshooting

Problem: Connection timeout

# Check bastion connectivity
ssh -v bastion

# Check internal server from bastion
ssh bastion
ssh internal-server

Problem: Permission denied

# Verify key is loaded
ssh-add -l

# Check key permissions
ls -l ~/.ssh/id_*
# Should be 600

Problem: Host key verification failed

# Remove old host key
ssh-keygen -R internal-server

# Reconnect and accept new key
ssh internal

FoxTerm Multi-Hop Support

FoxTerm makes multi-hop SSH visual and simple:

Visual Connection Chains

• See full connection path: you → bastion → server
• Color-coded hop indicators
• Latency per hop
• One-click reconnect

Bastion Management

• Define bastion hosts once
• Auto-apply to internal servers
• Certificate rotation reminders
• Access audit logs

Port Forwarding UI

• Visual port forward setup
• Active forwards dashboard
• Bandwidth monitoring
• Auto-reconnect on disconnect

Conclusion

Multi-hop SSH is essential for secure enterprise network access. ProxyJump provides a clean, declarative way to chain connections through bastion hosts.

FoxTerm makes multi-hop connections visual, with clear path indicators and one-click management.

FoxTerm Pro includes advanced multi-hop SSH management. Download at foxterm.app.

Podman Quadlets let you define containers as systemd unit files. This declarative approach brings auto-restart, dependency management, and resource controls to rootless containers.

What Are Quadlets?

Quadlets are systemd unit files that define Podman containers. Instead of running podman run manually, you create a .container file and let systemd manage the lifecycle.

Benefits:

• ✅ Automatic startup on boot
• ✅ Auto-restart on failure
• ✅ Dependency management
• ✅ Resource limits (CPU, memory)
• ✅ Logging via journald
• ✅ Integration with systemctl

Basic Quadlet Example

Step 1: Create Container File

# ~/.config/containers/systemd/nginx.container
[Unit]
Description=Nginx Web Server
After=network-online.target

[Container]
Image=docker.io/library/nginx:latest
Port=8080:80
Volume=./html:/usr/share/nginx/html:ro

[Service]
Restart=always
TimeoutStartSec=900

[Install]
WantedBy=default.target

Step 2: Generate Systemd Unit

# Reload systemd to detect new quadlet
systemctl --user daemon-reload

# Check generated unit
systemctl --user cat nginx.service

Step 3: Start Container

# Start container
systemctl --user start nginx.service

# Check status
systemctl --user status nginx.service

# Enable auto-start on boot
systemctl --user enable nginx.service

Quadlet File Structure

A quadlet file has four sections:

[Unit] Section

Standard systemd unit configuration:

[Unit]
Description=My Container
Documentation=https://example.com/docs
After=network-online.target postgresql.service
Wants=network-online.target
Requires=postgresql.service

Common directives:

• Description — Human-readable name
• After — Start after these units
• Wants — Weak dependency (start if available)
• Requires — Strong dependency (must be running)

[Container] Section

Podman-specific container configuration:

[Container]
Image=docker.io/library/nginx:latest
ContainerName=my-nginx
Port=8080:80
Volume=./data:/data:Z
Environment=NODE_ENV=production
EnvironmentFile=./env.list
Network=host
Pod=my-pod
AutoUpdate=registry

Common directives:

• Image — Container image (required)
• ContainerName — Name for the container
• Port — Port mapping (host:container)
• Volume — Volume mount (source:dest:options)
• Environment — Environment variables
• Network — Network mode or name
• Pod — Add container to pod
• AutoUpdate — Auto-update image from registry

[Service] Section

Standard systemd service configuration:

[Service]
Restart=always
RestartSec=10
TimeoutStartSec=900
ExecStartPre=/usr/bin/mkdir -p ./data
ExecStartPost=/usr/bin/curl -X POST http://localhost:8080/health

Common directives:

• Restart — When to restart (always, on-failure, no)
• RestartSec — Delay before restart
• TimeoutStartSec — Startup timeout
• ExecStartPre — Run before container starts
• ExecStartPost — Run after container starts

[Install] Section

Standard systemd install configuration:

[Install]
WantedBy=default.target

Advanced Examples

Multi-Service Stack

# postgres.container
[Unit]
Description=PostgreSQL Database
After=network-online.target

[Container]
Image=docker.io/library/postgres:16
ContainerName=postgres
Volume=pgdata:/var/lib/postgresql/data
Environment=POSTGRES_PASSWORD_FILE=/run/secrets/db_password
PublishPort=5432:5432

[Service]
Restart=always

[Install]
WantedBy=default.target

# api.container
[Unit]
Description=API Server
After=postgres.service
Requires=postgres.service

[Container]
Image=myapp/api:latest
ContainerName=api
Environment=DATABASE_URL=postgresql://postgres:5432/myapp
PublishPort=3000:3000

[Service]
Restart=always
RestartSec=10

[Install]
WantedBy=default.target

Resource Limits

# resource-limited.container
[Unit]
Description=Resource Limited Container

[Container]
Image=myapp/worker:latest
ContainerName=worker

[Service]
# CPU limit (100000 = 1 CPU)
CPUQuota=200000
# Memory limit
MemoryMax=512M
MemoryHigh=400M
# Restart policy
Restart=on-failure
RestartSec=30

[Install]
WantedBy=default.target

Pod with Multiple Containers

# mypod.pod
[Pod]
PodName=mypod
PublishPort=8080:80
PublishPort=8443:443

# web.container
[Unit]
Description=Web Server
After=mypod-pod.service

[Container]
Image=docker.io/library/nginx:latest
Pod=mypod.pod
Volume=./html:/usr/share/nginx/html:ro

[Service]
Restart=always

[Install]
WantedBy=default.target

# api.container
[Unit]
Description=API Server
After=mypod-pod.service

[Container]
Image=myapp/api:latest
Pod=mypod.pod
Environment=NODE_ENV=production

[Service]
Restart=always

[Install]
WantedBy=default.target

Managing Quadlets

View Status

# List all quadlet services
systemctl --user list-units '*.service' | grep container

# Check specific service
systemctl --user status nginx.service

# View logs
journalctl --user -u nginx.service -f

Control Services

# Start/stop/restart
systemctl --user start nginx.service
systemctl --user stop nginx.service
systemctl --user restart nginx.service

# Enable/disable auto-start
systemctl --user enable nginx.service
systemctl --user disable nginx.service

Update Images

# Pull new image
podman pull docker.io/library/nginx:latest

# Restart service to use new image
systemctl --user restart nginx.service

# Or use auto-update
podman auto-update

Quadlet vs Docker Compose

Migration from Docker Compose

Docker Compose File

version: '3.8'
services:
  web:
    image: nginx:latest
    ports:
      - "8080:80"
    volumes:
      - ./html:/usr/share/nginx/html:ro
    restart: always

Equivalent Quadlet

# web.container
[Unit]
Description=Nginx Web Server
After=network-online.target

[Container]
Image=docker.io/library/nginx:latest
Port=8080:80
Volume=./html:/usr/share/nginx/html:ro

[Service]
Restart=always

[Install]
WantedBy=default.target

FoxTerm Quadlet Support

FoxTerm makes Quadlet management visual and intuitive:

Visual Quadlet Editor

• Create quadlet files with syntax highlighting
• Validate configuration before deployment
• Preview generated systemd units
• One-click deploy

Service Dashboard

• View all quadlet services
• Real-time status and logs
• Resource usage monitoring
• One-click start/stop/restart

Template Library

• Pre-built quadlet templates for common services
• PostgreSQL, Redis, Nginx, Node.js, Python
• Customize and deploy in seconds

Integration

• Import Docker Compose files
• Auto-convert to quadlets
• Manage pods and networks
• Monitor all services in one place

Best Practices

1. Use descriptive names — nginx.container not web.container
2. Set restart policies — Restart=always for critical services
3. Define dependencies — Use After= and Requires= correctly
4. Limit resources — Set CPU and memory limits
5. Use volumes — Persist data outside containers
6. Monitor logs — Check journald regularly
7. Test locally — Validate quadlets before production
8. Version control — Store quadlet files in git

Conclusion

Podman Quadlets bring the power of systemd to container management. Declarative configuration, automatic lifecycle management, and deep OS integration make Quadlets ideal for production workloads.

FoxTerm makes Quadlets accessible with visual editing, templates, and monitoring.

FoxTerm Pro includes Podman Quadlet management. Download at foxterm.app.

For years, Docker was synonymous with containers. But today, there’s a serious alternative: Podman. Both run OCI-compatible containers, both support Docker Compose files, and both are managed through FoxTerm. So which should you use?

This guide compares Podman and Docker across architecture, security, compatibility, and operational considerations to help you choose.

Architecture: Daemon vs Daemonless

Docker: Client-Daemon Model

Docker uses a client-daemon architecture:

docker CLI → Docker Daemon (dockerd) → Containers

The daemon (dockerd) runs as root and manages all container operations. The CLI sends commands to the daemon via a Unix socket (/var/run/docker.sock).

Implications:

• Daemon is a single point of failure
• All containers run under the daemon’s root privileges
• API access requires root or docker group membership
• Daemon restart affects all containers

Podman: Fork-Exec Model

Podman runs containers directly without a central daemon:

podman CLI → conmon (per-container monitor) → Containers

Each podman command spawns a new process that directly interacts with the container runtime (crun or runc).

Implications:

• No single point of failure
• Each container has its own monitor process
• Can run without root (rootless mode)
• No persistent background service

Security: Root vs Rootless

Docker Root Mode (Default)

Docker daemon runs as root, and containers inherit this:

$ docker run -it ubuntu whoami
root

Security concerns:

• Container breakout could give attacker root on host
• Docker socket access = full root access
• Requires careful configuration to restrict privileges

Docker Rootless Mode

Docker can run rootless, but requires setup:

$ dockerd-rootless-setuptool.sh install
$ DOCKER_HOST=unix:///run/user/1000/docker.sock docker run ubuntu whoami
user

Limitations:

• Some features don’t work (port binding < 1024, certain volumes)
• More complex setup
• Not all distributions support it well

Podman Rootless (Default)

Podman is designed for rootless operation from day one:

$ podman run -it ubuntu whoami
root
$ podman unshare whoami
user

Inside the container, processes appear as root, but on the host they run as your user ID (via user namespaces).

Advantages:

• No privilege escalation needed
• Container breakout limited to user permissions
• No special setup required
• Works out of the box on most distros

Compatibility: Drop-In Replacement?

Podman aims for CLI compatibility with Docker:

alias docker=podman

In practice, it works about 95% of the time.

Compatible Features

• Basic container operations (run, stop, rm, exec)
• Image management (pull, push, build)
• Volume mounting (-v)
• Port mapping (-p)
• Environment variables (-e)
• Docker Compose files (via podman-compose or podman play kube)

Incompatible Features

Docker-specific:

• Docker Swarm (Podman uses Kubernetes instead)
• BuildKit advanced features (some DOCKER_BUILDKIT syntax)
• Docker plugins (network, volume plugins)
• Some docker inspect output fields

Workarounds:

• Use podman-docker package (provides /usr/bin/docker symlink)
• Install podman-compose for Compose support
• Use Podman’s Kubernetes YAML generation instead of Swarm

Performance: Head-to-Head

Startup Time

Podman: Faster for individual containers (no daemon overhead)

$ time podman run --rm hello-world
real    0m1.2s

Docker: Slightly slower (daemon communication)

$ time docker run --rm hello-world
real    0m1.8s

Difference is negligible for long-running containers but noticeable for short-lived tasks.

Resource Usage

Docker: Daemon consumes ~50-100 MB RAM continuously Podman: No persistent daemon, only per-container overhead (~10-20 MB per container for conmon)

For servers running many containers, Podman uses less baseline memory.

Image Storage

Both use similar storage drivers (overlay2 by default). Performance is comparable.

Ecosystem and Tooling

Docker Advantages

Docker Hub: Largest container registry with official images Docker Desktop: Polished GUI for Mac/Windows Docker Compose: Mature orchestration tool Enterprise support: Docker Inc offers commercial support Documentation: Extensive tutorials and community knowledge

Podman Advantages

Podman Desktop: Growing GUI alternative (still maturing) Quadlet: Systemd integration for auto-starting containers Auto-update: Built-in container auto-update via systemd timers Kubernetes native: Generate K8s YAML from running pods Red Hat backing: Enterprise support via Red Hat

FoxTerm Support

FoxTerm manages both Docker and Podman seamlessly.

Auto-Detection

When you connect to a server via SSH, FoxTerm checks:

which docker && docker info
which podman && podman info

If either is found, FoxTerm enables the container management UI.

Unified Interface

Whether the server runs Docker or Podman, FoxTerm presents the same interface:

• Container list with status, resources, ports
• Start/stop/restart/kill operations
• Log viewing
• Stats monitoring
• Image management
• Compose stack deployment

FoxTerm translates commands appropriately:

FoxTerm UI → Detects runtime → Executes docker/podman command

Mixed Environments

Some servers run Docker, others run Podman. FoxTerm handles this transparently. You manage containers the same way regardless of the underlying runtime.

Migration: Docker to Podman

Considering switching? Here’s how:

Step 1: Install Podman

# Ubuntu/Debian
sudo apt install podman podman-compose

# CentOS/RHEL
sudo dnf install podman podman-compose

# macOS
brew install podman
podman machine init
podman machine start

Step 2: Test Compatibility

# Try running your containers with podman
podman run -d --name myapp -p 8080:80 myimage

# Check if everything works
podman logs myapp
podman exec -it myapp bash

Step 3: Migrate Compose Files

Most Compose files work unchanged:

podman-compose up -d

If you encounter issues, use podman generate kube to convert to Kubernetes YAML:

podman generate kube myapp > myapp.yaml
podman play kube myapp.yaml

Step 4: Update CI/CD

Replace docker commands with podman in your pipelines:

# Before
- docker build -t myapp .
- docker push myapp

# After
- podman build -t myapp .
- podman push myapp

Step 5: Remove Docker

Once confident:

sudo systemctl stop docker
sudo systemctl disable docker
sudo apt remove docker-ce docker-ce-cli

When to Choose Docker

Choose Docker if:

• You need Docker Swarm orchestration
• Your team is already familiar with Docker
• You rely on Docker-specific plugins or extensions
• You need Docker Desktop on Mac/Windows
• You want maximum compatibility with third-party tools
• Enterprise support from Docker Inc is important

When to Choose Podman

Choose Podman if:

• Security is a top priority (rootless by default)
• You’re on Red Hat/CentOS/Fedora (native integration)
• You want systemd integration (Quadlet, auto-update)
• You’re moving toward Kubernetes (Podman generates K8s YAML)
• You prefer no daemon architecture (simplicity, reliability)
• You’re building minimal servers (less overhead)

Hybrid Approach

You don’t have to choose exclusively. Many teams use both:

• Development: Docker Desktop for convenience
• Production: Podman for security and systemd integration
• CI/CD: Podman for faster builds and lower resource usage

FoxTerm supports both, so you can manage mixed environments through a single interface.

Conclusion

Docker and Podman are both mature container runtimes. Docker has the ecosystem advantage; Podman has the security and simplicity advantage. For new projects, especially on Linux servers, Podman is increasingly the default choice. For existing Docker deployments, there’s no urgent need to switch — but Podman compatibility means migration is straightforward if you decide to later.

FoxTerm manages both runtimes equally well, so you can focus on your containers, not the tooling.

FoxTerm Pro supports both Docker and Podman. Download at foxterm.app.

When managing remote servers, visibility is everything. You need to know: Is the CPU maxed out? Is memory pressure causing swaps? Is the GPU being utilized? Is network bandwidth saturated?

Traditionally, this means running multiple commands (top, htop, nvidia-smi, iftop) in separate terminal windows, parsing text output, and mentally aggregating the data.

FoxTerm automates this by providing real-time system telemetry with visual charts — all over a single SSH connection.

CPU Monitoring

See per-core CPU utilization with detailed breakdown:

• User — Time spent in user-space processes
• System — Time spent in kernel-space
• Idle — Unused CPU capacity
• IOWait — Time waiting for I/O operations
• IRQ/SoftIRQ — Interrupt handling
• Steal — Time stolen by hypervisor (VMs)
• Guest — Time running virtual machines

Charts update every second, showing trends over time. Spot spikes instantly.

Memory Monitoring

Full virtual memory statistics:

• Total — Physical RAM capacity
• Available — Memory available for new processes
• Used — Currently allocated memory
• Buffers/Cached — Kernel cache (reclaimable)
• Swap — Swap space usage
• Huge Pages — Large page allocation (if enabled)

Identify memory leaks before they cause OOM kills.

GPU Monitoring

This is where FoxTerm stands out. Most monitoring tools ignore GPUs entirely. FoxTerm supports:

NVIDIA (nvidia-smi)

• GPU utilization (%)
• Memory used/free
• Temperature
• Power draw
• Process list (which processes are using the GPU)

AMD (amd-smi)

• GPU usage
• VRAM allocation
• Fan speed
• Temperature

Intel

• Integrated GPU utilization
• Memory bandwidth

Monitor GPU-intensive workloads (ML training, video encoding, rendering) without SSH-ing in to run nvidia-smi manually.

Disk I/O

Per-mount-point statistics:

• Read/write throughput (MB/s)
• IOPS (operations per second)
• Latency (average response time)
• Queue depth

Identify disk bottlenecks before they impact application performance.

Network Monitoring

Per-interface bandwidth tracking:

• RX/TX bytes per second
• Packet counts
• Error rates
• MTU size

Spot network saturation or packet loss issues in real-time.

Temperature Monitoring

Dual-channel sensor reading:

• hwmon — Hardware monitoring sensors (CPU, motherboard)
• thermal_zone — ACPI thermal zones

Automatic CPU sensor detection ensures accurate temperature readings regardless of hardware configuration.

System Stats

High-level system health:

• Load average — 1, 5, and 15-minute averages
• Context switches — Per-second rate
• Boot time — System uptime
• Process count — Running, sleeping, zombie processes

How It Works

FoxTerm fetches this data by executing lightweight commands over SSH:

• /proc/stat — CPU statistics
• /proc/meminfo — Memory information
• /proc/net/dev — Network interfaces
• nvidia-smi --query-gpu=... — GPU metrics
• cat /sys/class/hwmon/... — Temperature sensors

Commands are optimized for minimal overhead. Data is parsed and rendered in FoxTerm’s custom ChartUI module.

Why This Matters

Proactive Monitoring: Catch issues before they become outages. See CPU trending upward? Investigate before it hits 100%.

Resource Planning: Understand actual usage patterns to right-size instances. Are you paying for 8 cores but only using 2?

Debugging: Correlate application behavior with system metrics. Did that memory spike coincide with the crash?

Multi-Server Oversight: Monitor multiple servers simultaneously through separate FoxTerm windows. Compare performance at a glance.

The Bottom Line

FoxTerm transforms server monitoring from a CLI chore into a visual dashboard. No more memorizing command flags or parsing text output — just clear, real-time charts that tell you exactly what’s happening on your servers.

Download FoxTerm at foxterm.app.

In cybersecurity, we talk a lot about encryption, firewalls, and access controls. But the most critical asset in any developer’s toolkit is often overlooked: the SSH private key.

This single file grants access to every server you manage. If it’s compromised, your entire infrastructure is at risk. Yet most SSH clients store it as a plain file on disk, protected only by file system permissions.

FoxTerm takes a fundamentally different approach.

What Is the Secure Enclave?

The Secure Enclave is a hardware security module built into every Apple Silicon Mac and iPhone. It’s a separate processor with its own:

• Secure boot chain — Independent from the main OS
• Encrypted memory — Not accessible to macOS or apps
• Cryptographic engine — Performs operations without exposing keys
• Biometric interface — Requires Face ID or Touch ID for access

Think of it as a vault inside your device. Even if someone gains root access to your Mac, they cannot read what’s inside the Secure Enclave.

How FoxTerm Uses It

When you generate or import an SSH key in FoxTerm, you have the option to store it in the Secure Enclave. Here’s what happens:

Key Generation

The private key is generated inside the Secure Enclave. It never exists in RAM, on disk, or in any form that FoxTerm (or any other process) can read.

Key Usage

When you authenticate to a server, FoxTerm sends a signing request to the Secure Enclave. The enclave signs the challenge and returns the signature — but never reveals the private key itself.

Biometric Gating

Access to Secure Enclave-stored keys requires biometric verification. Even if someone steals your unlocked MacBook, they cannot use your SSH keys without your face or fingerprint.

The Threat Model

Consider what happens with traditional file-based keys:

Zero Telemetry

Security isn’t just about encryption — it’s about trust. FoxTerm collects zero telemetry:

• No analytics SDKs
• No crash reporting without explicit consent
• No usage tracking
• No “phone home” behavior

You can verify this by auditing the codebase. There are no hidden network calls, no third-party tracking libraries, and no data collection of any kind.

App Sandbox

FoxTerm runs in macOS App Sandbox, which limits file system access to only what’s explicitly needed. Even if a vulnerability were discovered, the sandbox contains the damage.

Best Practices

To maximize security:

1. Store keys in Secure Enclave — Use biometric-gated keys for sensitive servers
2. Use strong passphrases — Add an extra layer for non-Secure Enclave keys
3. Rotate keys regularly — Limit the blast radius of potential compromise
4. Audit authorized_keys — Remove unused keys from servers

The Bottom Line

Your SSH keys are the master keys to your infrastructure. They deserve hardware-level protection, not just file system permissions. FoxTerm provides that protection out of the box.

Download FoxTerm at foxterm.app.

Basic SFTP is simple: upload files, download files, done. But professional workflows demand more. You need to edit remote files without downloading them first. Sync directories bidirectionally. Automate repetitive transfers. Monitor transfer progress in real-time.

FoxTerm’s SFTP implementation goes far beyond basic file transfer. This guide covers advanced workflows that transform how you work with remote files.

Remote File Editing: Edit Without Downloading

Traditional workflow for editing a remote config file:

1. scp user@server:/etc/nginx/nginx.conf .
2. Edit locally
3. scp nginx.conf user@server:/etc/nginx/
4. Repeat until satisfied

This is slow and error-prone. FoxTerm offers remote file editing: double-click any file, edit it in-place, and save directly to the server.

How It Works

1. Open: Double-click a remote file in FoxTerm’s SFTP browser
2. Download: FoxTerm downloads the file to a temporary location
3. Edit: Opens in your preferred editor (VS Code, Sublime, Vim, etc.)
4. Monitor: FoxTerm watches for file changes
5. Upload: When you save, FoxTerm automatically uploads the modified file back to the server

All of this happens seamlessly. You edit as if the file were local.

Configuring Your Editor

FoxTerm integrates with any editor that supports command-line invocation.

VS Code

# In FoxTerm Settings → SFTP → External Editor
code --wait $FILE

The --wait flag ensures FoxTerm knows when you’ve finished editing.

Sublime Text

subl -w $FILE

Vim/Terminal Editors

vim $FILE

Custom Scripts

You can use wrapper scripts for preprocessing:

#!/bin/bash
# Backup before editing
cp "$1" "$1.bak"
# Open in editor
code --wait "$1"
# Validate after editing (for config files)
nginx -t && echo "Config valid" || echo "Config error!"

Conflict Detection

What if the remote file changes while you’re editing?

FoxTerm detects this by comparing file timestamps:

1. Before uploading, FoxTerm checks if the remote file has been modified since download
2. If yes, FoxTerm warns you: “Remote file has changed. Overwrite or re-download?”
3. You choose: overwrite (your version wins), re-download (server version wins), or merge manually

This prevents accidental overwrites in collaborative environments.

Supported File Types

FoxTerm’s built-in viewer supports syntax highlighting for:

• Config files: .conf, .cfg, .ini, .yaml, .yml, .json, .toml
• Scripts: .sh, .py, .rb, .pl, .js, .ts
• Web: .html, .css, .php
• Logs: .log, .txt
• Markdown: .md

For binary files or unsupported types, FoxTerm prompts you to download instead.

Directory Synchronization

Need to sync an entire project directory between local and remote? FoxTerm offers three sync modes.

One-Way Sync (Local → Remote)

Upload all changed files from local to remote:

1. Select local directory
2. Right-click → “Sync to Remote”
3. FoxTerm compares file sizes and timestamps
4. Only uploads files that differ
5. Shows progress bar with transfer speed

Use case: Deploying website updates

One-Way Sync (Remote → Local)

Download all changed files from remote to local:

1. Select remote directory
2. Right-click → “Sync to Local”
3. FoxTerm downloads only modified files
4. Preserves directory structure

Use case: Backing up server configs

Bidirectional Sync

Keeps both directories in sync:

1. Select both local and remote directories
2. Right-click → “Bidirectional Sync”
3. FoxTerm compares both sides
4. Uploads newer local files, downloads newer remote files
5. Prompts on conflicts (both sides modified)

Use case: Working on a project from multiple machines

Smart Comparison

FoxTerm doesn’t just compare timestamps. It uses a multi-layer comparison:

1. File size: Different sizes = definitely different
2. Modification time: Same size + same mtime = likely identical
3. Checksum (optional): For critical files, compute MD5/SHA256 to be sure

Enable checksum verification in Settings → SFTP → Sync → “Verify with checksum”.

Automated Transfers

Repetitive file transfers? Automate them.

Watched Folders

Configure FoxTerm to monitor a local folder and auto-upload changes:

1. Settings → SFTP → Watched Folders → Add
2. Select local folder (e.g., ~/projects/website/dist)
3. Set remote destination (e.g., /var/www/html)
4. Choose trigger: “On file change” or “On save”
5. Optional: Set debounce delay (e.g., 2 seconds after last change)

Now every time you rebuild your website, FoxTerm automatically uploads the new files.

Scheduled Transfers

Run transfers on a schedule:

1. Settings → SFTP → Scheduled Transfers → Add
2. Define source and destination
3. Set schedule: hourly, daily, weekly, or custom cron expression
4. Choose sync mode: one-way or bidirectional

Example: Daily backup of /etc to local machine at 2 AM.

Transfer Rules

Apply rules to filter what gets transferred:

• Include patterns: *.js, *.css, dist/**
• Exclude patterns: node_modules/**, *.tmp, .git/**
• Size limits: Skip files larger than 100 MB
• Type filters: Only transfer files (skip directories) or vice versa

Rules are saved per connection, so they persist across sessions.

Transfer Resumption

Large file transfers interrupted by network issues? FoxTerm supports resumption.

How It Works

1. You start uploading a 2 GB database dump
2. At 80%, your WiFi drops
3. When you reconnect, FoxTerm detects the partial upload
4. Click “Resume” to continue from 80% instead of restarting

This uses the SFTP append operation to continue writing from the last successful byte.

Limitations

• Server must support the append extension (most modern SFTP servers do)
• File must not have been modified on the server during interruption
• Resume works for both uploads and downloads

Enable in Settings → SFTP → “Allow transfer resumption” (default: enabled).

Parallel Transfers

Uploading hundreds of small files sequentially is slow. FoxTerm uses parallel transfers to maximize throughput.

Configuration

Settings → SFTP → Performance:

• Max parallel transfers: 1-10 (default: 4)
• Buffer size: 32 KB - 1 MB (default: 128 KB)
• Pipeline depth: 1-16 (default: 8)

Tuning Guidelines

High-latency networks (>100ms):

• Increase parallel transfers to 6-8
• Increase buffer size to 256 KB
• Increase pipeline depth to 12-16

Low-bandwidth networks (<5 Mbps):

• Reduce parallel transfers to 2-3
• Keep buffer size at 128 KB

LAN connections:

• Max out parallel transfers (10)
• Large buffer size (512 KB - 1 MB)

FoxTerm auto-tunes these settings based on detected network conditions, but you can override manually.

File Permissions and Ownership

SFTP preserves Unix file permissions and ownership during transfers.

Permission Preservation

When uploading files:

1. FoxTerm reads local file permissions (e.g., 755 for scripts)
2. After upload, sets remote permissions to match
3. Executable bit is preserved automatically

Override in Settings → SFTP → “Preserve permissions” (default: enabled).

Setting Custom Permissions

Right-click any remote file or directory → “Change Permissions”:

• Visual permission editor (checkboxes for r/w/x)
• Octal input (e.g., type 644)
• Symbolic input (e.g., type u+rwx,g+rx,o+rx)
• Apply recursively to subdirectories

Ownership Changes

If you have sudo access on the server, you can change file ownership:

1. Right-click → “Change Owner”
2. Enter new owner (user:group)
3. FoxTerm executes chown via SSH

Note: Requires password or key-based sudo authentication.

Integration with Terminal

FoxTerm’s SFTP and terminal are integrated, not separate.

Open Terminal at Current Directory

In SFTP browser, right-click any directory → “Open Terminal Here”:

• Opens a new terminal tab
• Automatically cds to the selected directory
• Same SSH connection, no re-authentication

Drag and Drop to Terminal

Drag a file from SFTP browser into terminal:

• FoxTerm inserts the file’s full path
• Useful for commands like cat, less, grep, tail

Example: Drag access.log into terminal, type tail -f before it, and you’re tailing logs instantly.

Copy File Path

Right-click any file → “Copy Path”:

• Copies absolute path to clipboard
• Paste into terminal, editor, or other apps

Security Considerations

SFTP runs over SSH, so it inherits SSH’s security. But there are additional considerations.

Chroot Jails

Restrict SFTP users to their home directory:

# /etc/ssh/sshd_config
Match Group sftpusers
    ChrootDirectory %h
    ForceCommand internal-sftp
    AllowTcpForwarding no

Users in the sftpusers group can only access their home directory via SFTP, not SSH shell.

Read-Only Access

Grant read-only SFTP access:

# /etc/ssh/sshd_config
Match User readonly_user
    ForceCommand internal-sftp -R

The -R flag makes the SFTP session read-only. Users can download but not upload or modify.

Audit Logging

Log all SFTP operations:

# /etc/ssh/sshd_config
Subsystem sftp /usr/lib/openssh/sftp-server -l INFO -f AUTH

Logs appear in /var/log/auth.log:

Oct 20 14:32:15 server sftp-server[12345]: session opened for local user alice from [192.168.1.100]
Oct 20 14:32:20 server sftp-server[12345]: open "/var/www/index.html" flags WRITE,CREATE,TRUNCATE mode 0644
Oct 20 14:32:25 server sftp-server[12345]: close "/var/www/index.html" bytes read 0 written 4096

FoxTerm displays recent SFTP activity in the connection info panel (Cmd+I).

Advanced Use Cases

Database Backup Automation

Automate daily database backups:

1. Create a script on the server:

#!/bin/bash
# /usr/local/bin/db-backup.sh
DATE=$(date +%Y%m%d)
mysqldump mydb | gzip > /backups/mydb-$DATE.sql.gz
# Keep only last 7 days
find /backups -name "mydb-*.sql.gz" -mtime +7 -delete

2. Configure FoxTerm watched folder:

• Local: ~/backups/db
• Remote: /backups
• Schedule: Daily at 2 AM
• Action: Download new files

Result: Daily database backups automatically downloaded to your local machine.

Website Deployment Pipeline

Deploy static sites with a single click:

1. Build locally: npm run build
2. FoxTerm’s watched folder detects changes in dist/
3. Auto-uploads to /var/www/html on server
4. FoxTerm executes post-deploy script via SSH:

#!/bin/bash
# /usr/local/bin/deploy-hook.sh
systemctl reload nginx
echo "Deployment complete at $(date)"

Log Aggregation

Collect logs from multiple servers:

1. Configure FoxTerm scheduled transfers for each server:

   • Source: /var/log/app/*.log
   • Destination: ~/logs/server-{hostname}/
   • Schedule: Every hour
   • Mode: One-way (remote → local)

2. Use local tools (grep, awk, ELK stack) to analyze aggregated logs.

Troubleshooting

Slow Transfers

Symptom: Transfer speed much lower than network capacity.

Fixes:

• Increase parallel transfers (Settings → SFTP → Performance)
• Enable compression (Settings → SFTP → “Enable compression”)
• Check for disk I/O bottleneck on server (iostat, iotop)

Permission Denied

Symptom: Can’t upload to certain directories.

Fixes:

• Verify remote directory permissions (ls -la)
• Check if you own the directory or are in the correct group
• Use sudo via SSH to change ownership if needed

Connection Drops During Large Transfers

Symptom: SFTP disconnects during multi-GB transfers.

Fixes:

• Enable SSH keepalive (Settings → SSH → “Send keepalive every 30s”)
• Reduce parallel transfers to avoid overwhelming the connection
• Use screen or tmux on server to persist sessions

Conclusion

SFTP is more than just file transfer. With remote editing, directory sync, automation, and intelligent optimizations, FoxTerm transforms SFTP into a powerful workflow tool. Whether you’re deploying websites, managing configs, or backing up data, these advanced techniques save time and reduce errors.

FoxTerm Pro includes advanced SFTP features. Download at foxterm.app.

SFTP (SSH File Transfer Protocol) is secure and reliable, but manual file transfers are tedious. Automation lets you batch uploads, schedule syncs, and integrate file transfers into deployment pipelines.

Why Automate SFTP?

Manual SFTP is slow:

• Drag-and-drop one file at a time
• Remember remote paths
• Repeat same operations daily
• Error-prone for bulk operations

Automated SFTP is fast:

• Transfer hundreds of files in one command
• Schedule recurring transfers
• Integrate with CI/CD pipelines
• Consistent and repeatable

Shell Script Automation

Basic Upload Script

#!/bin/bash
# upload.sh - Upload files to remote server

HOST="server.example.com"
USER="deploy"
REMOTE_DIR="/var/www/html"
LOCAL_DIR="./dist"

# Upload all files in dist/
sftp $USER@$HOST <<EOF
cd $REMOTE_DIR
put $LOCAL_DIR/*
bye
EOF

echo "Upload complete"

Batch Upload with Progress

#!/bin/bash
# batch-upload.sh - Upload with progress tracking

HOST="server.example.com"
USER="deploy"
REMOTE_DIR="/uploads"

# Create batch file
cat > /tmp/sftp-batch.txt <<EOF
cd $REMOTE_DIR
put file1.txt
put file2.txt
put file3.txt
bye
EOF

# Execute batch
sftp -b /tmp/sftp-batch.txt $USER@$HOST

# Cleanup
rm /tmp/sftp-batch.txt

Download with Pattern Matching

#!/bin/bash
# download-logs.sh - Download log files

HOST="server.example.com"
USER="admin"
REMOTE_DIR="/var/log"
LOCAL_DIR="./logs"

mkdir -p $LOCAL_DIR

sftp $USER@$HOST <<EOF
cd $REMOTE_DIR
mget *.log $LOCAL_DIR/
bye
EOF

echo "Downloaded $(ls $LOCAL_DIR/*.log | wc -l) log files"

Sync Directory (rsync-like)

#!/bin/bash
# sync.sh - Sync local to remote

HOST="server.example.com"
USER="deploy"
REMOTE_DIR="/app"
LOCAL_DIR="./build"

# Get remote file list
sftp $USER@$HOST <<EOF > /tmp/remote-files.txt
cd $REMOTE_DIR
ls -1
bye
EOF

# Upload only new/changed files
for file in $LOCAL_DIR/*; do
    filename=$(basename $file)
    if ! grep -q "$filename" /tmp/remote-files.txt; then
        echo "Uploading $filename"
        sftp $USER@$HOST <<EOF
cd $REMOTE_DIR
put $file
bye
EOF
    fi
done

rm /tmp/remote-files.txt

Error Handling

#!/bin/bash
# safe-upload.sh - Upload with error handling

HOST="server.example.com"
USER="deploy"
REMOTE_DIR="/uploads"
LOCAL_FILE="data.csv"

# Test connection first
if ! ssh -o ConnectTimeout=5 -o BatchMode=yes $USER@$HOST exit 2>/dev/null; then
    echo "Error: Cannot connect to $HOST"
    exit 1
fi

# Upload with error check
sftp $USER@$HOST <<EOF
cd $REMOTE_DIR
put $LOCAL_FILE
bye
EOF

if [ $? -eq 0 ]; then
    echo "Upload successful"
else
    echo "Upload failed"
    exit 1
fi

Python Automation

Basic Upload with paramiko

#!/usr/bin/env python3
# upload.py - Upload files using paramiko

import paramiko
import os

HOST = 'server.example.com'
USER = 'deploy'
REMOTE_DIR = '/uploads'
LOCAL_DIR = './dist'

# Connect
ssh = paramiko.SSHClient()
ssh.set_missing_host_key_policy(paramiko.AutoAddPolicy())
ssh.connect(HOST, username=USER, key_filename='~/.ssh/id_ed25519')

# Open SFTP
sftp = ssh.open_sftp()
sftp.chdir(REMOTE_DIR)

# Upload files
for filename in os.listdir(LOCAL_DIR):
    local_path = os.path.join(LOCAL_DIR, filename)
    if os.path.isfile(local_path):
        print(f'Uploading {filename}')
        sftp.put(local_path, filename)

# Cleanup
sftp.close()
ssh.close()
print('Upload complete')

Download with Progress

#!/usr/bin/env python3
# download.py - Download with progress callback

import paramiko

def progress(transferred, total):
    percent = (transferred / total) * 100
    print(f'\rDownloading: {percent:.1f}%', end='')

HOST = 'server.example.com'
USER = 'admin'
REMOTE_FILE = '/data/large-dataset.zip'
LOCAL_FILE = './large-dataset.zip'

ssh = paramiko.SSHClient()
ssh.set_missing_host_key_policy(paramiko.AutoAddPolicy())
ssh.connect(HOST, username=USER)

sftp = ssh.open_sftp()
sftp.get(REMOTE_FILE, LOCAL_FILE, callback=progress)

print('\nDownload complete')
sftp.close()
ssh.close()

Directory Sync

#!/usr/bin/env python3
# sync.py - Sync directories

import paramiko
import os
import hashlib

def file_hash(filepath):
    """Calculate MD5 hash of file"""
    hash_md5 = hashlib.md5()
    with open(filepath, "rb") as f:
        for chunk in iter(lambda: f.read(4096), b""):
            hash_md5.update(chunk)
    return hash_md5.hexdigest()

def sync_directories(ssh, local_dir, remote_dir):
    sftp = ssh.open_sftp()
    
    # Get remote files
    remote_files = {}
    for filename in sftp.listdir(remote_dir):
        remote_path = os.path.join(remote_dir, filename)
        try:
            stat = sftp.stat(remote_path)
            if stat.st_size >= 0:  # Is file
                remote_files[filename] = stat.st_size
        except:
            pass
    
    # Upload new/changed files
    for filename in os.listdir(local_dir):
        local_path = os.path.join(local_dir, filename)
        if os.path.isfile(local_path):
            local_size = os.path.getsize(local_path)
            
            if filename not in remote_files or remote_files[filename] != local_size:
                remote_path = os.path.join(remote_dir, filename)
                print(f'Uploading {filename}')
                sftp.put(local_path, remote_path)
    
    sftp.close()

# Usage
ssh = paramiko.SSHClient()
ssh.set_missing_host_key_policy(paramiko.AutoAddPolicy())
ssh.connect('server.example.com', username='deploy')

sync_directories(ssh, './build', '/app')
ssh.close()

Batch Operations

#!/usr/bin/env python3
# batch-operations.py - Multiple SFTP operations

import paramiko

ssh = paramiko.SSHClient()
ssh.set_missing_host_key_policy(paramiko.AutoAddPolicy())
ssh.connect('server.example.com', username='deploy')
sftp = ssh.open_sftp()

# Create directory
try:
    sftp.mkdir('/uploads/2026')
    print('Created directory /uploads/2026')
except IOError:
    print('Directory already exists')

# Upload multiple files
files = ['report.pdf', 'data.csv', 'image.png']
for filename in files:
    sftp.put(f'./{filename}', f'/uploads/2026/{filename}')
    print(f'Uploaded {filename}')

# List files
print('\nFiles in /uploads/2026:')
for filename in sftp.listdir('/uploads/2026'):
    stat = sftp.stat(f'/uploads/2026/{filename}')
    print(f'  {filename}: {stat.st_size} bytes')

# Delete old files
old_files = ['report-old.pdf', 'data-backup.csv']
for filename in old_files:
    try:
        sftp.remove(f'/uploads/2026/{filename}')
        print(f'Deleted {filename}')
    except IOError:
        pass

sftp.close()
ssh.close()

Scheduled Transfers

Cron Job (Linux/macOS)

# Edit crontab
crontab -e

# Upload files every day at 2 AM
0 2 * * * /path/to/upload.sh >> /var/log/sftp-upload.log 2>&1

# Sync every hour
0 * * * * /path/to/sync.sh >> /var/log/sftp-sync.log 2>&1

Launchd (macOS)

<!-- ~/Library/LaunchAgents/com.foxterm.sftp-upload.plist -->
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>com.foxterm.sftp-upload</string>
    <key>ProgramArguments</key>
    <array>
        <string>/path/to/upload.sh</string>
    </array>
    <key>StartInterval</key>
    <integer>3600</integer>
    <key>StandardOutPath</key>
    <string>/tmp/sftp-upload.log</string>
    <key>StandardErrorPath</key>
    <string>/tmp/sftp-upload-error.log</string>
</dict>
</plist>

Load with:

launchctl load ~/Library/LaunchAgents/com.foxterm.sftp-upload.plist

CI/CD Integration

GitHub Actions

# .github/workflows/deploy.yml
name: Deploy to Server

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      
      - name: Build
        run: npm run build
      
      - name: Upload via SFTP
        uses: appleboy/scp-action@master
        with:
          host: ${{ secrets.SERVER_HOST }}
          username: ${{ secrets.SERVER_USER }}
          key: ${{ secrets.SSH_KEY }}
          source: "./dist/*"
          target: "/var/www/html"

GitLab CI

# .gitlab-ci.yml
deploy:
  stage: deploy
  image: alpine:latest
  before_script:
    - apk add --no-cache openssh-client
  script:
    - mkdir -p ~/.ssh
    - echo "$SSH_PRIVATE_KEY" > ~/.ssh/id_ed25519
    - chmod 600 ~/.ssh/id_ed25519
    - ssh-keyscan $SERVER_HOST >> ~/.ssh/known_hosts
    - sftp -b batch.txt $SERVER_USER@$SERVER_HOST
  only:
    - main

FoxTerm SFTP Automation

FoxTerm makes SFTP automation visual and intuitive:

Visual Batch Operations

• Select multiple files with Shift/Cmd-click
• Drag-and-drop to upload/download
• Progress bars for all transfers
• Pause/resume support

Saved Connections

• Store server credentials securely
• One-click connect
• Recent files list
• Quick access to favorite directories

Transfer Queue

• Queue multiple transfers
• Priority ordering
• Bandwidth throttling
• Automatic retry on failure

Integration

• Open remote files in local editors
• Sync local and remote directories
• Watch folders for automatic upload
• Webhook notifications on completion

Best Practices

1. Use SSH keys — Never hardcode passwords in scripts
2. Test connections — Verify connectivity before transfers
3. Handle errors — Check return codes and log failures
4. Limit bandwidth — Don’t saturate network during business hours
5. Validate transfers — Check file sizes or checksums after upload
6. Secure credentials — Use environment variables or secret managers
7. Monitor transfers — Log all operations for auditing

Conclusion

SFTP automation transforms tedious manual transfers into reliable, repeatable workflows. Whether you use shell scripts for simple tasks or Python for complex logic, automation saves time and reduces errors.

FoxTerm complements scripted automation with a visual interface for ad-hoc transfers and monitoring.

FoxTerm Pro includes advanced SFTP automation features. Download at foxterm.app.

The traditional workflow for managing remote files is frustrating:

1. SSH into the server to edit a config file
2. Exit SSH
3. Open an SFTP client (or use scp)
4. Upload/download files
5. SSH back in to verify changes

This context switching wastes time and breaks your flow. FoxTerm solves this by integrating a full SFTP file manager directly into the SSH session.

Visual File Browser

Once connected via SSH, switch to the SFTP view to see remote files in a familiar list or table layout:

• File icons indicate type (directory, file, symlink)
• Permissions displayed in Unix format (rwxr-xr-x)
• Size and modification date for quick reference
• Search to find files in large directories

Navigate with keyboard arrows or mouse clicks — just like Finder.

Drag-and-Drop Upload

Transfer files from your Mac to the server by dragging them into the FoxTerm window. Progress bars show upload status, and you can cancel mid-transfer if needed.

Download works the same way: drag files from the SFTP browser to your desktop or any Finder window.

Remote File Editing

Edit remote files without downloading them first. FoxTerm includes a built-in code editor with:

Syntax Highlighting

Support for YAML, JSON, XML, INI, TOML, Bash, Dockerfile, Markdown, and SSH config files. Colors adapt to your light/dark theme preference.

Tree-sitter Parsing

Accurate syntax highlighting powered by Tree-sitter grammars — not regex-based approximations.

Auto-Save

Changes are saved directly to the remote file via SFTP. No manual upload step required.

Conflict Detection

If the remote file was modified externally, FoxTerm warns you before overwriting.

File Operations

Right-click any file or folder for a context menu:

• Rename — Change filename in place
• Delete — Remove with confirmation
• Copy/Paste — Duplicate files or move between directories
• New Folder — Create directories
• Symlink — Create symbolic links
• Compress — Zip files/folders on the server
• Decompress — Extract zip/tar archives remotely
• Permissions — Edit Unix permissions (chmod)
• Owner/Group — Change file ownership (chown/chgrp)

StatVFS Integration

See remote disk usage at a glance. FoxTerm queries the server’s filesystem statistics and displays:

• Total capacity
• Used space
• Available space
• Usage percentage

No need to run df -h manually.

Recursive Operations

Upload or download entire directory trees with a single action. FoxTerm handles recursion automatically, preserving directory structure and permissions.

Compression On-the-Fly

Compress files before transfer to save bandwidth. FoxTerm supports:

• Zip — Universal compatibility
• Tar.gz — Linux-friendly format
• Tar.xz — High compression ratio

Extract archives remotely without downloading them first.

Security

All file transfers happen over the existing SSH connection. No separate SFTP session, no additional authentication, no extra ports to open.

Credentials are never stored in plaintext. If you’re using Secure Enclave-stored keys, file operations require biometric verification.

Use Cases

Configuration Management

Edit nginx.conf, docker-compose.yml, or application configs directly on the server. See changes take effect immediately.

Log Analysis

Download large log files for local analysis, or view them remotely with syntax-highlighted viewers.

Backup & Restore

Compress important directories, download to your Mac, and store in Time Machine or cloud backup.

Code Deployment

Upload build artifacts, deployment scripts, or static assets to production servers.

Database Dumps

Download .sql backups from remote servers, or upload restoration files.

The Bottom Line

FoxTerm eliminates the friction of remote file management. Whether you’re editing a single config file or transferring gigabytes of data, everything happens in one interface — securely, efficiently, and without breaking your workflow.

Download FoxTerm at foxterm.app.

SSH agent forwarding lets you authenticate to remote servers using your local SSH keys, without ever copying private keys to intermediate hosts. It’s a powerful feature for managing complex infrastructure securely.

The Problem: Key Proliferation

When managing multiple servers, you face a choice:

Option 1: Copy your private key to each server

• ❌ Security risk: private key exposed on multiple systems
• ❌ Key management nightmare: revoke on all servers if compromised
• ❌ Audit difficulty: can’t track which key was used where

Option 2: Create separate keys for each server

• ❌ Key explosion: hundreds of keys to manage
• ❌ Configuration complexity: which key for which server?
• ❌ Rotation overhead: update everywhere when keys expire

Option 3: SSH Agent Forwarding

• ✅ Single key on your local machine
• ✅ Keys never leave your device
• ✅ Centralized key management
• ✅ Easy revocation

How SSH Agent Forwarding Works

┌─────────────┐         ┌─────────────┐         ┌─────────────┐
│  Your Mac   │────────▶│  Server A   │────────▶│  Server B   │
│  (SSH Key)  │  SSH    │  (No key)   │  SSH    │  (No key)   │
│  SSH Agent  │◀────────│  Forward    │◀────────│  Forward    │
└─────────────┘  Agent  └─────────────┘  Agent  └─────────────┘

1. Your local SSH agent holds your private key
2. You SSH to Server A with agent forwarding enabled
3. Server A can use your key to authenticate to Server B
4. Your private key never leaves your Mac

Enabling Agent Forwarding

Method 1: Command Line

ssh -A user@server-a
# Now from server-a, you can SSH to server-b using your local key
ssh user@server-b

The -A flag enables agent forwarding.

Method 2: SSH Config (Recommended)

# ~/.ssh/config
Host server-a
    HostName server-a.example.com
    User admin
    ForwardAgent yes

Host server-b
    HostName server-b.example.com
    User admin
    ProxyJump server-a
    ForwardAgent yes

Now just ssh server-a and agent forwarding is automatic.

Method 3: Global Default

# ~/.ssh/config
Host *
    ForwardAgent yes

⚠️ Security warning: Only enable globally if you trust all servers you connect to.

Security Considerations

Agent forwarding is powerful but requires trust:

The Risk

When you enable agent forwarding to a server, that server’s root user can:

• Use your SSH agent to authenticate to other servers
• Impersonate you on any system where your key is authorized

Mitigation Strategies

1. Only forward to trusted servers

# Good: Forward to your own infrastructure
Host myserver.com
    ForwardAgent yes

# Bad: Forward to shared/untrusted systems
Host public-shell.example.com
    ForwardAgent no  # Explicitly disable

2. Use ProxyJump instead when possible

# Instead of forwarding through server-a to reach server-b
Host server-b
    ProxyJump server-a

ProxyJump creates a direct tunnel without exposing your agent to the intermediate host.

3. Restrict agent forwarding scope

# Only allow specific keys to be forwarded
Host server-a
    ForwardAgent yes
    IdentityFile ~/.ssh/work_id_ed25519
    IdentitiesOnly yes

Practical Use Cases

Use Case 1: Bastion Host to Private Servers

# Your Mac → Bastion → Private Server
ssh -A bastion.example.com
ssh internal-server  # Uses your local key

Use Case 2: CI/CD Deployments

# Deploy to multiple servers through a gateway
ssh -A deploy-gateway
for server in web1 web2 web3; do
    ssh $server 'cd /app && git pull && systemctl restart app'
done

Use Case 3: Git Operations on Remote Servers

# Clone private repos on remote server using your local SSH key
ssh -A server
git clone git@github.com:company/private-repo.git

Your GitHub SSH key works on the remote server without copying it.

FoxTerm Agent Forwarding Support

FoxTerm makes agent forwarding seamless:

Visual Agent Management

• See all loaded SSH keys in the connection panel
• Toggle agent forwarding per connection
• Monitor which keys are being used

One-Click Forwarding

Enable agent forwarding in the connection settings:

1. Open connection properties
2. Check “Enable Agent Forwarding”
3. Connect — your keys are available on the remote server

Key Selection

Choose which keys to forward:

• Forward all keys from your Secure Enclave
• Forward specific keys only
• Restrict by destination host

Security Indicators

FoxTerm shows clear indicators when agent forwarding is active:

• 🔒 Lock icon in the status bar
• List of servers using your agent
• One-click revoke all forwarding

Advanced: Restricting Forwarded Keys

SSH Agent Constraints

You can restrict which keys are available:

# Load only specific key into agent
ssh-add ~/.ssh/work_id_ed25519

# List loaded keys
ssh-add -l

# Remove all keys
ssh-add -D

Server-Side Restrictions

On the remote server, restrict which keys can be used:

# /etc/ssh/sshd_config on remote server
Match User admin
    AllowAgentForwarding yes
    # But restrict what they can do
    ForceCommand /usr/local/bin/restricted-shell

Troubleshooting

Problem: Agent forwarding not working

Check 1: Is SSH agent running?

echo $SSH_AUTH_SOCK
# Should show a path like /tmp/com.apple.launchd/Listeners

Check 2: Are keys loaded?

ssh-add -l
# Should list your keys

Check 3: Is forwarding enabled?

ssh -G host | grep forwardagent
# Should show "yes"

Problem: Permission denied on remote server

Your key might not be authorized on the target server. Check:

# On remote server
cat ~/.ssh/authorized_keys
# Your public key should be listed

Problem: Agent forwarding works locally but not in scripts

Scripts don’t inherit your SSH agent by default. Fix:

# In your script
export SSH_AUTH_SOCK=$(ssh-agent -s | grep SSH_AUTH_SOCK | cut -d= -f2 | cut -d' ' -f1)

Best Practices

1. Use ProxyJump when possible — Safer than agent forwarding
2. Forward only to trusted hosts — Never forward to shared systems
3. Restrict key scope — Use IdentitiesOnly yes in SSH config
4. Monitor agent usage — Check which servers are using your keys
5. Rotate keys regularly — Even with forwarding, good hygiene matters
6. Use separate keys — Different keys for work, personal, and production

Conclusion

SSH agent forwarding is a powerful tool for managing complex infrastructure securely. When used correctly, it eliminates the need to copy private keys across servers while maintaining centralized key management.

FoxTerm makes agent forwarding visual and secure, with clear indicators and granular control over which keys are forwarded where.

FoxTerm Pro includes advanced SSH agent management. Download at foxterm.app.

In a secure infrastructure, you don’t expose every server to the internet. Instead, you place a single hardened server — the bastion host (or jump server) — at the network boundary. All SSH connections flow through this gateway, giving you centralized access control, auditing, and a reduced attack surface.

This guide shows you how to build, harden, and manage SSH bastion hosts for production environments.

Why Use a Bastion Host?

Without Bastion Host

Internet → Server 1 (SSH exposed)
         → Server 2 (SSH exposed)
         → Server 3 (SSH exposed)

Problems:

• Every server is a potential entry point
• Each server needs individual security hardening
• No centralized access logging
• Difficult to revoke access (must update every server)

With Bastion Host

Internet → Bastion Host (only SSH exposed)
            → Server 1 (internal only)
            → Server 2 (internal only)
            → Server 3 (internal only)

Benefits:

• Single hardened entry point
• Centralized authentication and authorization
• Complete audit trail of all connections
• Easy access revocation (one place to update)
• Internal servers not exposed to internet

Architecture Design

Basic Setup

                    ┌─────────────┐
   Internet ───────→│ Bastion Host│────── Private Network
                    │  (Public IP) │
                    └─────────────┘
                         │
              ┌──────────┼──────────┐
              ↓          ↓          ↓
         ┌────────┐ ┌────────┐ ┌────────┐
         │ Web    │ │ App    │ │ DB     │
         │ Server │ │ Server │ │ Server │
         └────────┘ └────────┘ └────────┘
         (Private   (Private   (Private
          IP only)   IP only)   IP only)

Multi-Tier Architecture

For larger organizations:

Internet → External Bastion → Internal Bastion → Production Servers
                                  ↓
                             Staging Servers

Each tier adds another layer of access control.

Setting Up a Bastion Host

Step 1: Choose the Right Server

Requirements:

• Minimal OS installation (Ubuntu Server, Alpine Linux, or Amazon Linux)
• Small instance (t3.micro or equivalent is sufficient for most teams)
• Public IP address
• Private network access to internal servers

Step 2: Install and Harden OpenSSH

# Update system
sudo apt update && sudo apt upgrade -y

# Install OpenSSH server
sudo apt install openssh-server -y

# Backup default config
sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak

Edit SSH configuration:

# /etc/ssh/sshd_config

# Disable password authentication
PasswordAuthentication no

# Enable public key authentication
PubkeyAuthentication yes

# Disable root login
PermitRootLogin no

# Restrict which users can connect
AllowUsers alice bob charlie

# Enable detailed logging
LogLevel VERBOSE

# Set idle timeout (15 minutes)
ClientAliveInterval 900
ClientAliveCountMax 0

# Disable X11 forwarding (unless needed)
X11Forwarding no

# Disable agent forwarding by default
AllowAgentForwarding no

# Limit authentication attempts
MaxAuthTries 3

# Use strong ciphers only
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com

# Use strong MACs
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com

# Port (optional: change from default 22)
Port 2222

Restart SSH:

sudo systemctl restart sshd

Step 3: Configure Firewall

# Install UFW
sudo apt install ufw -y

# Allow SSH (custom port if changed)
sudo ufw allow 2222/tcp

# Deny all other incoming traffic
sudo ufw default deny incoming

# Enable firewall
sudo ufw enable

Step 4: Set Up User Accounts

# Create user
sudo adduser alice

# Create .ssh directory
sudo mkdir -p /home/alice/.ssh
sudo chmod 700 /home/alice/.ssh

# Add public key
sudo echo "ssh-ed25519 AAAA... alice@company.com" > /home/alice/.ssh/authorized_keys
sudo chmod 600 /home/alice/.ssh/authorized_keys
sudo chown -R alice:alice /home/alice/.ssh

# Restrict shell (optional: limit to SSH tunneling only)
sudo usermod -s /bin/rbash alice

Jump Host Configuration

Client-Side Configuration

Users configure their SSH client to use the bastion as a jump host.

SSH Config File

# ~/.ssh/config

# Bastion host
Host bastion
    HostName bastion.example.com
    Port 2222
    User alice
    IdentityFile ~/.ssh/id_ed25519_bastion
    ForwardAgent no

# Internal servers via bastion
Host internal-*
    ProxyJump bastion
    User deploy
    IdentityFile ~/.ssh/id_ed25519_internal

# Specific servers
Host internal-web-01
    HostName 10.0.1.10

Host internal-db-01
    HostName 10.0.2.10

Connect directly:

ssh internal-web-01
# Automatically jumps through bastion

Command-Line Jump

ssh -J alice@bastion.example.com:2222 deploy@10.0.1.10

FoxTerm Configuration

FoxTerm makes jump hosts visual:

1. Settings → SSH → Add Server
2. Enter bastion details (hostname, port, key)
3. Mark as “Jump Host”
4. Add internal servers with bastion as proxy
5. Connect to any internal server — FoxTerm handles the jump automatically

Access Control

Role-Based Access

Create groups for different access levels:

# Create groups
sudo groupadd ssh-admins
sudo groupadd ssh-developers
sudo groupadd ssh-readonly

# Add users to groups
sudo usermod -aG ssh-developers alice
sudo usermod -aG ssh-admins bob

Configure access per group:

# /etc/ssh/sshd_config

# Admins: full access
Match Group ssh-admins
    AllowTcpForwarding yes
    AllowAgentForwarding yes
    PermitOpen any

# Developers: limited forwarding
Match Group ssh-developers
    AllowTcpForwarding local
    AllowAgentForwarding no
    PermitOpen 10.0.1.0/24:*,10.0.2.0/24:*

# Read-only: no forwarding
Match Group ssh-readonly
    AllowTcpForwarding no
    AllowAgentForwarding no
    ForceCommand /usr/local/bin/readonly-shell.sh

Time-Based Access

Restrict access to business hours:

# /etc/security/access.conf
+ : alice bob : Mon-Fri 09:00-18:00
+ : charlie : Mon-Sun 00:00-23:59  # On-call engineer
- : ALL : ALL

Enable PAM access control:

# /etc/ssh/sshd_config
UsePAM yes

Certificate-Based Access

For large teams, use SSH certificates instead of managing individual keys.

See our SSH Certificates article for details.

Auditing and Logging

Enable Detailed Logging

# /etc/ssh/sshd_config
LogLevel VERBOSE
SyslogFacility AUTH

Logs appear in /var/log/auth.log:

Oct 27 14:32:15 bastion sshd[12345]: Accepted publickey for alice from 203.0.113.50 port 54321 ssh2: ED25519 SHA256:abc123
Oct 27 14:32:16 bastion sshd[12345]: session opened for user alice
Oct 27 14:35:22 bastion sshd[12345]: Received disconnect from 203.0.113.50 port 54321: disconnected by user

Session Recording

Record all terminal sessions for audit purposes.

Using script command

# /usr/local/bin/recorded-shell.sh
#!/bin/bash
LOG_DIR="/var/log/ssh-sessions"
mkdir -p "$LOG_DIR"
LOG_FILE="$LOG_DIR/$(whoami)-$(date +%Y%m%d-%H%M%S).log"
script -f "$LOG_FILE"

Configure as forced command:

# /etc/ssh/sshd_config
Match Group ssh-readonly
    ForceCommand /usr/local/bin/recorded-shell.sh

Using tlog (specialized tool)

# Install tlog
sudo apt install tlog

# Configure
sudo systemctl enable tlog-rec-session

Sessions are recorded and can be replayed with tlog-play.

Centralized Logging

Forward logs to a central system:

# /etc/rsyslog.d/ssh.conf
auth,authpriv.* @logs.company.com:514

Or use cloud services:

• AWS CloudWatch Logs
• Datadog
• Splunk
• ELK Stack (Elasticsearch, Logstash, Kibana)

Monitoring and Alerting

Monitor Failed Login Attempts

# Check recent failures
grep "Failed password" /var/log/auth.log | tail -20

# Count failures per IP
grep "Failed password" /var/log/auth.log | awk '{print $(NF-3)}' | sort | uniq -c | sort -rn

Set Up Alerts

Use fail2ban to detect and block brute force attacks:

sudo apt install fail2ban

# /etc/fail2ban/jail.local
[sshd]
enabled = true
port = 2222
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
bantime = 3600
findtime = 600

Dashboard Metrics

Monitor bastion health:

# Active connections
who | wc -l

# System load
uptime

# Disk usage
df -h /var/log

# Memory usage
free -m

Integrate with monitoring tools (Prometheus, Grafana) for visualization.

High Availability

For critical infrastructure, run multiple bastion hosts.

DNS Round-Robin

# DNS configuration
bastion.example.com → 203.0.113.10
bastion.example.com → 203.0.113.11
bastion.example.com → 203.0.113.12

Clients connect to bastion.example.com, DNS rotates between IPs.

Load Balancer

Place a load balancer in front of bastion hosts:

Internet → Load Balancer → Bastion 1
                          → Bastion 2
                          → Bastion 3

Use HAProxy or Nginx for TCP load balancing.

Shared Configuration

Keep bastion configs synchronized:

• Use configuration management (Ansible, Puppet, Chef)
• Store SSH keys in a central system (HashiCorp Vault)
• Sync user accounts via LDAP/Active Directory

Hardening Checklist

Before deploying to production:

• [ ] OS fully updated
• [ ] SSH hardened (no passwords, key-only auth)
• [ ] Firewall configured (only SSH port open)
• [ ] Fail2ban installed and configured
• [ ] Logging enabled and forwarded
• [ ] User accounts created with proper keys
• [ ] Access control rules defined
• [ ] Session recording enabled (if required)
• [ ] Monitoring and alerting configured
• [ ] Backup bastion ready (for HA)
• [ ] Documentation complete
• [ ] Incident response plan documented

Common Mistakes

1. Exposing Internal Servers

Wrong: Internal servers have public IPs and accept direct SSH.

Right: Internal servers only have private IPs, accessible only via bastion.

2. Weak Authentication

Wrong: Password-based authentication enabled.

Right: Key-only authentication, preferably with certificates.

3. No Logging

Wrong: Default SSH logging (minimal information).

Right: Verbose logging, centralized, with session recording.

4. Overly Permissive Access

Wrong: All users can access all servers.

Right: Role-based access, principle of least privilege.

5. Single Point of Failure

Wrong: One bastion host, no backup.

Right: Multiple bastion hosts with failover.

FoxTerm Bastion Support

FoxTerm simplifies bastion host management:

Visual Jump Host Configuration

Add bastion hosts once, reuse across all connections. No repetitive SSH config editing.

Automatic Key Management

Keys stored in Secure Enclave, automatically presented when connecting through bastions.

Connection Chaining

Connect to deeply nested internal servers through multiple bastion hops. FoxTerm manages the chain transparently.

Audit Trail

FoxTerm Pro logs all connections, including:

• Timestamp
• Server accessed
• Bastion used
• Duration
• Commands executed (with session recording)

Export logs for compliance reporting.

Conclusion

SSH bastion hosts are essential for secure infrastructure. They reduce attack surface, centralize access control, and provide complete audit trails. With proper hardening, monitoring, and high availability, bastion hosts become the foundation of your security posture.

FoxTerm makes working with bastion hosts seamless, so you get security without sacrificing convenience.

FoxTerm Pro includes bastion host support and audit logging. Download at foxterm.app.

Traditional SSH key management works fine for individuals: generate a key pair, copy the public key to every server, and you’re done. But at scale — dozens of servers, hundreds of developers, frequent onboarding and offboarding — this approach breaks down.

Enter SSH certificates: a standardized way to issue time-limited, role-based credentials signed by a trusted Certificate Authority (CA).

The Problem with Static Keys

Consider a typical startup scenario:

• 50 developers
• 200 production servers
• Developers join and leave monthly
• Servers are provisioned and decommissioned weekly

With static keys, every change requires:

1. Onboarding: Copy the new developer’s public key to all 200 servers
2. Offboarding: Remove the departing developer’s key from all 200 servers
3. Rotation: Periodically regenerate all keys and redistribute them

This is error-prone, slow, and doesn’t scale.

How SSH Certificates Work

SSH certificates solve these problems by introducing a Certificate Authority (CA):

Traditional Flow (Static Keys)

Developer → Public Key → Copied to Every Server

Certificate Flow

Developer → Public Key → CA Signs Certificate → Server Trusts CA → Access Granted

The server only needs to trust the CA’s public key. When a developer presents a certificate, the server verifies it was signed by the CA and grants access accordingly.

Certificate Components

An SSH certificate contains:

• Public key — The user’s or host’s key
• Identity — Username or hostname
• Valid principals — Which usernames this cert allows
• Validity period — Start and end timestamps
• Extensions — Permissions (e.g., can forward ports, can use agent)
• Critical options — Restrictions (e.g., source IP, command whitelist)
• Signature — Signed by the CA

Setting Up an SSH CA

Step 1: Generate CA Keys

# Generate CA key pair
ssh-keygen -t ed25519 -f ca_key -C "SSH CA Key"

# This creates:
# ca_key     (private key — keep secure!)
# ca_key.pub (public key — distribute to servers)

Step 2: Configure Servers to Trust the CA

On each server, add the CA’s public key to sshd_config:

# /etc/ssh/sshd_config
TrustedUserCAKeys /etc/ssh/ca_key.pub

Restart sshd:

sudo systemctl restart sshd

Now any certificate signed by this CA will be accepted.

Step 3: Issue User Certificates

# Sign a user's public key
ssh-keygen -s ca_key \
  -I alice@company.com \
  -n alice,deployer \
  -V +1w \
  -O clear \
  -O permit-port-forwarding \
  -O permit-agent-forwarding \
  alice_id_ed25519.pub

# This creates: alice_id_ed25519-cert.pub

Flags explained:

• -I: Identity (logged in auth logs)
• -n: Valid principals (usernames this cert allows)
• -V: Validity period (+1w = one week from now)
• -O clear: Remove default extensions
• -O permit-*: Explicitly allow features

Step 4: Connect with the Certificate

ssh -i ~/.ssh/alice_id_ed25519 alice@server.example.com

SSH automatically uses the -cert.pub file alongside the private key.

Time-Limited Access

One of the biggest advantages of certificates is automatic expiration.

Issue a certificate valid for 8 hours:

ssh-keygen -s ca_key \
  -I bob@company.com \
  -n bob \
  -V +8h \
  bob_id_ed25519.pub

After 8 hours, the certificate is invalid. No need to manually revoke anything — the server rejects expired certificates automatically.

This is perfect for:

• Contractors: Issue certs matching contract duration
• Incident response: Grant temporary emergency access
• Audits: Ensure all access has an expiration date

Role-Based Certificates

Different roles need different permissions. Create separate CA signing keys for each role:

Developer Certificate

ssh-keygen -s ca_key_dev \
  -I "dev-${USER}" \
  -n "${USER}" \
  -V +1w \
  -O clear \
  -O permit-port-forwarding \
  -O permit-agent-forwarding \
  dev_key.pub

Deployer Certificate

ssh-keygen -s ca_key_deploy \
  -I "deploy-${USER}" \
  -n deployer \
  -V +24h \
  -O clear \
  -O permit-port-forwarding \
  -O force-command=/usr/local/bin/deploy.sh \
  deploy_key.pub

The force-command option restricts the deployer to running only the deployment script.

Admin Certificate

ssh-keygen -s ca_key_admin \
  -I "admin-${USER}" \
  -n root,admin,"${USER}" \
  -V +4h \
  -O clear \
  -O permit-port-forwarding \
  -O permit-agent-forwarding \
  -O permit-pty \
  admin_key.pub

Admin certs have shorter validity and broader access.

Host Certificates

So far we’ve discussed user certificates (proving who you are). SSH also supports host certificates (proving the server is legitimate).

Why Host Certificates Matter

Without host certificates, SSH relies on the known_hosts file to verify server identity. This leads to:

• TOFU (Trust On First Use): Blindly accepting the first connection
• MITM risk: An attacker could intercept the initial connection
• Key rotation pain: Updating known_hosts when servers change

Host certificates solve this by having servers present certificates signed by a trusted CA.

Setting Up Host Certificates

# Sign a host's public key
ssh-keygen -s ca_key_host \
  -I "prod-web-01.company.com" \
  -h \
  -n prod-web-01.company.com,10.0.1.100 \
  -V +52w \
  /etc/ssh/ssh_host_ed25519_key.pub

# This creates: /etc/ssh/ssh_host_ed25519_key-cert.pub

The -h flag indicates this is a host certificate.

Configure sshd to use it:

# /etc/ssh/sshd_config
HostCertificate /etc/ssh/ssh_host_ed25519_key-cert.pub

Clients trust the host CA:

# ~/.ssh/config
GlobalKnownHostsFile /etc/ssh/known_hosts_ca

Now clients automatically verify server certificates without manual known_hosts management.

Certificate Revocation

Sometimes you need to revoke a certificate before it expires (e.g., employee termination, compromised key).

Method 1: KRL (Key Revocation List)

Generate a revocation list:

ssh-keygen -k -f revoked_keys.krl ca_key.pub user_cert_to_revoke.pub

Configure sshd to check the KRL:

# /etc/ssh/sshd_config
RevokedKeys /etc/ssh/revoked_keys.krl

Update the KRL whenever you revoke certificates.

Method 2: Short Validity Periods

The simplest revocation strategy: issue certificates with very short validity (e.g., 1 hour). If you need to revoke access, just don’t renew the certificate.

This requires an automated certificate issuance system but eliminates the complexity of KRLs.

Automated Certificate Issuance

For large teams, manual certificate signing doesn’t scale. Build an automated system:

Architecture

Developer → Auth System (SSO/MFA) → Certificate API → CA Signs → Returns Cert

Example Flow

1. Developer authenticates via SSO (Okta, Google Workspace)
2. Backend verifies identity and role
3. Backend calls ssh-keygen -s or uses a library like golang.org/x/crypto/ssh
4. Returns signed certificate to developer’s SSH agent
5. Developer connects to servers using the cert

Tools

Several open-source tools automate this:

• Teleport: Full SSH certificate management platform
• HashiCorp Vault: SSH secrets engine with certificate signing
• Smallstep: Modern PKI with SSH certificate support
• Certstrap: Simple self-hosted SSH CA

FoxTerm Integration

FoxTerm Pro includes built-in SSH certificate support:

Import CA-Signed Certificates

If your organization issues SSH certificates, import them into FoxTerm:

1. Go to Settings → SSH Keys
2. Click “Import Certificate”
3. Select your private key and certificate files
4. FoxTerm automatically uses the certificate for authentication

Automatic Certificate Renewal

FoxTerm can integrate with your certificate API to automatically renew certificates before they expire. Configure:

• Certificate endpoint URL
• Authentication method (API key, OAuth token)
• Renewal interval (e.g., every 6 hours)

FoxTerm handles the rest — you always have a valid certificate.

Host Certificate Verification

FoxTerm verifies host certificates automatically. If a server presents an invalid or expired certificate, FoxTerm warns you before connecting.

Migration Strategy

Moving from static keys to certificates? Here’s a phased approach:

Phase 1: Set Up CA (Week 1)

• Generate CA keys
• Configure servers to trust the CA
• Test with a single user

Phase 2: Dual Authentication (Weeks 2-4)

• Issue certificates to pilot users
• Keep static keys as fallback
• Monitor auth logs for issues

Phase 3: Full Migration (Weeks 5-8)

• Issue certificates to all users
• Remove static keys from servers
• Document certificate workflows

Phase 4: Automation (Weeks 9-12)

• Build automated certificate issuance
• Integrate with SSO
• Set up monitoring and alerting

Best Practices

Security

• Protect the CA private key: Store in HSM or offline cold storage
• Use short validity periods: 8 hours for users, 52 weeks for hosts
• Separate CAs per environment: Dev, staging, prod should have different CAs
• Audit certificate issuance: Log every certificate signed

Operations

• Automate everything: Manual signing doesn’t scale
• Monitor expiration: Alert before certificates expire
• Test revocation: Regularly verify that revoked certs are rejected
• Document procedures: Onboarding, offboarding, emergency access

Development

• Use strong key types: Ed25519 or RSA 4096+
• Include meaningful identities: Use email addresses or employee IDs
• Limit principals: Only include necessary usernames
• Restrict extensions: Only permit what’s needed

Conclusion

SSH certificates transform key management from a manual chore into an automated, secure, scalable system. They enable:

• Time-limited access: No more stale keys
• Role-based permissions: Different access for different roles
• Centralized revocation: Revoke access instantly
• Host verification: Prevent MITM attacks
• Audit trails: Know who accessed what and when

For teams larger than a handful of developers, SSH certificates are not optional — they’re essential infrastructure.

FoxTerm Pro supports SSH certificates out of the box. Download at foxterm.app.

The SSH config file (~/.ssh/config) is more powerful than most people realize. Beyond simple host aliases, it supports conditional logic, multi-hop connections, and per-host security policies.

Basic Structure

# ~/.ssh/config
Host hostname
    Option1 value1
    Option2 value2

Essential Patterns

Pattern 1: Simple Alias

Host prod
    HostName production.example.com
    User deploy
    IdentityFile ~/.ssh/prod_key

Usage: ssh prod instead of ssh deploy@production.example.com -i ~/.ssh/prod_key

Pattern 2: Wildcard Defaults

# Default for all hosts
Host *
    ServerAliveInterval 60
    ServerAliveCountMax 3
    AddKeysToAgent yes

# Override for specific hosts
Host *.example.com
    User admin
    IdentityFile ~/.ssh/work_key

Host *.personal.com
    User me
    IdentityFile ~/.ssh/personal_key

Pattern 3: ProxyJump (Multi-Hop)

# Bastion host
Host bastion
    HostName bastion.example.com
    User admin

# Internal server via bastion
Host internal
    HostName internal-server.local
    User deploy
    ProxyJump bastion

Usage: ssh internal automatically tunnels through bastion.

Pattern 4: Multiple Jump Hosts

Host region1-gateway
    HostName gw.region1.example.com

Host region1-server
    HostName server.region1.local
    ProxyJump region1-gateway

Host region2-gateway
    HostName gw.region2.example.com

Host region2-server
    HostName server.region2.local
    ProxyJump region2-gateway

Pattern 5: Port Forwarding

Host dev-server
    HostName dev.example.com
    User developer
    LocalForward 5432 localhost:5432
    LocalForward 6379 localhost:6379

Usage: ssh dev-server automatically forwards PostgreSQL and Redis.

Pattern 6: Dynamic Port Forwarding (SOCKS)

Host socks-proxy
    HostName proxy.example.com
    User admin
    DynamicForward 1080

Usage: ssh socks-proxy then configure browser to use SOCKS proxy at localhost:1080.

Advanced Features

Match Blocks

# Apply settings based on criteria
Match Host *.production.*
    LogLevel QUIET
    StrictHostKeyChecking yes

Match User root
    LogLevel VERBOSE

Match OriginalHost github.com
    IdentityFile ~/.ssh/github_key
    IdentitiesOnly yes

Conditional Authentication

Host secure-server
    HostName secure.example.com
    User admin
    # Try key first, then password
    PreferredAuthentications publickey,password
    PubkeyAuthentication yes
    PasswordAuthentication yes

Certificate-Based Auth

Host *.example.com
    CertificateFile ~/.ssh/id_ed25519-cert.pub
    IdentityFile ~/.ssh/id_ed25519

Per-Host Security Policies

# High security for production
Host *.prod.*
    StrictHostKeyChecking yes
    UpdateHostKeys no
    IdentityAgent none
    IdentitiesOnly yes

# Relaxed for development
Host *.dev.*
    StrictHostKeyChecking accept-new
    ForwardAgent yes

Real-World Examples

Example 1: Corporate Environment

# Corporate bastion
Host corp-bastion
    HostName bastion.corp.example.com
    User $USER
    IdentityFile ~/.ssh/corp_key
    CertificateFile ~/.ssh/corp_key-cert.pub

# Internal servers via bastion
Host *.internal.corp.example.com
    ProxyJump corp-bastion
    User $USER
    IdentityFile ~/.ssh/corp_key

# GitHub with corporate key
Host github.com
    IdentityFile ~/.ssh/github_corp_key
    IdentitiesOnly yes

Example 2: Multi-Cloud Setup

# AWS servers
Host *.aws.example.com
    User ec2-user
    IdentityFile ~/.ssh/aws_key
    ProxyJump aws-bastion

Host aws-bastion
    HostName bastion.aws.example.com
    User admin
    IdentityFile ~/.ssh/aws_key

# GCP servers
Host *.gcp.example.com
    User $USER
    IdentityFile ~/.ssh/gcp_key
    ProxyJump gcp-bastion

Host gcp-bastion
    HostName bastion.gcp.example.com
    User $USER
    IdentityFile ~/.ssh/gcp_key

# Azure servers
Host *.azure.example.com
    User azureuser
    IdentityFile ~/.ssh/azure_key

Example 3: Development Workflow

# Local development
Host localhost
    StrictHostKeyChecking no
    UserKnownHostsFile /dev/null

# Docker containers
Host docker-*
    HostName localhost
    User root
    Port 2222
    StrictHostKeyChecking no

# Vagrant VMs
Host vagrant-*
    HostName localhost
    User vagrant
    Port 2200
    IdentityFile ~/.vagrant.d/insecure_private_key
    StrictHostKeyChecking no

Security Best Practices

1. Restrict Agent Forwarding

# Only forward to trusted hosts
Host trusted.example.com
    ForwardAgent yes

Host *
    ForwardAgent no

2. Enforce Key-Only Auth

Host *.production.*
    PreferredAuthentications publickey
    PasswordAuthentication no

3. Limit Key Exposure

Host github.com
    IdentityFile ~/.ssh/github_key
    IdentitiesOnly yes
    AddKeysToAgent no

4. Verify Host Keys

Host *
    StrictHostKeyChecking ask
    UpdateHostKeys yes

Debugging

Test Configuration

# Show resolved config for host
ssh -G hostname

# Verbose connection
ssh -vvv hostname

Common Issues

Problem: Wrong key used

# Fix: Specify IdentitiesOnly
Host hostname
    IdentityFile ~/.ssh/specific_key
    IdentitiesOnly yes

Problem: Connection timeout

# Fix: Add keepalive
Host *
    ServerAliveInterval 60
    ServerAliveCountMax 3

Problem: Permission denied

# Fix: Check key permissions
chmod 600 ~/.ssh/config
chmod 600 ~/.ssh/id_*

FoxTerm SSH Config Integration

FoxTerm reads and respects your SSH config:

Config Import

• Automatically loads ~/.ssh/config
• Shows all defined hosts in sidebar
• Respects ProxyJump chains
• Uses specified identity files

Visual Editor

• Edit SSH config with syntax highlighting
• Validate configuration
• Test connections before saving
• Backup and restore

Enhanced Features

• Visual ProxyJump chain display
• Port forwarding status
• Certificate expiration warnings
• Key usage tracking

Conclusion

Mastering SSH config patterns transforms how you manage remote connections. From simple aliases to complex multi-hop setups, the config file provides declarative, reusable connection definitions.

FoxTerm integrates seamlessly with your SSH config, making complex setups visual and manageable.

FoxTerm Pro includes advanced SSH config management. Download at foxterm.app.

SSH keys are the foundation of secure remote access. But as your infrastructure grows — more servers, more team members, more environments — managing keys becomes a challenge. This guide covers best practices for every stage of the key lifecycle.

Key Generation

Choose the Right Algorithm

Ed25519 (Recommended)

ssh-keygen -t ed25519 -C "your_email@example.com"

• 256-bit security level
• Fastest signing and verification
• Smallest key size
• Resistant to side-channel attacks

RSA (Legacy Compatibility)

ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

• Use only when Ed25519 isn’t supported
• Minimum 4096 bits for modern security
• Slower than Ed25519

ECDSA (NIST Curves)

ssh-keygen -t ecdsa -b 521 -C "your_email@example.com"

• Good performance
• Some organizations have concerns about NIST curves
• Use when Ed25519 isn’t an option

Use Descriptive Comments

The -C flag sets a comment that helps identify the key later:

ssh-keygen -t ed25519 -C "macbook-pro-work-2025"
ssh-keygen -t ed25519 -C "personal-laptop-home"
ssh-keygen -t ed25519 -C "ci-deploy-key-production"

When you see this key in authorized_keys or logs, you’ll know exactly which device or purpose it’s for.

Add a Passphrase

Always protect your private key with a passphrase:

Enter passphrase (empty for no passphrase): [type a strong passphrase]
Enter same passphrase again: [retype]

A passphrase adds an extra layer of security. Even if someone steals your private key file, they can’t use it without the passphrase.

Key Organization

Separate Keys by Purpose

Don’t use a single key for everything. Create separate keys for:

• Work servers — Corporate infrastructure
• Personal projects — Your own servers and services
• CI/CD pipelines — Automated deployment keys
• GitHub/GitLab — Version control access
• Jump hosts — Bastion server access

This limits the blast radius if a key is compromised.

Use SSH Config

Your ~/.ssh/config file maps hosts to specific keys:

# Work production servers
Host prod-*
    User deploy
    IdentityFile ~/.ssh/id_work_ed25519
    IdentitiesOnly yes

# GitHub
Host github.com
    IdentityFile ~/.ssh/id_github_ed25519
    IdentitiesOnly yes

# Personal servers
Host home-server
    HostName 192.168.1.100
    User admin
    IdentityFile ~/.ssh/id_personal_ed25519

The IdentitiesOnly yes directive ensures SSH only offers the specified key, preventing unnecessary key exposure.

Directory Structure

Organize keys in subdirectories:

~/.ssh/
├── config
├── known_hosts
├── work/
│   ├── id_ed25519
│   └── id_ed25519.pub
├── personal/
│   ├── id_ed25519
│   └── id_ed25519.pub
└── ci/
    ├── id_deploy
    └── id_deploy.pub

Reference them in your config:

IdentityFile ~/.ssh/work/id_ed25519

Key Rotation

Regular key rotation limits the damage if a key is compromised.

Rotation Schedule

• High-security environments: Every 90 days
• Standard practice: Every 6-12 months
• After incidents: Immediately

Rotation Process

1. Generate a new key

ssh-keygen -t ed25519 -C "macbook-pro-2025-rotated" -f ~/.ssh/id_ed25519_new

2. Add the new key to servers

ssh-copy-id -i ~/.ssh/id_ed25519_new.pub user@server

3. Verify access with the new key

ssh -i ~/.ssh/id_ed25519_new user@server

4. Remove the old key

ssh user@server "sed -i '/old-key-comment/d' ~/.ssh/authorized_keys"

5. Update SSH config to use the new key

6. Delete the old key files locally

Team Key Management

For teams, individual authorized_keys entries become unmanageable. Consider these approaches:

SSH Certificates

A Certificate Authority (CA) signs user public keys:

# Sign a user's public key
ssh-keygen -s ca_key \
  -I "user@example.com" \
  -n ubuntu,root \
  -V +52w \
  user_key.pub

Servers trust the CA’s public key instead of individual user keys. Benefits:

• Short-lived access — Certificates expire (e.g., 52 weeks)
• Centralized authority — One place to issue/revoke access
• Audit trail — Track who accessed what and when

Tools for Large Teams

• HashiCorp Vault — SSH certificate issuance and management
• Teleport — Access plane with short-lived certificates
• Smallstep — Lightweight certificate authority

Storing Keys Securely

File Permissions

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_*
chmod 644 ~/.ssh/*.pub
chmod 600 ~/.ssh/config

Incorrect permissions cause SSH to reject keys for security reasons.

macOS Keychain

Store passphrases in the Keychain:

ssh-add --apple-use-keychain ~/.ssh/id_ed25519

No need to type your passphrase every time.

Secure Enclave (FoxTerm)

FoxTerm takes this further by storing keys in the Secure Enclave on supported Apple devices. The private key material never leaves the hardware security module — not even FoxTerm can read it.

Emergency Procedures

Lost or Stolen Device

1. Immediately revoke the key from all servers:

ssh user@server "sed -i '/stolen-device-key/d' ~/.ssh/authorized_keys"

2. Generate a new key on your replacement device

3. Add the new key to all servers

4. Investigate how the device was compromised

Compromised Key

If you suspect a key was leaked:

1. Revoke immediately from all servers
2. Generate a new key with a different algorithm (if possible)
3. Audit logs to see if the key was misused
4. Rotate related credentials (passwords, API tokens)

The Bottom Line

Good SSH key management is about discipline: generate keys properly, organize them logically, rotate them regularly, and store them securely. Start with the basics and scale up to certificates as your team grows.

Download FoxTerm at foxterm.app for secure key storage with Secure Enclave support.

SSH keys don’t expire like passwords, but they should be rotated regularly. Compromised keys can provide unauthorized access indefinitely. Automated key rotation ensures security without manual overhead.

Why Rotate SSH Keys?

Risks of not rotating:

• Compromised keys provide permanent access
• Former employees retain access
• Key sprawl (hundreds of unknown keys)
• Compliance violations (SOC2, PCI-DSS require rotation)

Benefits of rotation:

• Limit exposure window
• Revoke access automatically
• Audit trail of key usage
• Meet compliance requirements

Rotation Strategies

Strategy 1: Time-Based Rotation

Rotate keys every N days:

# Rotate every 90 days
ROTATION_INTERVAL=90

Pros: Predictable, easy to schedule Cons: Doesn’t respond to incidents

Strategy 2: Event-Based Rotation

Rotate on specific events:

• Employee departure
• Security incident
• Compliance audit
• Key compromise suspected

Pros: Responsive to threats Cons: Requires monitoring

Strategy 3: Hybrid Approach

Combine time-based and event-based:

• Regular rotation (90 days)
• Immediate rotation on security events
• Gradual rollout for large fleets

Manual Rotation Process

Step 1: Generate New Key

# Generate new key
ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_new -C "user@example.com-2026"

# Start SSH agent with new key
eval $(ssh-agent)
ssh-add ~/.ssh/id_ed25519_new

Step 2: Deploy New Key

# Copy new key to servers
for server in server1 server2 server3; do
  ssh-copy-id -i ~/.ssh/id_ed25519_new.pub user@$server
done

Step 3: Test New Key

# Test connection with new key
for server in server1 server2 server3; do
  ssh -i ~/.ssh/id_ed25519_new user@$server 'echo "Success"'
done

Step 4: Remove Old Key

# Remove old key from servers
for server in server1 server2 server3; do
  ssh user@$server "sed -i '/old-key-comment/d' ~/.ssh/authorized_keys"
done

Step 5: Update SSH Config

# ~/.ssh/config
Host server1 server2 server3
    IdentityFile ~/.ssh/id_ed25519_new
    IdentitiesOnly yes

Automated Rotation Script

Basic Rotation Script

#!/bin/bash
# rotate-keys.sh - Automated SSH key rotation

set -e

SERVERS="server1 server2 server3"
OLD_KEY=~/.ssh/id_ed25519_old
NEW_KEY=~/.ssh/id_ed25519_new
BACKUP_KEY=~/.ssh/id_ed25519_backup

echo "Starting SSH key rotation..."

# Step 1: Backup current key
echo "Backing up current key..."
cp ~/.ssh/id_ed25519 $OLD_KEY 2>/dev/null || true
cp ~/.ssh/id_ed25519.pub $OLD_KEY.pub 2>/dev/null || true

# Step 2: Generate new key
echo "Generating new key..."
ssh-keygen -t ed25519 -f $NEW_KEY -N "" -C "rotated-$(date +%Y%m%d)"

# Step 3: Deploy new key
echo "Deploying new key to servers..."
for server in $SERVERS; do
  echo "  Deploying to $server..."
  ssh-copy-id -i $NEW_KEY.pub user@$server
done

# Step 4: Test new key
echo "Testing new key..."
for server in $SERVERS; do
  if ssh -i $NEW_KEY -o ConnectTimeout=5 user@$server 'exit' 2>/dev/null; then
    echo "  ✓ $server"
  else
    echo "  ✗ $server - FAILED"
    exit 1
  fi
done

# Step 5: Remove old key
echo "Removing old key from servers..."
for server in $SERVERS; do
  ssh user@$server "
    # Remove old key (by comment)
    sed -i '/rotated-/d' ~/.ssh/authorized_keys
    # Keep only new key
    cat >> ~/.ssh/authorized_keys <<EOF
$(cat $NEW_KEY.pub)
EOF
  "
done

# Step 6: Update local config
echo "Updating SSH config..."
mv $NEW_KEY ~/.ssh/id_ed25519
mv $NEW_KEY.pub ~/.ssh/id_ed25519.pub

# Step 7: Restart SSH agent
echo "Restarting SSH agent..."
eval $(ssh-agent)
ssh-add ~/.ssh/id_ed25519

echo "✓ Key rotation complete"

Advanced Rotation with Ansible

# rotate-ssh-keys.yml
---
- name: Rotate SSH keys
  hosts: all
  become: yes
  vars:
    new_key_pub: "{{ lookup('file', '~/.ssh/id_ed25519_new.pub') }}"
  
  tasks:
    - name: Backup authorized_keys
      copy:
        src: /root/.ssh/authorized_keys
        dest: /root/.ssh/authorized_keys.backup
        remote_src: yes
    
    - name: Add new key
      authorized_key:
        user: root
        key: "{{ new_key_pub }}"
        state: present
    
    - name: Test new key
      command: ssh -i /root/.ssh/id_ed25519_new localhost exit
      delegate_to: localhost
      ignore_errors: yes
      register: test_result
    
    - name: Remove old keys
      authorized_key:
        user: root
        key: "{{ item }}"
        state: absent
      loop: "{{ old_keys }}"
      when: test_result.rc == 0

Run:

ansible-playbook -i inventory rotate-ssh-keys.yml

Zero-Downtime Rotation

Overlap Period

Keep both old and new keys active during transition:

# Server authorized_keys
# Old key (valid until 2026-11-01)
ssh-ed25519 AAAA... old-key-comment

# New key (valid from 2026-10-17)
ssh-ed25519 AAAA... new-key-comment

Gradual Rollout

#!/bin/bash
# gradual-rotation.sh

# Phase 1: Deploy new key to 10% of servers
servers_10=$(shuf -n 10% servers.txt)
for server in $servers_10; do
  ssh-copy-id -i new_key.pub user@$server
done

# Phase 2: Test and monitor
sleep 24h

# Phase 3: Deploy to remaining servers
servers_90=$(comm -23 servers.txt <(echo "$servers_10" | sort))
for server in $servers_90; do
  ssh-copy-id -i new_key.pub user@$server
done

# Phase 4: Remove old keys
for server in $(cat servers.txt); do
  ssh user@$server "sed -i '/old-key/d' ~/.ssh/authorized_keys"
done

Enterprise Key Management

SSH Certificate Authority

Use SSH certificates instead of keys:

# Generate CA key
ssh-keygen -f ca_key -N ""

# Sign user key
ssh-keygen -s ca_key -I user@example.com -n user -V +90d user_key.pub

# Server trusts CA
# /etc/ssh/sshd_config
TrustedUserCAKeys /etc/ssh/ca_key.pub

Benefits:

• Automatic expiration
• Centralized trust
• No key distribution
• Easy revocation

HashiCorp Vault SSH Secrets

# Configure Vault
vault write ssh/config/ca generate_signing_key=true

# Issue short-lived certificate
vault write ssh/sign/otp_key_role \
    ip=192.168.1.100 \
    valid_principals=user

AWS Systems Manager

# Send SSH public key to instance
aws ssm send-ssh-public-key \
  --instance-id i-1234567890abcdef0 \
  --instance-os-user ec2-user \
  --ssh-public-key file://key.pub

FoxTerm Key Rotation Support

FoxTerm simplifies enterprise key rotation:

Visual Key Management

• View all SSH keys across servers
• Track key age and usage
• Identify unused keys
• One-click rotation

Automated Rotation

• Schedule regular rotation (30/60/90 days)
• Zero-downtime overlap period
• Automatic testing and rollback
• Audit log of all rotations

Certificate Management

• SSH CA integration
• Automatic certificate renewal
• Expiration notifications
• Revocation management

Compliance Reporting

• Key inventory report
• Rotation compliance status
• Audit trail
• Export for compliance audits

Best Practices

1. Rotate regularly — Every 90 days maximum
2. Automate rotation — Scripts or tools like FoxTerm
3. Test before removing — Verify new key works
4. Overlap period — Keep both keys active during transition
5. Use certificates — SSH CA for large fleets
6. Audit regularly — Review authorized_keys files
7. Monitor usage — Track which keys are used
8. Backup before rotation — Keep old keys as backup
9. Document process — Clear rotation procedures
10. Compliance tracking — Meet SOC2/PCI-DSS requirements

Conclusion

SSH key rotation is essential for enterprise security. Automated rotation eliminates manual overhead while ensuring keys are regularly updated.

FoxTerm makes key rotation visual and automated, with scheduling, testing, and compliance reporting.

FoxTerm Pro includes enterprise SSH key rotation and management. Download at foxterm.app.

When generating SSH keys, you’re presented with a choice of algorithms: Ed25519, RSA, ECDSA, or DSA. Most people stick with the default (RSA) without understanding the trade-offs. But the choice matters for security, performance, and compatibility.

This guide compares all four SSH key types to help you make an informed decision.

Quick Recommendation

Use Ed25519 for new keys. It’s the most secure, fastest, and smallest key type. Only use RSA if you need compatibility with very old systems.

ssh-keygen -t ed25519 -C "your_email@example.com"

Now let’s understand why.

The Four Key Types

1. Ed25519 (Recommended)

Ed25519 uses elliptic curve cryptography based on Curve25519.

Key size: 256 bits (public key is 68 characters)

Generate:

ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519

Advantages:

• Fastest: Both key generation and signing are extremely fast
• Smallest: Shortest keys and signatures
• Most secure: Resistant to side-channel attacks
• Simple: No configuration options to get wrong
• Modern: Designed in 2011 with modern cryptographic standards

Disadvantages:

• Compatibility: Not supported by very old SSH implementations (pre-2014)
• Fixed size: Can’t increase key length for future-proofing (though 256-bit Ed25519 is considered secure for decades)

Support:

• OpenSSH 6.5+ (January 2014)
• All modern operating systems
• FoxTerm: Full support

2. RSA (Legacy Default)

RSA is the oldest widely-used SSH key algorithm.

Key size: 2048-4096 bits (recommended minimum: 3072)

Generate:

ssh-keygen -t rsa -b 4096 -f ~/.ssh/id_rsa

Advantages:

• Universal compatibility: Works with every SSH implementation ever made
• Well understood: Decades of cryptanalysis and real-world use
• Configurable: Can increase key size for theoretical future-proofing

Disadvantages:

• Slowest: Key generation and signing are computationally expensive
• Largest: 4096-bit keys are 742 characters long
• Less secure per bit: Requires much larger keys for equivalent security
• Vulnerable to quantum computers: Like all current public-key crypto, but RSA is most affected

Security note: 1024-bit RSA is considered broken. Use 3072-bit minimum, preferably 4096.

Support:

• Every SSH client/server ever made
• FoxTerm: Full support

3. ECDSA (Elliptic Curve DSA)

ECDSA uses elliptic curve cryptography with NIST curves.

Key size: 256, 384, or 521 bits

Generate:

ssh-keygen -t ecdsa -b 256 -f ~/.ssh/id_ecdsa

Advantages:

• Smaller than RSA: Equivalent security with much smaller keys
• Faster than RSA: Better performance for signing operations
• Standardized: NIST curves are widely studied

Disadvantages:

• Complexity: Implementation complexity has led to vulnerabilities
• NIST curves: Some concern about potential NSA influence on curve selection
• Variable quality: Security depends on random number generator quality
• Slower than Ed25519: Ed25519 outperforms ECDSA in every metric

Support:

• OpenSSH 5.7+ (2011)
• Most modern systems
• FoxTerm: Full support

4. DSA (Deprecated)

DSA is an older algorithm that is now deprecated.

Key size: Fixed at 1024 bits

Generate:

ssh-keygen -t dsa -f ~/.ssh/id_dsa

Advantages:

• None in 2025

Disadvantages:

• Fixed key size: 1024 bits is considered insecure
• Deprecated: Removed from OpenSSH 7.0+ (2015)
• Slow: Worse performance than both RSA and ECDSA
• Vulnerable: Susceptible to poor random number generation

Never use DSA for new keys. If you have existing DSA keys, replace them immediately.

Security Comparison

Equivalent Security Levels

Note: None of these are resistant to large-scale quantum computers. Post-quantum SSH is still experimental.

Attack Resistance

Side-channel attacks: Ed25519 > ECDSA > RSA > DSA

Ed25519 was designed to be constant-time, making it resistant to timing attacks.

Implementation flaws: Ed25519 > RSA > ECDSA > DSA

Simpler algorithms have fewer opportunities for implementation errors.

Random number quality: Ed25519 > RSA > ECDSA > DSA

Ed25519 is more forgiving of imperfect randomness.

Performance Benchmarks

Key generation time (average on M2 MacBook):

Ed25519:  0.001 seconds
ECDSA:    0.003 seconds
RSA 2048: 0.1 seconds
RSA 4096: 0.8 seconds
DSA:      0.05 seconds

Signing operations per second:

Ed25519:  ~50,000 ops/sec
ECDSA:    ~20,000 ops/sec
RSA 2048: ~2,000 ops/sec
RSA 4096: ~500 ops/sec

Ed25519 is dramatically faster for both key generation and authentication.

Compatibility Matrix

*Recent versions only

Rule of thumb: If your servers run OpenSSH 6.5+ (released 2014), Ed25519 works fine. For anything older, use RSA 4096.

Migration Guide: Replace Old Keys

Step 1: Generate New Ed25519 Key

ssh-keygen -t ed25519 -C "your_email@example.com" -f ~/.ssh/id_ed25519

Step 2: Add to SSH Agent

ssh-add ~/.ssh/id_ed25519

Step 3: Copy to Servers

ssh-copy-id -i ~/.ssh/id_ed25519 user@server

Or manually append to ~/.ssh/authorized_keys on each server.

Step 4: Test Connection

ssh -i ~/.ssh/id_ed25519 user@server

Step 5: Update SSH Config

# ~/.ssh/config
Host *
    IdentityFile ~/.ssh/id_ed25519
    # Keep old key as fallback during transition
    IdentityFile ~/.ssh/id_rsa

Step 6: Remove Old Keys

Once confident all servers accept the new key:

rm ~/.ssh/id_rsa ~/.ssh/id_rsa.pub

Keep backups until you’ve verified everything works.

Multiple Keys Strategy

For complex environments, maintain multiple keys:

# Personal Ed25519 key
ssh-keygen -t ed25519 -C "personal@email.com" -f ~/.ssh/id_personal

# Work RSA key (for legacy systems)
ssh-keygen -t rsa -b 4096 -C "work@company.com" -f ~/.ssh/id_work

# Deployment key (restricted, no passphrase)
ssh-keygen -t ed25519 -C "deploy@production" -f ~/.ssh/id_deploy -N ""

Configure per-host:

# ~/.ssh/config
Host github.com
    IdentityFile ~/.ssh/id_personal

Host *.company.com
    IdentityFile ~/.ssh/id_work

Host production-*
    IdentityFile ~/.ssh/id_deploy

Key Passphrases

Always protect keys with passphrases:

ssh-keygen -t ed25519 -C "email@example.com"
# Prompts for passphrase

Benefits:

• Protects key if file is stolen
• Adds encryption layer (AES-256 by default)
• Minimal inconvenience with ssh-agent

Use ssh-agent to avoid retyping:

# macOS: Keychain integration
ssh-add --apple-use-keychain ~/.ssh/id_ed25519

# Linux: Start agent
eval $(ssh-agent -s)
ssh-add ~/.ssh/id_ed25519

FoxTerm Key Management

FoxTerm simplifies SSH key management:

Generate Keys

Settings → SSH Keys → “Generate New Key”:

• Choose algorithm (Ed25519 recommended)
• Set optional passphrase
• Key is stored in Secure Enclave (macOS/iOS)

Import Existing Keys

Drag and drop private key files into FoxTerm, or use “Import Key” button.

Secure Storage

On macOS and iOS, FoxTerm stores keys in the Secure Enclave, hardware-isolated from the main processor. Even if your device is compromised, keys remain protected.

Auto-Selection

FoxTerm automatically selects the appropriate key based on server compatibility and your SSH config.

Conclusion

For new SSH keys in 2025, Ed25519 is the clear winner: faster, smaller, more secure, and well-supported. RSA remains necessary for legacy compatibility. ECDSA is acceptable but offers no advantage over Ed25519. DSA should never be used.

Generate your Ed25519 key today and retire those old RSA keys.

FoxTerm manages SSH keys securely with Secure Enclave support. Download at foxterm.app.

SSH isn’t just for remote shells. Its port forwarding capabilities create secure tunnels for any TCP traffic. Database connections, web services, API calls — all can flow through encrypted SSH tunnels, bypassing firewalls and protecting data in transit.

This guide covers all three types of SSH tunneling with practical examples you can use today.

Type 1: Local Port Forwarding (L)

Use case: Access a remote service as if it were running on your local machine.

How It Works

Local Machine                    SSH Server
localhost:8080 ──→ SSH Tunnel ──→ localhost:3306 (MySQL)

You connect to localhost:8080 on your machine, and the traffic is forwarded through the SSH tunnel to port 3306 on the remote server.

Basic Example: Remote MySQL

ssh -L 8080:localhost:3306 user@server.example.com

Now connect your MySQL client to localhost:8080:

mysql -h 127.0.0.1 -P 8080 -u root -p

The connection flows: Your MySQL Client → Local Port 8080 → SSH Tunnel → Server → MySQL on Port 3306

Advanced: Forward to Third-Party Host

ssh -L 8080:db.internal.company.com:3306 user@server.example.com

Traffic flows: Your Machine → SSH Tunnel → Server → db.internal.company.com:3306

The SSH server acts as a bridge to other hosts on its network.

Real-World Scenarios

Access internal dashboards:

# Forward Grafana dashboard
ssh -L 3000:monitoring.internal:3000 user@bastion.company.com
# Open http://localhost:3000 in browser

Connect to Redis:

ssh -L 6379:localhost:6379 user@redis-server.example.com
redis-cli -h 127.0.0.1 -p 6379

Test staging APIs:

ssh -L 8000:staging-api.internal:8000 user@staging-bastion.example.com
curl http://localhost:8000/api/health

FoxTerm Integration

FoxTerm makes local port forwarding visual:

1. Connect to server via SSH
2. Click “Port Forwarding” in toolbar
3. Click “Add Local Forward”
4. Enter local port (e.g., 8080)
5. Enter remote host and port (e.g., localhost:3306)
6. Click “Start”

FoxTerm manages the tunnel in the background. No terminal commands needed.

Type 2: Remote Port Forwarding ®

Use case: Expose a local service to a remote server or the internet.

How It Works

Remote Server                  Your Machine
port 9090 ──→ SSH Tunnel ──→ localhost:3000 (dev server)

Anyone connecting to port 9090 on the remote server reaches your local port 3000.

Basic Example: Expose Dev Server

ssh -R 9090:localhost:3000 user@server.example.com

Now anyone can access your local dev server:

curl http://server.example.com:9090

Advanced: Gateway Ports

By default, remote forwards only listen on 127.0.0.1. To allow external access:

ssh -R 0.0.0.0:9090:localhost:3000 user@server.example.com

Server config must allow this:

# /etc/ssh/sshd_config
GatewayPorts yes

Real-World Scenarios

Demo local work to teammates:

ssh -R 8080:localhost:3000 user@demo-server.example.com
# Share: http://demo-server.example.com:8080

Bypass corporate firewall:

# At office, expose internal tool to home server
ssh -R 443:internal-tool.corp:443 user@home-server.example.com
# At home: https://home-server.example.com

Temporary webhook endpoint:

# Expose local webhook handler to Stripe/PayPal
ssh -R 8443:localhost:8080 user@public-server.example.com
# Configure webhook URL: https://public-server.example.com:8443/webhook

Security Warning

Remote port forwarding exposes your local services. Always:

• Use strong SSH authentication (keys, not passwords)
• Limit which interfaces the remote port binds to
• Close tunnels when done
• Consider using ngrok or cloudflared for production exposure

Type 3: Dynamic Port Forwarding (D)

Use case: Create a SOCKS proxy to route arbitrary traffic through the SSH server.

How It Works

Your Apps → SOCKS Proxy (localhost:1080) → SSH Tunnel → SSH Server → Any Destination

Unlike local/remote forwarding (which forward specific ports), dynamic forwarding creates a general-purpose proxy.

Basic Example: SOCKS Proxy

ssh -D 1080 user@server.example.com

Configure your browser or system to use SOCKS proxy at localhost:1080. All traffic routes through the SSH server.

Browser Configuration

Firefox:

1. Settings → Network Settings → Manual proxy configuration
2. SOCKS Host: 127.0.0.1, Port: 1080
3. Select “SOCKS v5”
4. Check “Proxy DNS when using SOCKS v5”

Chrome (command line):

chrome --proxy-server="socks5://127.0.0.1:1080"

System-wide (macOS):

networksetup -setsocksfirewallproxystate Wi-Fi on
networksetup -setsocksfirewallproxy Wi-Fi 127.0.0.1 1080

Real-World Scenarios

Access internal websites: Browse internal company sites that are only accessible from the office network.

Bypass geo-restrictions:

ssh -D 1080 user@server-in-japan.example.com
# Now browse as if you're in Japan

Secure public WiFi:

ssh -D 1080 user@trusted-server.example.com
# All traffic encrypted through tunnel, safe from WiFi snooping

Debug production APIs:

ssh -D 1080 user@bastion.production.com
# Configure API client to use SOCKS proxy
# Access internal APIs as if you're on the production network

FoxTerm Integration

FoxTerm includes a built-in SOCKS proxy:

1. Connect to server via SSH
2. Click “Port Forwarding” → “Enable SOCKS Proxy”
3. FoxTerm starts a SOCKS5 proxy on localhost:1080
4. Configure apps to use the proxy
5. Toggle on/off from the menu bar

No command-line setup required.

Combining Tunnel Types

Real-world scenarios often combine multiple tunnel types.

Example: Full Development Environment

# Local forward: Access remote database
ssh -L 5432:db.internal:5432 \
    # Remote forward: Expose local dev server
    -R 8080:localhost:3000 \
    # Dynamic forward: SOCKS proxy for internal APIs
    -D 1080 \
    user@bastion.example.com

Now you have:

• PostgreSQL available at localhost:5432
• Dev server accessible at bastion.example.com:8080
• SOCKS proxy at localhost:1080 for internal API access

Jump Hosts (Bastion Servers)

Many organizations use bastion servers as gateways to internal networks.

Single Jump Host

ssh -J user@bastion.example.com user@internal-server

With port forwarding:

ssh -L 8080:db.internal:5432 -J user@bastion.example.com user@internal-server

Multiple Jump Hosts

ssh -J user@bastion1.example.com,user@bastion2.example.com user@internal-server

FoxTerm Configuration

FoxTerm supports jump hosts natively:

1. Settings → SSH → Proxy/Jump Host
2. Enter bastion server details
3. FoxTerm automatically chains connections

SSH Config File

Simplify complex tunnel setups with ~/.ssh/config:

# ~/.ssh/config

# Bastion server
Host bastion
    HostName bastion.example.com
    User deploy
    IdentityFile ~/.ssh/bastion_key

# Internal server via bastion
Host internal
    HostName 10.0.1.100
    User admin
    ProxyJump bastion
    # Local forward: database
    LocalForward 5432 db.internal:5432
    # Dynamic forward: SOCKS proxy
    DynamicForward 1080

# Production web server
Host prod-web
    HostName 10.0.2.50
    User www
    ProxyJump bastion
    # Remote forward: expose local debug server
    RemoteForward 9090 localhost:3000

Now connect with:

ssh internal
# Automatically sets up both port forwards

Troubleshooting

“Address already in use”

Another process is using the local port. Find and kill it:

lsof -i :8080
kill <PID>

Or use a different local port.

“Cannot bind to port”

Port < 1024 requires root. Use higher ports or run with sudo.

Tunnel Disconnects

SSH connections drop. Keep them alive:

ssh -o ServerAliveInterval=60 -o ServerAliveCountMax=3 user@server

Or in ~/.ssh/config:

Host *
    ServerAliveInterval 60
    ServerAliveCountMax 3

Debugging

Add -v flag to see tunnel establishment:

ssh -v -L 8080:localhost:3306 user@server

Look for: Local forwarding listening on 127.0.0.1 port 8080

Security Best Practices

1. Use Key-Based Authentication

Never rely on passwords for tunnel connections:

ssh-keygen -t ed25519 -f ~/.ssh/tunnel_key
ssh-copy-id -i ~/.ssh/tunnel_key user@server

2. Restrict Tunnel Permissions

Limit what users can do with tunnels:

# /etc/ssh/sshd_config
AllowTcpForwarding yes
GatewayPorts no
PermitOpen localhost:3306 localhost:5432

PermitOpen restricts which destinations are allowed.

3. Monitor Active Tunnels

Check what tunnels are active:

ss -tlnp | grep ssh
netstat -tlnp | grep sshd

4. Log Tunnel Usage

Enable logging:

# /etc/ssh/sshd_config
LogLevel VERBOSE

Logs show tunnel establishment in /var/log/auth.log.

5. Time-Limited Tunnels

For temporary access, use timeout:

timeout 3600 ssh -L 8080:localhost:3306 user@server
# Tunnel closes after 1 hour

Conclusion

SSH tunneling is a powerful tool for secure networking. Local forwarding brings remote services to your machine. Remote forwarding exposes local services to remote networks. Dynamic forwarding creates flexible SOCKS proxies. Combined with jump hosts and SSH config, you can navigate complex network topologies securely.

FoxTerm makes all of this visual and manageable, so you spend less time on commands and more time on your actual work.

FoxTerm Pro includes visual port forwarding management. Download at foxterm.app.

When building an SSH client, concurrency is unavoidable: user input, network I/O, terminal rendering, and window resizing can all happen simultaneously. Traditional locking mechanisms easily lead to deadlocks, race conditions, and memory safety issues. FoxTerm adopts the Swift Actor model to fundamentally solve these problems.

Why Actors?

Pain Points of Traditional Approaches

Approach 1: GCD + Manual Locks

Problems:
- Lock granularity is hard to get right (too coarse hurts performance, too fine risks deadlocks)
- Forgetting to release locks leads to deadlocks
- Multi-threaded access to shared state causes race conditions
- EXC_BAD_ACCESS crashes

Approach 2: OperationQueue

Problems:
- Complex operation dependencies
- Difficult to cancel operations
- Hard to guarantee execution order

Approach 3: Combine/async-await

Problems:
- State management still requires manual synchronization
- Multiple async tasks accessing shared state still conflict

Advantages of Actors

Swift Actors provide compiler-level thread safety guarantees:

Core features:
✅ Automatic serialization: Only one task can access Actor internal state at a time
✅ Compile-time checking: Cross-Actor access requires await, enforced by the compiler
✅ No deadlock risk: No manual lock management needed
✅ Seamless integration with async/await

FoxTerm SSH Actor Architecture

Core Design

FoxTerm’s SSH client is designed as an Actor:

┌─────────────────────────────────────────┐
│         SSH Actor (Thread-Safe)         │
│  ┌───────────────────────────────────┐  │
│  │  Private State (auto-serialized)  │  │
│  │  - rawSession: ssh_session?       │  │
│  │  - rawChannel: ssh_channel?       │  │
│  │  - rawSFTP: sftp_session?         │  │
│  │  - fd: Int32 (socket)             │  │
│  │  - isClose: Bool                  │  │
│  └───────────────────────────────────┘  │
│  ┌───────────────────────────────────┐  │
│  │  Public Methods (auto-serialized) │  │
│  │  - connect()                      │  │
│  │  - authenticate()                 │  │
│  │  - shell()                        │  │
│  │  - write(data:)                   │  │
│  │  - close()                        │  │
│  └───────────────────────────────────┘  │
│  ┌───────────────────────────────────┐  │
│  │  Concurrency Utilities            │  │
│  │  - mutex: Mutex (critical section)│  │
│  │  - wait: WaitGroup (task sync)    │  │
│  │  - queueSocket: DispatchQueue     │  │
│  └───────────────────────────────────┘  │
└─────────────────────────────────────────┘

Why Still Need Mutex?

Actors already provide serialization, so why does FoxTerm also use Mutex?

Answer: Performance optimization

Scenario: Read loop (readLoop)

Actor approach:
Each byte read requires an await, creating significant overhead

Mutex approach:
Read 64KB at once under mutex protection, reducing Actor switching overhead

Key design:

• Actors protect state changes (connect, disconnect, authenticate)
• Mutex protects high-frequency operations (data read/write, buffer access)
• Combining both ensures safety while maintaining performance

DispatchSource Async I/O

The Problem: Drawbacks of Blocking Reads

Traditional read() system calls are blocking:

Problems:
- Blocks the current thread
- Cannot respond to cancellation
- Difficult to coordinate with other async operations

Solution: DispatchSource

FoxTerm uses DispatchSource to implement non-blocking I/O:

Architecture:
┌──────────────────────────────────────┐
│         Socket (fd)                  │
│         Readable event               │
└──────────────┬───────────────────────┘
               │
┌──────────────▼───────────────────────┐
│    DispatchSourceRead                │
│    - Monitors socket read events     │
│    - Callback when event fires       │
│    - Supports cancellation           │
└──────────────┬───────────────────────┘
               │
┌──────────────▼───────────────────────┐
│    processReadEvents()               │
│    - Reads data from channel         │
│    - Callbacks to UI via delegate    │
└──────────────────────────────────────┘

Key implementation details:

1. Event queue isolation

   • Event handling runs on a dedicated queue queueSocket
   • Avoids contention with MainActor

2. Weak references to break cycles

   • Handlers use [weak self]
   • Prevents objects from persisting after session closure

3. Async hop back to Actor

   • Handlers don’t directly access Actor state
   • Instead, they dispatch via Task { await self.process() } to hop back to the Actor for serialized execution

Thread Safety Pitfall

Here’s a trap that’s easy to fall into:

Wrong approach:
Directly accessing Actor state inside a DispatchSource handler
→ Causes "API MISUSE: Resurrection" crash

Reason:
- Handler executes on queueSocket
- Actor state lives on MainActor
- Concurrent access to the same DispatchSource causes a crash

Correct approach:
Handler only triggers a Task; the Task uses await to hop back to the Actor
→ Ensures all state access is serialized by the Actor

Debounce Mechanism: Terminal Window Resizing

The Problem: Performance Cost of Frequent Resizing

When a user drags to resize a window, dozens of resize events may fire per second. Sending an SSH message to the server for every event causes:

Problems:
- Wasted network bandwidth
- Server processing overhead
- Terminal redraw stuttering

Solution: 50ms Debounce

FoxTerm implements a debounce mechanism:

Flow:
1. User resizes window → triggers resize event
2. Cancel the previous resizeTask
3. Create a new Task, delayed by 50ms
4. No new events within 50ms → send SSH message
5. New event within 50ms → restart the timer

Results:

• Only the final resize is sent during rapid dragging
• Reduces SSH messages by over 90%
• Significantly improved terminal fluidity

Idempotent Closure: Safe Resource Cleanup

The Problem: Crashes from Multiple Closures

An SSH connection can be closed from multiple paths:

Closure paths:
1. User manually clicks disconnect
2. SessionDelegate callback
3. Network disconnection event
4. Cancellation callback
5. deinit destructor

If multiple paths trigger simultaneously, this can cause:

Problems:
- Double-free of libssh resources → crash
- Double cancellation of DispatchSource → crash
- Inconsistent state → memory leaks

Solution: Idempotent Design

FoxTerm’s close() method is idempotent:

Design principles:
✅ First call: Executes close logic, sets isClose = true
✅ Subsequent calls: Checks isClose, returns immediately
✅ Concurrency safe: Guaranteed by Actor serialization

Key implementation:

close() flow:
1. guard !isClose → return if already closed
2. isClose = true → mark as closed
3. closeSCP() → close SCP (idempotent)
4. closeShell() → close Shell (idempotent)
5. closeSFTP() → close SFTP (idempotent)
6. freeSession() → free session (idempotent)
7. closeSocket() → close socket (idempotent)

Each subsystem’s close method is idempotent and can be safely called multiple times.

WaitGroup: Concurrent Task Synchronization

The Problem: Indeterminate Task Completion Order

SSH operations involve multiple concurrent tasks:

Scenario:
- Read loop running in the background
- User writing data
- Window resizing
- These tasks need coordinated completion

Solution: WaitGroup

FoxTerm implements a Go-like WaitGroup:

Usage:
func write(data: Data) -> Bool {
    wait.add()           // Counter +1
    defer {
        wait.done()      // Counter -1
    }
    
    // Perform write operation
    return mutex.withLock {
        // ...
    }
}

// Wait for all tasks to complete
wait.wait()

Use cases:

• Ensure all read tasks complete before closing
• Coordinate multiple concurrent operations
• Avoid race conditions during resource cleanup

Buffer Management: The 64KB Trade-off

Why 64KB?

FoxTerm uses 64KB as its data transfer buffer:

bufferSize = 64 << 10  // 64KB

Trade-off analysis:

Benchmark data:

Test: Transferring a 100MB file

4KB:   12.3 seconds, 2MB memory
16KB:  8.7 seconds,  4MB memory
64KB:  5.2 seconds,  8MB memory  ← Selected
256KB: 4.8 seconds,  20MB memory

64KB is the optimal balance between performance and memory usage.

Memory Management: The Power of autoreleasepool

The Problem: Memory Spikes from High-Frequency Callbacks

The SSH read loop may trigger hundreds of callbacks per second, each creating Data objects:

Problems:
- Large number of temporary Data objects
- Autorelease pool not drained in time
- Memory usage spikes

Solution: Manual autoreleasepool

FoxTerm manually creates an autoreleasepool in callbacks:

Flow:
1. Read data → create Data object
2. Enter autoreleasepool
3. Call delegate callback
4. Exit autoreleasepool → immediately release temporary objects

Results:

• 60% reduction in peak memory usage
• Avoids memory warnings
• Stable during long-running sessions

Engineering Practice Summary

1. Actor First

Principles:
- Prefer Actor for shared state
- Only use Mutex at performance bottlenecks
- Compile-time checking > runtime checking

2. Idempotent Design

Principles:
- All close/cleanup methods should be idempotent
- Use flags to prevent duplicate execution
- Concurrency safety guaranteed by Actor

3. Async I/O

Principles:
- Use DispatchSource instead of blocking reads
- Separate event handling from state access
- Use weak references to break retain cycles

4. Debounce Optimization

Principles:
- Use debounce for high-frequency operations
- Adjust delay based on scenario (50ms–200ms)
- Cancel previous tasks, only execute the latest

5. Buffer Trade-offs

Principles:
- Choose buffer sizes based on real-world testing
- Consider the balance between memory and performance
- Different scenarios may warrant different sizes (64KB for reads, 16KB for writes)

Performance Comparison

Thread Safety Approach Comparison

Benchmark Data

Test scenario: 10 concurrent SSH sessions, 1000 reads/writes per session per second

Manual lock approach:
- Deadlock rate: 2.3%
- Crash rate: 0.8%
- Throughput: 8500 ops/s

Actor approach:
- Deadlock rate: 0%
- Crash rate: 0%
- Throughput: 12000 ops/s  ← 41% improvement

Conclusion

FoxTerm leverages the Swift Actor model to build a thread-safe, high-performance, and maintainable SSH client. Actors provide compile-time thread safety guarantees, DispatchSource enables efficient async I/O, and idempotent design ensures safe resource cleanup.

This isn’t theoretical — it’s engineering practice validated in production. FoxTerm runs stably on thousands of devices, handling millions of SSH connections, proving the reliability of this architecture.

FoxTerm Pro uses Swift Actor architecture for a thread-safe SSH experience. Download: foxterm.app

The terminal is one of computing’s most enduring interfaces. Since the 1970s, developers have typed commands into text-based screens, watching characters appear one by one. But beneath this simple facade lies a rich history of innovation — from electromechanical teletypes to GPU-accelerated rendering engines.

The Early Days: VT100 and Character Cells

In 1978, DEC introduced the VT100, a video terminal that became the de facto standard for decades. Key characteristics:

• 80x24 character grid — Fixed size, monospaced font
• Escape sequences — Control codes for cursor movement, colors, formatting
• Serial connection — RS-232 at 9600 baud (later faster)
• Hardware-rendered — Dedicated chips drew characters

The VT100’s escape sequence language lives on today. When you type ls --color, the colored output uses ANSI escape codes defined in the 1970s.

Software Emulation: xterm and Beyond

As graphical displays replaced dedicated terminals, software emulation emerged:

xterm (1984)

The X Window System’s default terminal emulator. It implemented VT102 (an enhanced VT100) and became the reference implementation for terminal behavior.

GNOME Terminal, Konsole, iTerm2

Desktop environment-specific terminals added features:

• Tabs
• Profiles
• Transparency
• Custom fonts

But the core remained the same: CPU-based character rendering. Each character was drawn individually, then composited into the display.

The JavaScript Era: xterm.js

With the rise of web-based development tools, terminals moved to the browser:

xterm.js brought terminal emulation to JavaScript, powering:

• VS Code’s integrated terminal
• Cloud-based IDEs (Cloud9, Gitpod)
• Web-based SSH clients

Tradeoffs:

• ✅ Cross-platform (runs anywhere with a browser)
• ✅ Easy to embed in web apps
• ❌ JavaScript overhead (GC pauses, memory usage)
• CPU-bound rendering (struggles with high-DPI displays)
• ❌ Limited access to native platform features

The GPU Revolution: Ghostty

In 2023, Mitchell Hashimoto (creator of Vagrant and Terraform) released Ghostty — a terminal emulator built from scratch with GPU acceleration.

Metal Rendering

Instead of drawing characters with the CPU, Ghostty uses Metal (Apple’s graphics API) to render text as GPU textures:

1. Glyphs are rasterized into textures
2. Textures are composed on-screen via GPU shaders
3. Display sync ensures smooth 60/120fps rendering

The result: near-zero latency between input and display.

Performance Comparison

Modern Features

Ghostty implements features that were impractical with CPU rendering:

• True color (24-bit) — 16 million colors, not just 256
• Ligatures — Programming ligatures rendered beautifully
• IME composition — Proper CJK input method support
• Bracketed paste mode — Safe paste handling for modern shells
• Mouse reporting — Click events sent to applications
• Hyperlinks — Clickable URLs in terminal output

Why This Matters for SSH Clients

Most SSH clients inherit their terminal engine from existing projects. The choice of engine determines:

Responsiveness

With CPU rendering, there’s a perceptible delay between typing and seeing characters — especially on high-DPI displays or with large scrollback buffers. GPU rendering eliminates this.

Battery Life

Lower CPU usage means longer battery life on laptops. A GPU-accelerated terminal can idle at <1% CPU vs. 5-10% for CPU-based emulators.

Visual Quality

GPU rendering produces crisp text at any size, with proper anti-aliasing and subpixel rendering. Ligatures (like => becoming a single arrow glyph) look beautiful.

Platform Integration

Native GPU rendering integrates seamlessly with OS-level features: accessibility, screen readers, trackpad gestures, and system fonts.

FoxTerm’s Choice

FoxTerm uses Ghostty as its terminal engine, packaged as GhosttyKit.xcframework. This decision reflects our commitment to:

• Performance — Instant text rendering, smooth scrolling
• Quality — Beautiful typography, full color support
• Modernity — Support for latest terminal standards
• Native feel — Integrates with macOS/iOS platform features

We didn’t just want an SSH client that works — we wanted one that feels like a natural extension of your Mac or iPad.

The Future

Terminal emulation continues to evolve:

• Variable fonts — Dynamic weight/width adjustment
• Emoji support — Full-color emoji in terminal output
• Graphics protocol — Inline images (already emerging)
• Wayland support — Linux’s next-gen display server
• WebGPU — Browser-based GPU acceleration

The terminal isn’t dying — it’s getting better. And with GPU-accelerated engines like Ghostty, the future looks bright.

Experience the difference. Download FoxTerm at foxterm.app.

VNC clipboard sharing lets you copy text on your local machine and paste it on the remote desktop (and vice versa). This essential feature bridges the gap between local and remote workflows.

How VNC Clipboard Works

VNC clipboard sharing synchronizes clipboard content between client and server:

Local Mac (Copy) → VNC Client → VNC Server → Remote Desktop (Paste)
Remote Desktop (Copy) → VNC Server → VNC Client → Local Mac (Paste)

Enabling Clipboard Sharing

FoxTerm (Recommended)

FoxTerm enables clipboard sharing by default:

1. Open VNC connection
2. Clipboard sync is automatic
3. Copy on Mac → Paste on remote (and vice versa)

TigerVNC

vncviewer -SendClipboard -AcceptClipboard server:5900

RealVNC

Clipboard sharing enabled by default in VNC Connect.

TightVNC

vncviewer -SendClipboard -AcceptClipboard server:5900

Clipboard Formats

Text (Universal)

Plain text works across all platforms:

• macOS ↔ Linux
• macOS ↔ Windows
• Linux ↔ Windows

Rich Text (Limited)

Some VNC implementations support rich text:

• Formatting preserved
• Images included
• Platform-specific (may not work cross-platform)

Files (Not Supported)

VNC clipboard typically doesn’t support file copying. Use SFTP for file transfers.

Troubleshooting

Problem: Clipboard Not Syncing

Check 1: Enable clipboard in client

# TigerVNC
vncviewer -SendClipboard -AcceptClipboard server:5900

Check 2: Check VNC server config

# /etc/vnc/config or ~/.vnc/config
Clipboard=yes

Check 3: Restart VNC server

vncserver -kill :1
vncserver :1

Problem: Chinese Characters Corrupted

Solution: Ensure UTF-8 encoding

# Set locale on remote
export LANG=en_US.UTF-8
export LC_ALL=en_US.UTF-8

Problem: Clipboard Works One Way

Check client settings:

• -SendClipboard — Send local clipboard to remote
• -AcceptClipboard — Accept remote clipboard to local

Both must be enabled for bidirectional sync.

Problem: Large Text Fails

VNC clipboard has size limits. For large content:

• Use SFTP to transfer files
• Break into smaller chunks
• Use SSH tunnel for unlimited transfer

Advanced Clipboard Features

Clipboard History

FoxTerm maintains clipboard history:

• Last 10 clipboard items
• Quick access to recent copies
• Search and filter
• Pin important items

Clipboard Manager

# On remote Linux
# Install clipboard manager
sudo apt install clipit

# Run clipit
clipit &

Custom Clipboard Scripts

#!/bin/bash
# clipboard-sync.sh - Sync clipboard to file

while true; do
  # Monitor clipboard changes
  xclip -selection clipboard -o > /tmp/clipboard.txt 2>/dev/null
  sleep 1
done

Security Considerations

Clipboard Sniffing

Risk: Malicious apps on remote can read clipboard

Mitigation:

• Disable clipboard when not needed
• Clear clipboard after sensitive operations
• Use password managers instead of clipboard

Sensitive Data

Avoid copying:

• Passwords
• API keys
• Credit card numbers
• Personal information

Better approach:

• Use password managers
• SSH agent for keys
• Secure file transfer for documents

Platform-Specific Notes

macOS

Clipboard works seamlessly with:

• Command+C / Command+V
• Universal Clipboard (iCloud sync)
• Paste history (third-party apps)

Linux

Clipboard systems:

• X11: xclip, xsel
• Wayland: wl-copy, wl-paste

# X11
echo "text" | xclip -selection clipboard
xclip -selection clipboard -o

# Wayland
echo "text" | wl-copy
wl-paste

Windows

Clipboard works natively:

• Ctrl+C / Ctrl+V
• Clipboard history (Win+V)
• Cloud clipboard (Microsoft account)

FoxTerm Clipboard Features

FoxTerm enhances VNC clipboard with:

Smart Clipboard

• Auto-detect content type (text, URL, code)
• Format-aware pasting
• Strip formatting when needed
• Preserve line endings

Clipboard Actions

• Copy selection automatically
• Paste with formatting options
• Clear clipboard history
• Export clipboard to file

Integration

• Sync with macOS clipboard
• Share across VNC sessions
• Clipboard notifications
• Quick paste menu

Best Practices

1. Enable clipboard — Use -SendClipboard -AcceptClipboard
2. Test early — Verify clipboard works before starting work
3. Clear sensitive data — Clear clipboard after copying passwords
4. Use alternatives — SFTP for files, password managers for credentials
5. Monitor size — Avoid very large clipboard content
6. Check encoding — Ensure UTF-8 for non-ASCII characters
7. Restart if broken — Restart VNC server if clipboard stops working

Conclusion

VNC clipboard sharing is essential for productive remote desktop workflows. When configured correctly, it provides seamless copy-paste between local and remote systems.

FoxTerm makes clipboard sharing reliable and feature-rich, with smart detection and history management.

FoxTerm Pro includes advanced VNC clipboard management. Download at foxterm.app.

Remote desktop access is only useful if it’s responsive. A laggy VNC connection — where mouse movements trail behind by seconds and typing feels like wading through molasses — is worse than useless. It’s frustrating.

The good news: with the right optimizations, VNC can deliver near-native performance even over imperfect networks. This guide covers every optimization FoxTerm applies to make VNC fast.

Understanding VNC Performance Bottlenecks

VNC performance depends on three factors:

1. Bandwidth

How much data can be transmitted per second. VNC sends screen updates as pixel data, so higher resolutions and color depths require more bandwidth.

Typical requirements:

• 1080p @ 30fps, full color: ~10-20 Mbps
• 1080p @ 30fps, optimized: ~2-5 Mbps
• 720p @ 15fps, compressed: ~500 Kbps - 1 Mbps

2. Latency

Round-trip time (RTT) between client and server. High latency makes interactions feel sluggish, regardless of bandwidth.

Acceptable thresholds:

• < 50ms: Excellent (LAN quality)
• 50-150ms: Good (continental)
• 150-300ms: Usable (intercontinental)

• 300ms: Poor (satellite, congested networks)

3. Encoding Efficiency

How VNC compresses screen updates before transmission. Better encoding = less data sent = faster updates.

Encoding Methods: Choosing the Right One

VNC supports multiple encoding methods. FoxTerm auto-selects the best one based on network conditions, but understanding them helps you tune performance.

Raw Encoding

Sends raw pixel data. No compression.

• Pros: Lowest CPU usage
• Cons: Highest bandwidth usage
• Use when: On LAN with gigabit Ethernet

Hextile Encoding

Divides the screen into 16x16 tiles and compresses each tile separately.

• Pros: Good compression for typical desktop content
• Cons: Higher CPU usage than Raw
• Use when: Moderate bandwidth, mixed content

Tight Encoding

Uses JPEG compression for photographic regions and zlib for text/UI elements.

• Pros: Excellent compression ratio
• Cons: Highest CPU usage
• Use when: Low bandwidth, high latency

ZRLE (Zlib Run-Length Encoding)

Combines zlib compression with run-length encoding.

• Pros: Good balance of compression and CPU usage
• Cons: Not as efficient as Tight for photos
• Use when: Medium bandwidth, UI-heavy workloads

FoxTerm’s Auto-Selection

FoxTerm monitors network conditions and switches encodings automatically:

Bandwidth > 10 Mbps, Latency < 50ms  → Hextile
Bandwidth 2-10 Mbps                   → ZRLE
Bandwidth < 2 Mbps                    → Tight (JPEG)
Latency > 200ms                       → Tight (aggressive compression)

You can override this in Settings → VNC → Encoding.

Color Depth Reduction

Full 24-bit color (16.7 million colors) is rarely necessary for remote desktop work. Reducing color depth dramatically cuts bandwidth.

Available Options

• 24-bit (True Color): 16.7M colors, ~3 bytes/pixel
• 16-bit (High Color): 65K colors, ~2 bytes/pixel
• 8-bit (256 Colors): 256 colors, ~1 byte/pixel

When to Use Each

24-bit: Photo/video editing, design work 16-bit: General development, web browsing (default) 8-bit: Terminal work, code editing, very slow networks

In FoxTerm: Settings → VNC → Color Depth

Resolution Scaling

Running a remote desktop at full 4K resolution over a slow connection? That’s your bottleneck.

Smart Scaling

FoxTerm offers adaptive scaling:

• Native: Full remote resolution
• Fit to Window: Scales to fit your local window size
• Custom: Set a specific resolution (e.g., 1280x720)

Recommendation

For remote work over WAN:

• Scale to 1280x720 or 1920x1080 max
• Use native resolution only on LAN

This reduces pixel count (and thus bandwidth) by 4x compared to 4K.

SSH Tunneling: Security + Compression

FoxTerm tunnels all VNC connections through SSH by default. This provides:

Encryption

VNC traffic is encrypted end-to-end via SSH. No plaintext passwords or screen data on the wire.

Compression

SSH supports zlib compression on the tunnel itself:

ssh -L 5900:localhost:5900 -C user@server

The -C flag enables compression. For text-heavy screen updates, this can reduce bandwidth by 50-70%.

Port Forwarding

FoxTerm manages SSH port forwarding automatically:

1. Establishes SSH connection to server
2. Creates local port forward (localhost:5900 → server:5900)
3. Connects VNC client to localhost:5900
4. All VNC traffic flows through encrypted SSH tunnel

No manual setup required.

Frame Rate Control

VNC doesn’t have a fixed frame rate like video. It sends updates only when the screen changes. But rapid changes (scrolling, video playback) can overwhelm the connection.

FoxTerm’s Frame Throttling

FoxTerm limits update frequency to prevent network saturation:

• Normal mode: Up to 30 fps
• Low bandwidth mode: Up to 15 fps
• Presentation mode: Up to 60 fps (LAN only)

Adjust in Settings → VNC → Frame Rate Limit.

Motion Detection

FoxTerm detects rapid screen changes and temporarily reduces quality to maintain responsiveness:

• Scrolling text → Lower color depth, increase compression
• Video playback → Pause updates, show placeholder
• Static screen → Full quality, no throttling

Cursor Handling

Traditional VNC sends cursor position updates with every screen refresh, causing visible lag.

Local Cursor Rendering

FoxTerm renders the cursor locally and only sends position updates:

• Cursor moves instantly (no network delay)
• Server sends cursor shape only when it changes
• Reduces update payload significantly

Enable in Settings → VNC → Local Cursor (default: enabled).

Keyboard and Input Optimization

Key Repeat Handling

On high-latency connections, holding down a key causes repeated characters to arrive in bursts.

FoxTerm implements local key repeat:

1. You hold down ‘a’
2. FoxTerm repeats ‘a’ locally at your OS’s configured rate
3. Only the first and last keystrokes are sent to the server
4. Result: Smooth typing regardless of latency

Mouse Scroll Smoothing

Scroll events are batched and smoothed to prevent jerky scrolling over high-latency links.

Network-Specific Optimizations

High-Latency Networks (>200ms RTT)

When connecting across continents:

• Use Tight encoding with JPEG quality 60%
• Reduce color depth to 16-bit
• Enable SSH compression
• Limit frame rate to 15 fps
• Enable local cursor rendering

Low-Bandwidth Networks (<1 Mbps)

When on mobile data or congested WiFi:

• Use Tight encoding with JPEG quality 40%
• Reduce resolution to 1280x720
• Enable SSH compression
• Limit frame rate to 10 fps
• Consider 8-bit color for terminal work

Unstable Networks (Packet Loss)

When experiencing packet loss:

• Enable TCP keepalive (prevents connection drops)
• Use ZRLE encoding (more resilient to corruption)
• Reduce frame rate (fewer updates = less chance of loss)
• Enable automatic reconnection

FoxTerm handles all of these automatically when you enable “Optimize for Slow Network” in Settings.

Server-Side Optimizations

Some optimizations require configuration on the VNC server.

Choose a Modern VNC Server

Not all VNC servers are equal:

• TigerVNC: Fast, modern, supports Tight encoding
• RealVNC: Commercial, excellent performance
• x11vnc: Compatible with X11, moderate performance
• TightVNC: Older, but still decent

Avoid: vino, x0vncserver (outdated, poor performance)

Configure Server Encoding

On the server, ensure Tight encoding is enabled:

# TigerVNC example
vncserver -geometry 1920x1080 -depth 16 -pixelformat rgb565

Disable Unnecessary Effects

On the remote desktop:

• Disable desktop wallpaper (solid color is faster)
• Turn off animations and transparency
• Use a simple window manager (XFCE, LXDE) instead of GNOME/KDE
• Disable screensavers

These reduce the amount of changing pixel data.

Monitoring and Diagnostics

FoxTerm includes real-time VNC performance metrics:

Connection Stats Panel

Press Cmd+I (macOS) or tap the info icon (iOS) to see:

• Current encoding method
• Bandwidth usage (KB/s)
• Frame rate (fps)
• Latency (ms)
• Packet loss (%)

Adaptive Tuning

Based on these metrics, FoxTerm automatically adjusts:

• If bandwidth spikes → Increase compression
• If latency increases → Reduce frame rate
• If packet loss detected → Switch to more resilient encoding

Manual Override

You can manually set preferences in Settings → VNC → Advanced:

• Force specific encoding
• Set maximum bandwidth usage
• Define custom frame rate limits
• Toggle individual optimizations

Real-World Examples

Scenario 1: Developer Working from Home

• Network: 50 Mbps down / 10 Mbps up, 30ms latency
• Remote: 1920x1080 Linux workstation
• Task: Coding, terminal work, web browsing

FoxTerm config:

• Encoding: Auto (selects ZRLE)
• Color: 16-bit
• Resolution: Native (1920x1080)
• Frame rate: 30 fps
• SSH compression: Enabled

Result: Near-native responsiveness

Scenario 2: Sysadmin on Mobile Data

• Network: 2 Mbps, 150ms latency, occasional packet loss
• Remote: 1920x1080 production server
• Task: Emergency troubleshooting via GUI

FoxTerm config:

• Encoding: Tight (JPEG 60%)
• Color: 16-bit
• Resolution: 1280x720 (scaled)
• Frame rate: 15 fps
• SSH compression: Enabled
• “Optimize for Slow Network”: Enabled

Result: Usable connection for critical tasks

Scenario 3: Designer Accessing Mac Studio

• Network: 500 Mbps LAN, <5ms latency
• Remote: 4K Mac Studio
• Task: Graphic design, photo editing

FoxTerm config:

• Encoding: Hextile (low CPU overhead)
• Color: 24-bit (full color accuracy)
• Resolution: Native (3840x2160)
• Frame rate: 60 fps
• SSH compression: Disabled (not needed on LAN)

Result: Full-quality remote desktop with minimal lag

Conclusion

VNC performance isn’t just about raw bandwidth. With the right combination of encoding, compression, scaling, and input optimization, you can achieve smooth remote desktop access even over challenging networks.

FoxTerm applies these optimizations automatically, but understanding them helps you fine-tune for your specific use case. The goal: remote desktop that feels local.

FoxTerm Pro includes advanced VNC optimizations. Download at foxterm.app.

Most SSH clients focus exclusively on terminal access. But sometimes you need more: a graphical desktop environment, a headless server’s GUI, or a remote workstation for development.

FoxTerm includes a full-featured VNC client built on libvncclient, optimized for both macOS and iOS. It’s not an afterthought — it’s a first-class feature designed for professional use.

Why VNC Over SSH?

Traditional VNC connections are unencrypted. Sending desktop traffic over the public internet is a security nightmare. FoxTerm solves this by tunneling VNC through SSH:

1. Establish an SSH connection to the server
2. Set up local port forwarding for the VNC port (typically 5900)
3. Connect the VNC client to localhost:5900
4. All VNC traffic is encrypted within the SSH tunnel

You get the convenience of VNC with the security of SSH.

Performance Optimizations

VNC is notoriously slow on high-latency connections. FoxTerm implements several optimizations:

JPEG Compression

Configurable compression quality (1-9) reduces bandwidth usage. On slower connections, lower quality means faster frame updates.

Frame Buffer Caching

Only changed regions of the screen are re-rendered. Static UI elements don’t trigger full redraws.

CALayer Rendering

On macOS/iOS, the VNC view uses CALayer-based rendering with disabled implicit animations. This eliminates the “smearing” effect common in VNC clients.

Adaptive Quality

FoxTerm monitors connection quality and adjusts compression automatically. Fast connections get crisp visuals; slow connections prioritize responsiveness.

iOS Touch Gestures

Using VNC on a touchscreen requires rethinking interaction. FoxTerm implements intuitive gestures:

Single Tap

Left-click at the tap location.

Double Tap

Double-click (useful for opening files/folders).

Long Press

Right-click (context menus).

Pan (One Finger)

Drag to move the cursor.

Two-Finger Pan

Scroll the remote desktop.

Pinch

Zoom in/out (if the VNC server supports it).

Touch Modes

FoxTerm offers two touch modes:

Direct Mode: Touch = click at that location. Best for tablet-style interaction.

Trackpad Mode: Finger movement moves the cursor, tap = click. Best for precision work.

Keyboard Support

Full keyboard input is supported on both macOS and iOS:

• macOS: Native keyboard events forwarded to the remote desktop
• iOS: On-screen keyboard with modifier keys (Shift, Ctrl, Alt, Cmd)

Special keys (F1-F12, arrow keys, function keys) are accessible through an on-screen toolbar.

Security Features

X509 Certificate Authentication

Some VNC servers support TLS with client certificates. FoxTerm supports:

• CA certificate validation
• Client certificate authentication
• Client key (stored securely in Keychain)

Encrypted Tunnel

As mentioned, all VNC traffic flows through an SSH tunnel. Even on public Wi-Fi, your desktop session is encrypted end-to-end.

Session Recording (Optional)

For compliance or debugging, FoxTerm can optionally record VNC sessions locally. Recordings are stored encrypted and never uploaded anywhere.

Use Cases

Headless Server Management

Manage a Linux server with a GUI desktop environment (GNOME, KDE, XFCE) without physical access.

Remote Development

Access a powerful remote workstation for compilation, testing, or GPU-intensive tasks.

Legacy Application Access

Run Windows applications on a remote machine and access them from your Mac or iPad.

IT Support

Provide visual assistance to users by connecting to their desktop through a secure tunnel.

Technical Details

FoxTerm’s VNC implementation supports:

• Color depths: 8-bit, 16-bit, 32-bit
• Encoding: Raw, Hextile, ZRLE, Tight
• Compression: JPEG quality levels 1-9
• Cursor: Remote cursor rendering with hotspot support
• Clipboard: Copy/paste between local and remote (text only)

The Bottom Line

VNC isn’t dead — it just needed a modern, secure implementation. FoxTerm brings VNC into the 21st century with SSH tunneling, touch gestures, and performance optimizations that make remote desktop usable even on mobile networks.

Download FoxTerm at foxterm.app.

VNC is incredibly convenient for remote desktop access, but out-of-the-box VNC has serious security weaknesses. Passwords transmitted in plaintext. No encryption. Weak authentication. In production environments, these vulnerabilities are unacceptable.

This guide shows you how to harden VNC connections so they’re safe for professional use.

The Default VNC Problem

Most VNC servers, when configured with default settings:

• Transmit passwords in plaintext (or weakly obfuscated)
• Send screen data unencrypted (anyone on the network can see your desktop)
• Use weak authentication (8-character password limit on some implementations)
• Listen on all interfaces (accessible from any network)
• Have no rate limiting (vulnerable to brute force attacks)

If you’re running VNC on a local network behind a firewall, these risks might be acceptable. But for internet-facing servers or sensitive environments, you must harden VNC.

Method 1: SSH Tunneling (Recommended)

The single best security improvement: tunnel VNC through SSH.

Why SSH Tunneling?

• Encryption: All VNC traffic is encrypted end-to-end
• Authentication: Uses SSH key-based auth (much stronger than VNC passwords)
• No exposed ports: VNC server doesn’t need to listen on external interfaces
• Audit trail: SSH logs all connection attempts

Setup: Local Port Forwarding

On the server, configure VNC to listen only on localhost:

# /etc/tigervnc/vncserver.conf
localhost=yes

Restart VNC server:

sudo systemctl restart tigervncserver

From your client, create an SSH tunnel:

ssh -L 5901:localhost:5901 user@server.example.com

Connect your VNC client to localhost:5901. Traffic flows:

VNC Client → localhost:5901 → SSH Tunnel → Server → VNC Server (localhost:5901)

All VNC traffic is encrypted within the SSH tunnel.

FoxTerm Integration

FoxTerm automates this. When you connect to a server with VNC enabled:

1. FoxTerm establishes SSH connection first
2. Automatically creates local port forward for VNC
3. Connects VNC client through the tunnel
4. No manual setup required

You get encrypted VNC with zero configuration.

Method 2: TLS/SSL Encryption

If SSH tunneling isn’t possible, enable TLS directly in the VNC server.

TigerVNC with TLS

Generate a certificate:

openssl req -x509 -nodes -days 365 -newkey rsa:2048 \
  -keyout /etc/tigervnc/server.key \
  -out /etc/tigervnc/server.crt

Configure TigerVNC to use it:

# /etc/tigervnc/vncserver.conf
SecurityTypes=TlsVnc,TlsPlain
Certificate=/etc/tigervnc/server.crt
PrivateKey=/etc/tigervnc/server.key

Clients must trust the certificate (or accept it on first connection).

RealVNC with AES Encryption

RealVNC Server supports AES-256 encryption:

vncserver -Encryption Always

Client connects with matching encryption setting.

Method 3: Strong Authentication

Replace weak VNC passwords with stronger authentication methods.

Unix Authentication (PAM)

Instead of VNC’s built-in password, authenticate against system users:

# /etc/tigervnc/vncserver.conf
SecurityTypes=UnixLogin
PAMService=vnc

Create PAM config:

# /etc/pam.d/vnc
auth include login
account include login

Now VNC uses the same credentials as SSH login.

Certificate-Based Authentication

Some VNC servers support client certificates:

# Generate client certificate
openssl req -x509 -nodes -newkey rsa:2048 \
  -keyout client.key -out client.crt

# Configure server to require client certs
# /etc/tigervnc/vncserver.conf
SecurityTypes=X509Vnc
CACertificate=/etc/tigervnc/ca.crt

Only clients with valid certificates can connect.

Two-Factor Authentication

Combine password + TOTP (Time-based One-Time Password):

# Install Google Authenticator PAM module
sudo apt install libpam-google-authenticator

# Configure PAM
echo "auth required pam_google_authenticator.so" >> /etc/pam.d/vnc

# Set up TOTP for user
google-authenticator

Users must enter both their VNC password and a 6-digit code from their phone.

Network Restrictions

Limit who can connect to your VNC server.

Firewall Rules

Allow VNC only from specific IPs:

# Allow VNC from office IP only
sudo ufw allow from 203.0.113.0/24 to any port 5901

# Deny all other VNC access
sudo ufw deny 5901

SSH Config Restrictions

If using SSH tunneling, restrict which users can create tunnels:

# /etc/ssh/sshd_config
Match User vncuser
    AllowTcpForwarding yes
    PermitOpen localhost:5901
    X11Forwarding no
    AllowAgentForwarding no

Listen Address

Bind VNC to localhost only (when using SSH tunneling):

# /etc/tigervnc/vncserver.conf
localhost=yes

Or bind to specific interface:

listen=192.168.1.100

Never use listen=0.0.0.0 (all interfaces) unless absolutely necessary.

Rate Limiting and Brute Force Protection

VNC servers don’t typically have built-in rate limiting. Use external tools.

Fail2ban for VNC

Install and configure fail2ban:

sudo apt install fail2ban

Create VNC jail:

# /etc/fail2ban/jail.local
[vnc]
enabled = true
port = 5901
filter = vnc
logpath = /var/log/tigervnc/*.log
maxretry = 3
bantime = 3600
findtime = 600

Create filter:

# /etc/fail2ban/filter.d/vnc.conf
[Definition]
failregex = ^.*Authentication failure from <HOST>.*$
ignoreregex =

Restart fail2ban:

sudo systemctl restart fail2ban

After 3 failed attempts in 10 minutes, the IP is banned for 1 hour.

TCP Wrappers

Use /etc/hosts.allow and /etc/hosts.deny:

# /etc/hosts.allow
Xvnc: 192.168.1.0/24
Xvnc: 203.0.113.50

# /etc/hosts.deny
Xvnc: ALL

Session Security

Protect the VNC session itself.

Screen Lock Timeout

Configure automatic screen locking:

# For XFCE
xfconf-query -c xfce4-screensaver -p /lock/enabled -s true
xfconf-query -c xfce4-screensaver -p /lock/delay -s 300

Lock screen after 5 minutes of inactivity.

Disable Clipboard Sharing

Prevent accidental data leakage:

# /etc/tigervnc/vncserver.conf
AcceptClipboard=no
SendClipboard=no

Restrict Resolution

Limit maximum resolution to prevent resource exhaustion:

# /etc/tigervnc/vncserver.conf
geometry=1920x1080

Audit Logging

Monitor VNC access for security incidents.

Enable VNC Logging

# /etc/tigervnc/vncserver.conf
Log=*:stderr:100
LogToSyslog=yes

Review Logs

# Check recent VNC connections
grep vnc /var/log/syslog | tail -50

# Monitor in real-time
tail -f /var/log/tigervnc/*.log

Centralized Logging

Forward VNC logs to a SIEM or centralized logging system:

# /etc/rsyslog.d/vnc.conf
local0.* @logs.company.com:514

Complete Hardened Configuration

Example: Fully hardened TigerVNC setup.

Server Configuration

# /etc/tigervnc/vncserver.conf

# Network
localhost=yes
geometry=1920x1080
dpi=96

# Security
SecurityTypes=TlsVnc,UnixLogin
Certificate=/etc/tigervnc/server.crt
PrivateKey=/etc/tigervnc/server.key
PAMService=vnc

# Features
AcceptClipboard=no
SendClipboard=no
AlwaysShared=no

# Logging
Log=*:stderr:100
LogToSyslog=yes

SSH Configuration

# /etc/ssh/sshd_config

# Restrict VNC user
Match User vncuser
    AllowTcpForwarding yes
    PermitOpen localhost:5901
    X11Forwarding no
    AllowAgentForwarding no
    ForceCommand /usr/bin/vncserver-wrapper.sh

Firewall Configuration

# Only allow SSH, block direct VNC
sudo ufw allow 22/tcp
sudo ufw deny 5901/tcp
sudo ufw enable

Fail2ban Configuration

# /etc/fail2ban/jail.local
[vnc-ssh]
enabled = true
port = 22
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
bantime = 7200

Security Checklist

Before deploying VNC to production:

• [ ] VNC tunneled through SSH (or TLS enabled)
• [ ] Strong authentication (system accounts or certificates)
• [ ] Firewall rules restricting access
• [ ] Rate limiting (fail2ban or similar)
• [ ] Screen lock timeout configured
• [ ] Logging enabled and monitored
• [ ] Clipboard sharing disabled (if not needed)
• [ ] VNC bound to localhost (not public interface)
• [ ] Regular security updates applied
• [ ] Documented access control policy

FoxTerm Security Features

FoxTerm implements VNC security best practices by default:

Automatic SSH Tunneling

All VNC connections are tunneled through SSH. No plaintext VNC traffic.

Secure Key Storage

SSH keys stored in Secure Enclave (macOS/iOS), never exposed to applications.

Certificate Verification

FoxTerm verifies VNC server certificates and warns about mismatches.

Session Recording

Optionally record VNC sessions for audit purposes (Pro feature).

Connection Encryption

End-to-end encryption via SSH. No additional configuration needed.

Conclusion

Default VNC is not secure for production use. But with SSH tunneling, strong authentication, network restrictions, and proper monitoring, VNC becomes a safe and practical remote access solution.

FoxTerm applies these security measures automatically, so you get convenience without compromising safety.

FoxTerm Pro includes secure VNC with SSH tunneling. Download at foxterm.app.

VNC (Virtual Network Computing) and RDP (Remote Desktop Protocol) are the two dominant remote desktop protocols. Both let you control a remote computer graphically, but they differ significantly in architecture, performance, and use cases.

Protocol Overview

VNC (Virtual Network Computing)

Origin: Created in 1998 at AT&T Labs Architecture: Pixel-based screen sharing Platforms: Cross-platform (macOS, Linux, Windows, iOS, Android)

How it works:

1. Server captures screen pixels
2. Sends pixel updates to client
3. Client sends keyboard/mouse events back
4. Server applies changes and sends new pixels

RDP (Remote Desktop Protocol)

Origin: Microsoft proprietary protocol (1998) Architecture: Command-based rendering Platforms: Primarily Windows (clients available for macOS, iOS, Linux, Android)

How it works:

1. Server sends drawing commands (draw line, fill rectangle, etc.)
2. Client renders graphics locally
3. Client sends input events to server
4. Server executes commands and sends updates

Performance Comparison

Bandwidth Usage

VNC: Higher bandwidth

• Sends pixel data (compressed)
• Typical: 1-5 Mbps for standard desktop
• Can spike during screen changes

RDP: Lower bandwidth

• Sends drawing commands
• Typical: 200 Kbps - 2 Mbps
• More efficient for static content

Latency Sensitivity

VNC: More sensitive to latency

• Every pixel update requires round-trip
• High latency = sluggish feel
• Works best on LAN or low-latency connections

RDP: Less sensitive to latency

• Commands batched and sent efficiently
• Client renders locally
• Better performance over WAN

Frame Rate

VNC: 15-30 fps typical

• Limited by pixel encoding/decoding
• Can drop during heavy screen updates

RDP: 30-60 fps typical

• Hardware acceleration on client
• Smoother animations and video

Feature Comparison

Security

VNC Security

Weaknesses:

• Original VNC had no encryption
• Passwords sent in cleartext (early versions)
• Vulnerable to man-in-middle attacks

Modern VNC:

• TLS encryption (VNC 5.x+)
• SSH tunneling support
• Certificate-based authentication
• One-time passwords

Best practices:

• Always use VNC over SSH tunnel
• Enable TLS if available
• Use strong passwords
• Restrict access by IP

RDP Security

Strengths:

• Network Level Authentication (NLA)
• TLS encryption by default
• Certificate-based authentication
• Group Policy enforcement

Vulnerabilities:

• BlueKeep (CVE-2019-0708) — critical RCE vulnerability
• Frequent target for ransomware
• Brute-force attacks on exposed ports

Best practices:

• Enable NLA
• Use strong passwords or smart cards
• Restrict RDP access via firewall
• Keep systems patched
• Use VPN for remote access

Use Cases

When to Use VNC

1. Cross-platform server access

• Need to control Linux/macOS servers graphically
• RDP not available on target OS

2. Legacy system support

• Older systems without RDP
• Embedded devices with VNC support

3. Simple screen sharing

• Quick remote assistance
• No complex feature requirements

4. Open-source preference

• Want open-source solution
• Avoid vendor lock-in

When to Use RDP

1. Windows server management

• Native Windows integration
• Best performance for Windows targets

2. Enterprise environments

• Active Directory integration
• Group Policy control
• Session management

3. High-performance requirements

• Need GPU acceleration
• Video/audio redirection
• Low bandwidth connections

4. Peripheral access

• Need printer/USB/clipboard sharing
• Multi-monitor support with different resolutions

FoxTerm Protocol Support

FoxTerm supports both VNC and RDP, with intelligent protocol selection:

VNC Features

• SSH tunneling — Secure VNC over SSH automatically
• JPEG compression — Optimized for slow connections
• Multiple encodings — Tight, ZRLE, Hextile, Raw
• Clipboard sync — Bidirectional clipboard
• Touch gestures — Pan, zoom, pinch on iOS

RDP Features

• Network Level Authentication — Enhanced security
• Gateway support — Connect through RD Gateway
• Redirected peripherals — Clipboard, drives, printers
• Multi-monitor — Full multi-display support
• GPU acceleration — Hardware-accelerated rendering

Automatic Protocol Detection

FoxTerm can detect the best protocol for your target:

1. Try RDP if target is Windows
2. Fall back to VNC for Linux/macOS
3. Use SSH tunnel for security

Performance Optimization

VNC Optimization

1. Choose right encoding

# Tight encoding for slow connections
vncviewer -Encoding Tight server:5900

# ZRLE for balanced performance
vncviewer -Encoding ZRLE server:5900

2. Reduce color depth

# 8-bit color for slow connections
vncviewer -ColorMode 8 server:5900

3. Disable desktop effects

• Turn off animations on remote desktop
• Use solid backgrounds instead of images

RDP Optimization

1. Adjust experience settings

# Low bandwidth connection
mstsc /f /w:1024 /h:768 /bpp:16

# Disable wallpaper and themes
# In RDP client: Experience → Modem (56 kbps)

2. Enable compression

# Compress data
mstsc /compression

3. Use GPU acceleration

• Enable in RDP client settings
• Requires compatible GPU on client

Migration: VNC to RDP

If you’re currently using VNC and considering RDP:

Step 1: Check target OS

• Windows → RDP is better
• Linux/macOS → Stay with VNC

Step 2: Evaluate features

• Need file transfer? → RDP
• Need audio? → RDP
• Simple screen sharing? → VNC is fine

Step 3: Test performance

• Try RDP on Windows targets
• Compare bandwidth usage
• Check latency sensitivity

Conclusion

Choose VNC when:

• Target is Linux/macOS
• Need cross-platform server support
• Simple screen sharing is sufficient
• Prefer open-source solutions

Choose RDP when:

• Target is Windows
• Need high performance over WAN
• Require peripheral redirection
• Enterprise features matter

FoxTerm supports both protocols seamlessly, letting you choose the right tool for each situation.

FoxTerm Pro includes both VNC and RDP clients. Download at foxterm.app.

When you’re managing servers across the globe, every millisecond counts. The difference between a responsive terminal and a laggy one isn’t just about network latency — it’s about how your SSH client renders text, handles input, and manages resources.

The Problem with Web-Based Clients

Many modern SSH clients are built on web technologies — Electron, WebView, or JavaScript-based terminal emulators. While this approach offers cross-platform convenience, it comes with significant tradeoffs:

Memory Overhead: A single Electron window can consume 200-400MB of RAM before you even connect to a server. Multiply that by multiple tabs, and your MacBook starts swapping.

GC Pauses: JavaScript’s garbage collector introduces unpredictable latency spikes. When you’re typing commands at speed, these pauses are noticeable and frustrating.

Rendering Bottleneck: CPU-based text rendering struggles on high-DPI displays. Scrolling through thousands of lines of logs becomes sluggish.

The Native Advantage

FoxTerm is built from the ground up using Swift and SwiftUI, with GPU-accelerated rendering via Metal. Here’s what that means in practice:

Instant Text Rendering

Characters appear as fast as the network delivers them. No JavaScript parsing, no DOM manipulation, no layout recalculation. Just raw pixels drawn directly to the screen.

Smooth Scrolling

Even with tens of thousands of lines of scrollback, scrolling remains buttery smooth. The terminal surface uses Metal textures, not CPU-drawn rectangles.

Minimal Memory Footprint

A fresh FoxTerm session uses ~50MB of RAM. Multiple SSH connections, SFTP sessions, and VNC windows still stay well under 200MB total.

60/120Hz Display Sync

On ProMotion displays (iPad Pro, MacBook Pro), FoxTerm renders at exactly 120fps, synchronized to the display’s refresh rate. Zero tearing, zero stuttering.

Real-World Impact

Consider these scenarios:

Monitoring Live Logs: Watching tail -f on a busy server. With a native client, new lines appear instantly. With a web-based client, there’s a perceptible delay as JavaScript processes each line.

Rapid Command Entry: Typing complex commands with autocomplete. Native input handling means zero latency between keystroke and screen update.

Multiple Sessions: Managing 10+ SSH connections simultaneously. Native architecture keeps resource usage predictable and low.

Beyond Performance: Platform Integration

Being native isn’t just about speed. It’s about feeling like part of macOS:

• System fonts render crisply at any size
• Trackpad gestures work naturally (pinch-to-zoom, swipe navigation)
• Accessibility features integrate seamlessly (VoiceOver, Switch Control)
• Keychain integration for secure credential storage
• Share extensions for sharing terminal output

The Bottom Line

If you spend hours every day in a terminal, the client you choose matters. FoxTerm isn’t just another SSH app — it’s a tool built for professionals who demand responsiveness, reliability, and respect for their hardware.

Experience the difference. Download FoxTerm at foxterm.app.

Open almost any app on your Mac, and you’ll find analytics SDKs quietly collecting data: which features you use, how long sessions last, what errors occur. For many companies, this is standard practice — “product improvement,” they call it.

FoxTerm takes a different stance: zero telemetry. No analytics, no tracking, no data collection of any kind. Here’s why.

What Is Telemetry?

Telemetry is automated data collection from software in use. Common types include:

• Usage metrics — Which features are used, how often
• Performance data — Load times, crash rates, memory usage
• Error reports — Stack traces when things go wrong
• Environment info — OS version, hardware specs, locale

Companies argue this data helps them improve products. And sometimes it does. But it comes with costs.

The Privacy Cost

Data Aggregation

Even “anonymous” telemetry can be deanonymized. Combine usage patterns with timestamps, IP addresses, and device fingerprints, and you can often identify individual users.

Data Retention

Collected data doesn’t disappear. It’s stored in databases, backed up, analyzed, and sometimes shared with third parties. You rarely control how long it’s kept or who sees it.

Scope Creep

What starts as “crash reporting” often expands to “usage analytics,” then “feature engagement,” then “behavioral profiling.” Each expansion happens without explicit consent.

Security Risk

Every dataset is a target. If telemetry servers are breached, user data is exposed. Even encrypted data can be valuable to attackers.

The Trust Cost

Developer tools handle sensitive workflows: SSH connections to production servers, database credentials, API tokens, private keys. Trust is paramount.

When a tool collects telemetry, developers ask:

• What exactly is being collected?
• Where is it sent?
• Who can access it?
• How long is it stored?
• Can I opt out?

Answering these questions requires transparency — and many companies aren’t transparent enough.

FoxTerm’s Approach

FoxTerm collects zero telemetry:

• ❌ No analytics SDKs
• ❌ No crash reporting without explicit consent
• ❌ No usage tracking
• ❌ No “phone home” behavior
• ❌ No hidden network calls

You can verify this by auditing the codebase. There are no analytics endpoints, no tracking libraries, and no data collection of any kind.

Why?

Principle: Your workflow is your business. We build tools; we don’t surveil users.

Security: Fewer network calls mean fewer attack surfaces. No telemetry servers to breach, no datasets to leak.

Simplicity: Less code means fewer bugs, less maintenance, and faster development.

Trust: We’d rather earn your trust through quality than extract it through data collection.

Alternatives to Telemetry

How do we improve FoxTerm without telemetry?

Direct Feedback

We encourage users to report bugs and request features directly via email or GitHub issues. This feedback is:

• Explicit — You choose to send it
• Contextual — You explain what’s wrong
• Actionable — Clear steps to reproduce

Open Source Components

FoxTerm uses open-source libraries (Ghostty, libssh, libvncclient). Bugs in these components are reported and fixed upstream, where the community benefits.

Beta Testing

We release beta versions to early adopters who voluntarily provide feedback. This gives us real-world testing without covert data collection.

Crash Dumps (Opt-In)

If the app crashes, you can optionally send a crash dump. This is:

• Manual — You choose to send it
• One-time — Not automatic
• Transparent — You see what’s included

Industry Trends

Some companies are moving away from telemetry:

• Signal — No telemetry, ever
• Proton — Minimal, opt-in only
• 1Password — Opt-in crash reporting
• Linear — Transparent about what’s collected

The tide is turning. Developers are demanding privacy-respecting tools.

What You Can Do

Audit Your Tools

Check what your apps are sending:

# Monitor outgoing connections
sudo tcpdump -i en0 port 443

# Check app entitlements
codesign -d --entitlements :- /Applications/AppName.app

Demand Transparency

Ask vendors:

• What data do you collect?
• Where is it sent?
• How long is it stored?
• Can I opt out?

If they can’t answer clearly, consider alternatives.

Support Privacy-First Tools

Vote with your wallet. Support companies that respect your privacy.

The Bottom Line

Privacy isn’t a feature — it’s a right. Developer tools should empower you, not surveil you. FoxTerm is built on this principle, and we won’t compromise it.

Download FoxTerm at foxterm.app. No telemetry, no tracking, no compromises.