Initial Access and Remote Administration

The installation of Ubuntu Server 26.04 LTS was completed in the previous chapter. The next question is simple: how do we access this server on a daily basis? A server is not a laptop that is always right in front of us. Servers usually sit in a data center rack, at a cloud provider, or in a virtual machine far from our desk. Therefore, we need a secure and efficient remote access path before moving on to other configuration topics.

This chapter covers three major topics: first login to the server, SSH as the primary administration entry point, and remote session management to keep our work efficient even if the connection drops. We conclude with a discussion on console access as an emergency fallback when SSH encounters issues.

3.1 First Login to the Server

As soon as the installation process completes and the server reboots, a text-based login screen will welcome us. This is where we use the account created during installation via Subiquity in Chapter 2. For virtual machines, this first login is usually done via the hypervisor's built-in console (VirtualBox, KVM, or the cloud provider's VM console). For physical servers, we log in via a directly connected monitor and keyboard, or via remote console management such as IPMI/iDRAC/iLO if the supporting hardware is available.

This initial login is temporary. Our goal is to gather basic system information and ensure the server is ready to be accessed via SSH, so that the console session no longer needs to be used for daily operations.

Practical Steps

1. Log in using the username and password created during installation.
2. Check the server hostname to ensure the initial configuration is correct.

   hostnamectl

3. Check the IP address assigned to the server, as this is the address used later for SSH connections from our local computer.

   ip a

   Pay attention to the primary interface (usually enp0s3, eth0, or a similar name) and note its IPv4 address.
4. Update the package list and the system before proceeding further. This is a mandatory habit every time a new server is booted for the first time.

   sudo apt update
   sudo apt upgrade -y

5. Ensure openssh-server is installed. If the "Install OpenSSH server" option was checked during Subiquity installation, this package should already be present.

   dpkg -l | grep openssh-server

   If it does not appear, install it manually.

   sudo apt install openssh-server -y

Verification and Troubleshooting

• The hostnamectl output must display a hostname matching what was specified during installation. An empty hostname or one still named localhost indicates that the initial setup was not fully successful.
• If ip a does not show an IPv4 address on the main interface, the server likely has not received an address from DHCP, or the virtual network adapter is not connected properly. Check the network adapter settings in the hypervisor (for VMs) before going further.
• Ensure the output line of dpkg -l | grep openssh-server begins with status code ii. This code indicates the package is fully installed. If no lines appear at all, the openssh-server package is not installed and needs to be installed manually using the step above.

Once the IP address and SSH status are verified, we can close the console session and proceed to access the server via SSH from our own computer. The console remains useful as an emergency path, which will be discussed in more detail at the end of this chapter.

3.2 SSH as the Primary Administration Entry Point

Imagine the server as an office building. The console access used just now is like a back door that can only be opened if standing directly in front of it. SSH is the main entrance, the single path used to enter and exit every day by Sysadmins as well as Developers deploying applications. Due to its status as the main entrance, SSH is also the primary target for attackers trying to gain access via brute force attacks or weak configuration options.

SSH (Secure Shell) is a network protocol that allows us to access a server shell remotely over an encrypted connection. On the server side, this protocol is run by a daemon named sshd, managed via a systemd unit named ssh.

Practical Steps: Enabling and Checking the SSH Service

1. Enable the SSH service to start automatically at boot.

   sudo systemctl enable ssh

2. Check the service status.

   sudo systemctl status ssh

   If the service is not running, start it manually.

   sudo systemctl start ssh

3. In Ubuntu Server 26.04, SSH uses socket activation by default. This means the ssh.socket unit controls which port SSH listens on for incoming connections, rather than sshd itself directly. Check its status.

   systemctl status ssh.socket

   If the status is active (listening), socket activation is active. This detail is important later when changing the SSH port.

From our computer, test logging into the server using the IP address noted previously.

ssh username@server_ip_address

3.2.1 sshd_config Configuration

The primary SSH server configuration is stored in /etc/ssh/sshd_config. Rather than modifying this file directly, a safer and cleaner practice is to place changes inside the /etc/ssh/sshd_config.d/ directory. Files inside this directory are loaded before the main sshd_config, allowing hardening settings to be isolated from system defaults without editing original files.

Create a new configuration file for hardening purposes.

sudo nano /etc/ssh/sshd_config.d/00-hardening.conf

The file name starts with the prefix 00- so it is evaluated first relative to other files in the same directory. Always validate configuration syntax before applying any changes.

sudo sshd -t

If no output is returned, the configuration is valid and safe to apply.

3.2.2 Key-Based vs Password Authentication

Passwords can be guessed via brute force, especially if weak passwords are used. Key pair authentication is significantly more secure because it relies on a cryptographic key pair: a private key kept secret on the local machine, and a public key deployed to the server.

Practical Steps

1. On the local computer (not the server), generate a new key pair. The ed25519 algorithm is the standard choice because it is compact, fast, and secure.

   ssh-keygen -t ed25519 -C "[email protected]"

   Press Enter to accept the default location, then enter a passphrase to secure the private key. A passphrase is optional, but highly recommended.
2. Copy the public key to the server.

   ssh-copy-id username@server_ip_address

   This command will prompt for the server password one final time, then place the public key content into ~/.ssh/authorized_keys on the server.
3. Test passwordless login.

   ssh username@server_ip_address

   If login succeeds without prompting for the server user password (prompting only for the key passphrase if set), key-based authentication is functional.

3.2.3 Disabling Root Login and Password Login

Once key-based login is verified, the two most common vulnerabilities can be closed: direct root login via SSH, and password-based authentication. Add the following lines to the /etc/ssh/sshd_config.d/00-hardening.conf file created earlier.

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes

PermitRootLogin no forces anyone requiring administrative access to log in as a standard user and elevate privileges via sudo, rather than logging in directly as root. PasswordAuthentication no disables password logins, ensuring only keys registered in authorized_keys can authenticate.

Validate the syntax before restarting the service.

sudo sshd -t

Never close an active SSH session before verifying that the new configuration works. Open a new terminal window to test logging in, keeping the old session open as a fallback path in case of configuration errors.

sudo systemctl restart ssh

Attempt login from the new terminal. If key authentication succeeds and root login attempts are rejected, the configuration is working as intended.

3.2.4 Custom Ports and Security Considerations

Changing the default SSH port from 22 to a non-standard port is not a substitute for the hardening measures above, but it reduces automated login attempts from bots scanning port 22 on the internet. This is primarily for log noise reduction, not a primary security layer.

Because Ubuntu Server 26.04 uses socket activation for SSH, changing the Port directive in sshd_config alone is insufficient. The ssh.socket unit will continue listening on port 22 until a socket override is created. Follow these proper steps.

Practical Steps

1. Create an override for the ssh.socket unit.

   sudo systemctl edit ssh.socket

2. Populate the opened editor with the following configuration, replacing 2222 with the chosen port.

   [Socket]
   ListenStream=
   ListenStream=0.0.0.0:2222
   ListenStream=[::]:2222

   The empty ListenStream= line at the beginning clears default port 22 settings before adding the new port.
3. Reload systemd configuration and restart the socket.

   sudo systemctl daemon-reload
   sudo systemctl restart ssh.socket

4. Allow the new port in the firewall before terminating existing connections.

   sudo ufw allow 2222/tcp comment 'SSH custom port'

5. Test the connection using the new port.

   ssh -p 2222 username@server_ip_address

6. Once the new port is confirmed working, remove the firewall rule for port 22 if it is no longer needed.

   sudo ufw delete allow 22/tcp

Verification and Troubleshooting

• Check which port SSH is listening on.

  sudo ss -tlnp | grep ssh

• Check active effective configuration in sshd.

  sudo sshd -T | grep -E "^(port|passwordauthentication|permitrootlogin)"

• Connection refused typically indicates that the ssh or ssh.socket service is inactive, or a firewall is blocking the target port.
• Permission denied (publickey) usually means the public key is missing from the server's authorized_keys, or permissions on the .ssh directory are too permissive. Ensure correct permissions.

  chmod 700 ~/.ssh
  chmod 600 ~/.ssh/authorized_keys

• If locked out due to configuration misstep, do not panic. Section 3.4 below covers emergency recovery via console access.

3.3 Remote Session Management

SSH connections can drop due to unstable Wi-Fi, laptops entering sleep mode, or momentary network disruptions. If a long-running process like a large package installation or database migration is executing, that process terminates when the SSH connection breaks. This is where terminal multiplexers become essential.

3.3.1 tmux/screen for Persistent Sessions

tmux and screen are tools that keep terminal sessions running on the server even if the SSH connection disconnects. Sessions can be detached (detach) and later reattached (reattach) at any time, even from a different computer.

Practical Steps: tmux

1. Install tmux if not already available.

   sudo apt install tmux -y

2. Create a new named session for easy identification later.

   tmux new -s deploy

3. Run tasks normally inside this session.
4. To exit without stopping the session, press Ctrl+b followed by d.
5. If the SSH connection drops or is manually detached, the session continues running on the server. List active sessions using:

   tmux ls

6. Reattach to the existing session.

   tmux attach -t deploy

7. To terminate the session completely rather than detaching, type exit inside the session, or kill it externally.

   tmux kill-session -t deploy

In production environments, assigning clear session names like deploy, backup-db, or app-migration is crucial when multiple tmux sessions run concurrently. Generic names like default numbers in tmux cause confusion during incident response when fast reattachment is needed.

screen operates on similar principles and remains common on legacy servers.

sudo apt install screen -y
screen -S deploy

Detach from a screen session using Ctrl+a followed by d, and reattach using screen -r deploy. To terminate a screen session completely, type exit inside the session, or run screen -X -S deploy quit from outside the session.

3.3.2 File Transfer: scp, sftp, rsync

Beyond executing commands, Sysadmin duties regularly require transferring files between local machines and remote servers, such as uploading configuration files or downloading backup archives.

scp is suited for quick, simple single-file transfers.

scp report.txt username@server_ip_address:/home/username/

sftp opens an interactive session similar to FTP running securely over SSH, useful when browsing remote directory structures before selecting files to transfer.

sftp username@server_ip_address

Inside an sftp session, use commands like ls, cd, get file_name to download, and put file_name to upload.

rsync is the preferred choice for syncing large directories or routine backups, as it transfers only modified delta portions of files rather than re-transmitting whole files.

rsync -avz -e ssh /local/path/ username@server_ip_address:/destination/path/

The -a flag preserves file attributes like permissions and timestamps, -v enables verbose output, and -z compresses data during transport.

Verification and Troubleshooting

• If tmux attach -t deploy returns no server running on ..., the session no longer exists, typically because the server rebooted or the session was previously terminated. All processes running inside it have stopped.
• Processes inside a tmux/screen session can crash independently while the session shell remains active. Check application logs; do not assume an active session implies the underlying process is running normally.
• If scp or rsync fails with a Permission denied message, the target user lacks write permissions on the destination directory. Verify path permissions for that user.
• If rsync fails with command not found, the rsync package is missing on the remote server. Install it first.

  sudo apt install rsync -y

3.4 Console Access as a Fallback

What happens if SSH becomes entirely inaccessible due to a configuration error in sshd_config.d blocking all access paths? This is where console access serves as a critical emergency recovery method.

For virtual machines, access the console via the hypervisor's built-in interface (such as VirtualBox or virt-manager for KVM). Cloud instances generally provide a web console or serial console via their management dashboard, accessible even when network SSH services fail.

Through this console interface, log in as a standard user (or boot into recovery mode if necessary) to repair broken configuration files.

sudo nano /etc/ssh/sshd_config.d/00-hardening.conf

After applying fixes, re-validate configuration syntax and restart the SSH service prior to testing remote login again.

sudo sshd -t
sudo systemctl restart ssh

Testing every SSH configuration modification in a separate terminal session prior to closing existing connections (as covered in section 3.2.3) prevents reliance on emergency access paths. However, should lockouts occur, recovery remains straightforward using serial console options.