Bastion Host vs Jump Host: Key Architectural Differences in Secure Remote Access Systems


1 views

While often used interchangeably in casual discussions, bastion hosts and jump servers serve distinct architectural purposes in secure network design:

  • Bastion Host: A hardened server exposed to public networks that acts as the single entry point to private subnets (e.g., AWS EC2 instances with security groups allowing only SSH from bastion)
  • Jump Host: An intermediary server that facilitates connections between security zones, typically within internal networks
Criteria Bastion Host Jump Host
Network Position DMZ or edge network Internal segmentation zones
Authentication Multi-factor + IAM integration Often standard SSH keys
Logging Level Full session recording Basic connection logging

Here's a Terraform snippet for AWS bastion host configuration:

resource "aws_instance" "bastion" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t2.micro"
  subnet_id     = aws_subnet.public.id
  vpc_security_group_ids = [aws_security_group.bastion.id]
  
  tags = {
    Name = "prod-bastion-host"
  }
}

resource "aws_security_group" "bastion" {
  name_prefix = "bastion-sg-"
  vpc_id      = aws_vpc.main.id

  ingress {
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["10.0.0.0/16"]
  }
}

For jump host setups, here's a typical ~/.ssh/config entry:

Host internal-server
  HostName 10.10.1.5
  ProxyJump jumpuser@jump-host.example.com
  IdentityFile ~/.ssh/internal_key
  User appadmin
  • Bastions: Implement session timeouts, require VPN pre-authentication, and rotate credentials hourly
  • Jump hosts: Use network-level segmentation (e.g., VPC peering with least-privilege rules) and enforce SSH certificate authority

Major cloud platforms handle these concepts differently:

  • AWS: Session Manager (SSM) can replace traditional bastions
  • Azure: Just-in-Time VM access with Azure Bastion service
  • GCP: IAP TCP forwarding as jump host alternative

In secure network architectures, both bastion hosts and jump servers serve as controlled entry points, but their implementations differ significantly. A bastion host is a hardened server specifically designed to withstand attacks, typically exposed to untrusted networks (like the internet) with minimal services running. In contrast, a jump server (or jump host) is any intermediary system used to access other devices in a secure zone.

The key technical differences become apparent when examining their configurations:

# Bastion Host SSH Configuration (hardened)
PermitRootLogin no
PasswordAuthentication no
AllowUsers admin
Protocol 2
MaxAuthTries 3
# Typical Jump Server SSH Configuration
PermitRootLogin prohibit-password
PasswordAuthentication yes
AllowGroups ssh-users

Bastion hosts often implement multi-factor authentication and extensive logging:

// AWS Bastion Host IAM Policy Example
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:DescribeInstances",
        "ssm:StartSession"
      ],
      "Resource": "*"
    }
  ]
}

Jump servers frequently employ privilege access management solutions:

# Ansible playbook for jump host setup
- name: Configure jump host access
  hosts: jump_servers
  tasks:
    - name: Install session recording
      apt:
        name: tlog
        state: present
    - name: Configure audit rules
      copy:
        src: /etc/audit/rules.d/jump-audit.rules
        dest: /etc/audit/rules.d/

Bastion hosts are ideal for:

  • Internet-facing access points
  • High-security environments requiring strict compliance
  • Scenarios where all access must be logged and monitored

Jump servers work better for:

  • Internal network segmentation
  • Temporary access requirements
  • Environments where flexibility outweighs security needs

Both solutions often suffer from:

# Bad practice - overly permissive bastion host
# in security groups
{
  "IpProtocol": "tcp",
  "FromPort": 22,
  "ToPort": 22,
  "IpRanges": [{"CidrIp": "0.0.0.0/0"}]
}

Instead, implement CIDR restrictions and use VPC endpoints where possible.

Newer approaches like AWS Systems Manager Session Manager eliminate the need for traditional bastion hosts:

# SSM Session Manager CLI command
aws ssm start-session \
--target i-0123456789abcdef \
--document-name AWS-StartSSHSession \
--parameters portNumber=22