Preventing Remote Lockouts with Ubuntu Netplan

The Danger of the 'Apply' Command

Configuring a remote Ubuntu server's network settings is a high-stakes task. A single typo in a static IP address, a misplaced subnet mask, or a YAML indentation error can instantly sever your SSH connection. Once the network interface drops, you lose access to the machine, often requiring a physical console or a cloud provider's emergency recovery terminal to fix the mistake.

The solution is to stop using netplan apply as your primary deployment command and instead leverage the netplan try workflow. This creates a safety window that automatically reverts changes if you are locked out.

How Netplan Abstraction Works

Netplan is not a network manager itself; it is a configuration abstraction layer. It allows you to write your network intent in a human-readable YAML format, which Netplan then "renders" into the specific configuration files required by the actual backend.

Ubuntu typically uses two renderers:

• systemd-networkd: The default for Ubuntu Server, optimized for headless environments and boot-time networking.
• NetworkManager: The default for Ubuntu Desktop, designed for dynamic environments like Wi-Fi switching.

Because Netplan handles the translation, you can switch renderers or manage complex setups like VLANs and bridges without learning the intricate, low-level syntax of the underlying backend.

Safe Configuration Workflow

Network configurations are stored in /etc/netplan/ as .yaml files. Because YAML relies on strict indentation (spaces, not tabs), the risk of syntax errors is high.

The 'Try' Mechanism

When you run netplan try, the system applies the configuration but starts a countdown timer (default is 120 seconds). If you do not confirm the changes by pressing Enter before the timer expires, Netplan automatically rolls back the configuration to the previous working state. This is the primary defense against remote lockout.

Worked Example: Assigning a Static IP

To change a dynamic DHCP interface to a static IP on Ubuntu Server (assuming systemd-networkd), follow these steps. You will need sudo permissions to modify files in /etc/netplan/.

1. Identify your interface name:
Run ip link to find your interface (e.g., enp0s3).

2. Edit the configuration:
Open the YAML file (e.g., sudo nano /etc/netplan/01-netcfg.yaml) and use the following structure:

network:
  version: 2
  renderer: networkd
  ethernets:
    enp0s3:
      dhcp4: no
      addresses:
        - 192.168.1.50/24
      routes:
        - to: default
          via: 192.168.1.1
      nameservers:
        addresses: [8.8.8.8, 8.8.4.4]

3. Test and Apply:
Run the following command on the server terminal:

sudo netplan try

4. Verification:
If your SSH session remains active, press Enter to accept the changes. If the session freezes, wait two minutes; Netplan will revert the IP to the previous setting, and you will regain access.

Limitations and Risks

While netplan try is powerful, it has limitations. If you are making changes to the physical hardware state or complex routing tables that affect the gateway's ability to see the server, the rollback may still fail if the kernel cannot re-initialize the interface quickly enough.

Additionally, Netplan does not validate the reachability of your settings—only the syntax and the timeout. If you provide a syntactically correct IP that is simply wrong for your subnet, the command will succeed, but you will still lose connectivity. The rollback only triggers because you cannot provide the confirmation signal.

Verification Checklist

After applying changes, verify the state using these methods:

• Check active config: Run netplan get to see the current rendered configuration.
• Verify IP assignment: Run ip addr show [interface] to ensure the static IP is bound.
• Test Gateway: Run ping -c 3 [gateway_ip] to confirm local routing.