Linux Tutorial / Set Up a New Linux Server Safely
Prepare a new server by establishing recovery access, validating a normal administrator account and SSH key, then checking updates, time, required ports, and reboot behavior. Completion means required access and services still work in a fresh session and after a planned reboot.
After account creation and initial configuration, open a new SSH key login and verify permissions before applying firewall and account protection. Retain console access and the original session throughout verification.
System configuration exercises use a conventional Ubuntu 26.04 LTS or Rocky Linux 9 VM as the reference environment. Containers, WSL, and other releases can differ in service and package configuration. Prepare console recovery and record your versions using the virtual machine setup lesson.
Confirm the server and its recovery channel
Use a new VM or test server and choose either Ubuntu or Rocky Linux. Establish administrator privileges, console access, and a backup or rebuild procedure. Snapshots can simplify rollback, but do not automatically solve shared-storage failure or application consistency.
cat /etc/os-release
hostnamectl
ip -brief address
ip route
timedatectl
lsblk -fRecord distribution, hostname, addresses, timezone, and storage to confirm you are on the intended machine. Do not copy device names, service names, or addresses blindly from another lab. On cloud images, inspect the initial account and any settings managed by cloud-init.
Create or verify a normal administrator account
Reuse an appropriate existing administrator account. If creating courseadmin, first check that it does not already exist with getent passwd courseadmin. Use only the block for your distribution. Enter passwords interactively rather than embedding them in commands.
sudo adduser courseadmin
sudo usermod -aG sudo courseadminsudo useradd -m courseadmin
sudo passwd courseadmin
sudo usermod -aG wheel courseadminLog in from a new terminal and check id and sudo -v. Supplementary groups may not update in an existing session. If sudoers needs changes, use visudo validation and preserve the current administrative session. Do not add unrestricted passwordless administration merely for convenience.
Validate SSH keys through a second connection
On the client, select an approved key or create a new one, and verify the server host-key fingerprint through the trusted console. Install only the public key and test a separate connection with the actual account and address. Confirm sudo through that connection before restricting firewall or authentication policy.
Inspect the actual SSH listener and any cloud access rules. Restrict passwords only after validating key authentication and recovery, then check sshd syntax and a fresh login. A surviving existing connection and an allowed new connection are separate tests.
Apply planned updates and verify time and identity
sudo apt update
sudo apt upgradesudo dnf upgradeRun only the applicable update block and review the proposed transaction. Check service restarts, kernel changes, and reboot requirements, then retest needed functions. Inspect timezone and synchronization with timedatectl and choose an actual IANA timezone according to the operating policy if a change is required.
If renaming the host with hostnamectl, review DNS, hosts entries, certificates, and management integrations. Check whether cloud-init or another provisioning system will overwrite the value. Enabling time synchronization does not prove successful synchronization where time-server access is blocked.
Limit exposure and save a baseline
Inspect the firewall actually in use, typically UFW on Ubuntu or firewalld on Rocky Linux. Permit the verified management port and test a new connection before adding only required services. Review IPv4 and IPv6 and both host and cloud policy; do not disable SELinux without diagnosing the actual issue.
mkdir -p "$HOME/server-baseline"
chmod 700 "$HOME/server-baseline"
cat /etc/os-release > "$HOME/server-baseline/os-release.txt"
ip -brief address > "$HOME/server-baseline/addresses.txt"
lsblk -f > "$HOME/server-baseline/storage.txt"
systemctl --failed > "$HOME/server-baseline/failed-units.txt"These files provide a comparison baseline without passwords, private keys, or tokens. Addresses and storage topology are still operational information, so restrict access. Store configuration backups separately and document how authorized recovery staff can retrieve them.
Verify readiness after a planned reboot
- Choose an interruption window, verify console access, and save needed data.
- Perform a planned sudo reboot and inspect boot progress through the console.
- Test a new SSH session, sudo, networking, time synchronization, required services, and mounts.
- Review failed units and current-boot logs against the baseline.
If reconnection fails, use the console to inspect the address, SSH service, listener, and firewall in order. Restore according to the last change instead of making several speculative edits. Proceed to application installation only after management access has been verified.
