Changing the address of the machine you are currently SSHed into is one of those tasks that feels routine right until the terminal freezes. The reliable approach starts with ownership and rollback: reserve the address centrally when possible, record the current working network, keep console access, and only then change the host configuration.

Prefer a DHCP reservation when possible

  • The router/DHCP server always assigns the same address to the host’s stable client identifier/MAC.

  • Gateway, DNS, routes, and subnet changes remain centrally managed.

  • Address conflicts are easier to prevent through the DHCP/IPAM source of truth.

  • Laptops and systems moving between networks retain ordinary DHCP behavior.

  • The host needs no hard-coded local network assumptions.

  • A host-side static address remains justified for environments without controllable DHCP, certain infrastructure roles, or explicit platform designs.

Collect the working state first

Ubuntu hostbash
ip -brief link
ip -brief address
ip route show
ip -6 route show
resolvectl status
sudo netplan get
Record the active interface, addresses/prefixes, default routes, DNS, renderer, and generated Netplan view.

Modern tools expose different layers

  • ip link/address replaces legacy ifconfig for interface and address inspection.

  • Routes reveal the actual gateway/default path and any policy/static networks.

  • resolvectl shows systemd-resolved per-link/global DNS state on typical Ubuntu installations.

  • netplan get shows merged Netplan configuration, not merely one YAML file.

  • Interface names such as enp2s0, ens18, or wlp3s0 are machine-specific.

  • Save this evidence somewhere reachable if the host goes offline.

Identify who manages the interface

Ubuntu hostbash
networkctl status --all --no-pager
nmcli general status 2>/dev/null || true
nmcli device status 2>/dev/null || true
ls -l /etc/netplan
Determine whether Netplan renders to systemd-networkd or NetworkManager and which interface is managed.

Avoid competing sources of truth

  • Ubuntu Server commonly uses networkd; Desktop commonly uses NetworkManager.

  • Netplan YAML can configure either renderer.

  • NetworkManager connection profiles may be generated or managed directly depending on the installation.

  • Cloud images can regenerate Netplan from cloud-init/provider metadata.

  • Do not simultaneously configure the same interface in /etc/network/interfaces, Netplan, NetworkManager, and custom systemd units.

  • Follow the hosting/provider network model when it supplies routes, virtual gateways, or metadata-driven addresses.

Choose values from the network authority

  • IPv4/IPv6 address and prefix length, for example 192.168.50.20/24.

  • Default gateway reachable on that link, for example 192.168.50.1.

  • DNS resolver addresses and intended search domains.

  • Dynamic DHCP pool boundaries and the approved reserved/static range.

  • VLAN, bridge, bond, Wi-Fi SSID, routing-table, MTU, or proxy requirements.

  • Whether IPv6 is SLAAC, DHCPv6, static, provider-routed, or intentionally disabled by policy.

  • Reverse DNS and firewall/ACL updates required for the new address.

Change-window gate

  • Out-of-band console access is tested, not merely documented.

  • The exact current address, route, DNS, renderer, and manager configuration is backed up.

  • The new address is allocated/excluded in DHCP or IPAM and checked against network inventory.

  • Firewall, ACL, monitoring, DNS, and dependent clients are prepared for transition.

  • A timed rollback and named operator/observer are ready before the first apply.

1. Create a dedicated Netplan file

/etc/netplan/60-static-enp2s0.yamlyaml
network:
  version: 2
  renderer: networkd
  ethernets:
    enp2s0:
      dhcp4: false
      addresses:
        - 192.168.50.20/24
      routes:
        - to: default
          via: 192.168.50.1
      nameservers:
        addresses:
          - 192.168.50.1
          - 1.1.1.1
        search:
          - lab.example

Replace every example value

  • enp2s0 must match the real managed Ethernet interface.

  • CIDR /24 is equivalent to 255.255.255.0; use the actual prefix.

  • The default route uses the current routes syntax rather than deprecated gateway4.

  • The gateway must be reachable under the link’s addressing/routing design.

  • DNS may point to internal resolvers; a public resolver can break private names or violate policy.

  • renderer: networkd must match the intended manager.

  • YAML indentation uses spaces and is structurally significant.

Why a new numbered file helps

Netplan merges YAML files in lexical order, so later files can override earlier values. A dedicated file separates local intent from installer/cloud defaults, but merging can also surprise you. Review netplan get and generated output after changes; do not assume the last filename replaces every nested key.

2. Back up and install with restrictive permissions

Ubuntu hostbash
sudo install -d -m 0700 /root/netplan-backup
sudo cp -a /etc/netplan/. /root/netplan-backup/
sudo chmod 0600 /etc/netplan/60-static-enp2s0.yaml
sudo chown root:root /etc/netplan/60-static-enp2s0.yaml
The current Netplan tree is copied to a root-only recovery directory and the new file is root-only.

Risk level: caution. Review the command before running it.

Network files can contain secrets

  • Wi-Fi credentials and private topology may appear in Netplan, justifying mode 0600.

  • The backup preserves metadata and remains outside ordinary user/web directories.

  • Know how to restore it from console before applying.

  • Do not copy secrets into tickets, terminal recordings, or public repositories.

  • A backup on the same disk is rollback convenience, not disaster recovery.

3. Validate without applying

Ubuntu hostbash
sudo netplan generate
sudo netplan get
No output from generate indicates the configuration parsed; inspect the merged configuration from get.

Parsing is necessary but not network proof

  • netplan generate validates YAML/schema and generates backend configuration without intentionally applying it.

  • Read warnings about permissions, deprecated keys, conflicting routes, or renderer support.

  • netplan get helps catch merge behavior from multiple files.

  • A syntactically valid gateway can still be wrong or unreachable.

  • Review generated networkd/NetworkManager output when troubleshooting rather than hand-editing generated files.

4. Apply with timed rollback

Ubuntu console or protected remote sessionbash
sudo netplan try --timeout 120
Do you want to keep these settings?
Press ENTER before the timeout only after connectivity is verified.

Risk level: caution. Review the command before running it.

Do not confirm from hope

  • netplan try temporarily applies configuration and rolls back if not confirmed before timeout.

  • Behavior depends on the renderer/configuration and complex virtual devices deserve extra caution.

  • From a second terminal, test the new address, gateway, DNS, and application access before confirming.

  • Keep the original session and out-of-band console available.

  • If rollback fails or connectivity is already lost, restore known-good YAML from console and apply/reboot per recovery plan.

5. Verify address and route selection

Ubuntu hostbash
ip -brief address show dev enp2s0
ip route show
ip route get 1.1.1.1
ip route get 192.168.50.1
Confirm the new prefix and that route lookup selects enp2s0, the intended source address, and gateway.

Route lookup is more useful than memorizing the table

  • The interface should carry the intended static address and no unintended stale DHCP address.

  • ip route get shows the selected path/source for a destination.

  • Multiple default routes need deliberate metrics/policy routing.

  • A gateway on another subnet may require provider-specific on-link routes; do not invent this on ordinary LANs.

  • Check IPv6 separately when enabled.

6. Verify the network layer by layer

Ubuntu hostbash
ping -c 3 192.168.50.1
getent ahosts ubuntu.com
curl --fail --show-error --head https://ubuntu.com/
resolvectl status enp2s0
Verify gateway reachability, DNS resolution, HTTPS, and per-link resolver configuration independently.

Each check narrows a different failure

  • Gateway ping tests local routing/neighbor reachability only and ICMP can be filtered.

  • getent uses the system name-service stack rather than querying an arbitrary DNS server.

  • HTTPS verifies route, DNS, TCP, TLS, and a responding remote service.

  • resolvectl confirms which DNS/search domains are active on the link.

  • Do not treat a failed public endpoint as definitive if egress policy intentionally blocks it; use approved targets.

7. Test remote access from another host

Another authorized LAN/management hostbash
ping -c 3 192.168.50.20
ssh -o ConnectTimeout=10 admin@192.168.50.20
Open a new SSH session through the new address before closing the old session.

Inbound access has extra dependencies

  • Host firewall and network ACLs must allow the management source.

  • SSH may bind only selected addresses/interfaces.

  • Known-host keys identify the server; investigate changes rather than bypassing verification.

  • DNS inventory can be updated after address-level access is proven.

  • Do not close recovery sessions until application monitoring and reboot persistence pass.

NetworkManager-managed desktop alternative

Ubuntu Desktop / NetworkManager hostbash
nmcli connection show
nmcli connection show "Wired connection 1"
nmcli connection modify "Wired connection 1" \
  ipv4.method manual \
  ipv4.addresses 192.168.50.20/24 \
  ipv4.gateway 192.168.50.1 \
  ipv4.dns "192.168.50.1 1.1.1.1"
nmcli connection up "Wired connection 1"
The named NetworkManager profile is modified and reactivated.

Risk level: caution. Review the command before running it.

Modify the correct profile, not just the device

  • Connection profile names are user/system-specific; inspect them first.

  • Reactivating the profile interrupts connectivity and can drop remote access.

  • Direct nmcli changes may conflict with Netplan-managed/generated profiles; choose one durable ownership model.

  • For Wi-Fi, keep SSID/security secrets protected and expect roaming/network-specific profiles.

  • NetworkManager checkpoint features or console recovery deserve evaluation for remote changes.

  • Verify the same address/route/DNS/reboot checklist afterward.

Cloud-init and hosted server warnings

  • Cloud-init may regenerate /etc/netplan/50-cloud-init.yaml on reboot.

  • Providers may route addresses without an ordinary LAN gateway or require virtual MAC/interface metadata.

  • Editing network configuration outside the cloud control plane can sever console/metadata access.

  • Use provider-supported static/private IP attachment and authoritative documentation.

  • If disabling cloud-init network management is truly required, document ownership and future image/update behavior first.

  • Test a reboot while console access is available.

Static IPv6 is not “IPv4 with colons”

  • Confirm the provider/router delegates or routes the chosen prefix/address.

  • Understand Router Advertisements, SLAAC, DHCPv6, default route, DNS, privacy addresses, and duplicate-address detection.

  • Do not disable IPv6 to hide incomplete configuration when services/DNS still publish AAAA records.

  • Use separate addresses, routes, and nameserver entries with the authoritative prefix/gateway design.

  • Verify ip -6 address, ip -6 route, neighbor discovery, DNS AAAA, and HTTPS over IPv6.

  • Apply firewall policy equivalently for IPv4 and IPv6.

Rollback from console

Out-of-band/local consolebash
sudo cp -a /root/netplan-backup/. /etc/netplan/
sudo netplan generate
sudo netplan apply
Restore the known-good files, validate, apply, and verify the previous address/route/DNS.

Risk level: caution. Review the command before running it.

Recovery must restore ownership as well as files

  • Remove/rename the faulty new override if it was not present in the backup.

  • Inspect merged netplan get before applying.

  • Preserve root ownership and restrictive permissions.

  • Use local/provider console because the network may be unavailable.

  • After recovery, collect logs and diff configuration before attempting a revised change.

Reboot persistence gate

  • Reboot only while console and rollback access remain available.

  • Confirm the expected manager claims the interface after boot.

  • Repeat address, route-source, gateway, DNS, HTTPS, inbound SSH, firewall, and application checks.

  • Confirm no cloud-init/DHCP/secondary profile restored an old or duplicate address.

  • Update IPAM, DNS, monitoring, documentation, and retire the old address only after the rebooted state is stable.

Common failures decoded

  • YAML parse error: inspect indentation, tabs, key spelling, file permissions, and Netplan version support.

  • Address appears but no internet: wrong prefix/gateway/default route or upstream policy.

  • IP works but names fail: DNS/search domain/systemd-resolved configuration issue.

  • Duplicate IP symptoms: intermittent ARP/neighbor movement; remove the collision and fix DHCP/IPAM ownership.

  • Configuration reverts after reboot: cloud-init, NetworkManager profile generation, or another manager owns the interface.

  • Two addresses remain: DHCP is still active or another YAML/profile adds an address.

  • SSH lost after apply: wrong address/route/firewall; wait for try rollback or use console.

  • Wrong interface configured: predictable names differ; match permanent MAC/set-name only with careful hardware replacement planning.

  • Wi-Fi static config fails: credentials/renderer/profile/route may be wrong; prefer NetworkManager profile management on desktops.

Production completion checklist

  • DHCP reservation was evaluated first.

  • Address, prefix, gateway, DNS, pool exclusion, and ownership come from DHCP/IPAM/network authority.

  • Current interface, renderer, routes, DNS, cloud/provider ownership, and recovery console are recorded.

  • Netplan or NetworkManager is the single durable manager for the interface.

  • Backup exists with a tested restore procedure.

  • Generate/get validation passes and timed try/rollback is used where supported.

  • Address, source-route selection, gateway, DNS, HTTPS, inbound management, firewall, and application checks pass.

  • No duplicate address or unintended DHCP/default route remains.

  • Reboot persistence and monitoring pass before the old address/DNS record is retired.

  • Documentation and IPAM/DHCP/DNS/firewall inventory are updated.

Official Ubuntu and Netplan references