First SSH login to a Linux server: what to do in the first hour

Updated 4 October 2026 13 min read Читати українською

Contents

A checklist for an administrator who has just received access from support to a dedicated server running Ubuntu or Debian. In an hour you will have an up-to-date system, a working user with an SSH key, an active firewall, the correct time and a backup plan.

What you will need#

The email from support with your login details: server address, user name and password. The system is installed before delivery, and the installation creates a user with sudo rights named after the distribution: debian or ubuntu. SSH runs on the standard port 22. The examples below use placeholders: the address 203.0.113.10, the delivered user debian and a personal user admin.
Optionally, your public SSH key. If you pass it on in advance (in the comment on your order or to support before delivery), it is added to the delivered user straight away.
A computer with an SSH client. Windows 10, Windows 11 and Windows Server 2019 or later usually have the OpenSSH client installed — just open PowerShell; on macOS and Linux use Terminal.
A network you trust (not public Wi-Fi) and an unhurried hour.

The commands were checked in October 2026 on Ubuntu 26.04 LTS and Debian 13 “trixie”; they are the same on Ubuntu 24.04 LTS and Debian 12. Commands that need administrator rights are given with sudo.

Open PowerShell or Terminal and connect, using the user name and the address from the email (on Ubuntu, ubuntu@…):

ssh debian@203.0.113.10

Password login as root is disabled, so connect as the delivered user; there is no need to give a port. If you passed on your key in advance, the client finds it by itself (if the private key is not in the standard location, add -i and the path to it); otherwise enter the password from the email. If Windows cannot find the ssh command, add “OpenSSH Client” in the system’s optional features — see the Microsoft guide.

On the first connection the client shows the host key fingerprint and asks whether to trust the server:

The authenticity of host '203.0.113.10 (203.0.113.10)' can't be established.
ED25519 key fingerprint is SHA256:...
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

The fingerprint lets you make sure you have reached your own server. If support sent a fingerprint, paste it instead of yes: an OpenSSH 8.0 or later client compares the values itself and connects only if they match. An older client offers only yes/no — then compare the strings yourself. If they differ, do not connect and write to support. If the email has no fingerprint, ask support how to verify it. After logging in, save the fingerprints — other administrators will need them:

for f in /etc/ssh/ssh_host_*_key.pub; do ssh-keygen -lf "$f"; done

2. Change the password#

Treat a password that arrived by email as temporary: a mailbox is no place to keep secrets. Change it straight away, even if you log in with a key, and store the new one in a password manager:

passwd

3. Update the packages#

sudo apt update
sudo apt full-upgrade

If apt asks what to do with a modified configuration file (for example /etc/ssh/sshd_config), keep the current version — that is the default answer. If the kernel was updated (the linux-image packages), reboot the server; on Ubuntu the file /var/run/reboot-required reminds you of this. A dedicated server takes a few minutes to reboot.

sudo reboot

4. The delivered user or your own#

You can keep the delivered user: it gets administrator rights through sudo, so there is no need to work as root. If several people administer the server, create a personal account for each: the logs then show who did what, and you can close access for someone who has left without affecting the others. An example for the user admin:

sudo adduser admin
sudo usermod -aG sudo admin

adduser asks you to set a password — sudo will ask for it later. If you log in with a key, copy the delivered user’s keys to the new user:

sudo install -d -m 700 -o admin -g admin /home/admin/.ssh
sudo install -m 600 -o admin -g admin ~/.ssh/authorized_keys /home/admin/.ssh/authorized_keys

Without closing the current session, open a second terminal window and test the new login:

ssh admin@203.0.113.10
sudo whoami

The answer root means sudo works.

5. Add an SSH key#

A key is stronger than a password: it cannot be guessed by brute force. If you passed on your key in advance, it is already on the server. Otherwise create a key on your own computer (not on the server); on macOS and Linux the second command installs it on the server — use the user you will work as:

ssh-keygen -t ed25519
ssh-copy-id admin@203.0.113.10

Windows has no ssh-copy-id command. “SSH keys” explains how to install the key from there, protect it with a passphrase and when it is safe to turn off password login. Do not turn off password login until you have confirmed that key login works. Bear in mind that our Linux images are configured by cloud-init, so /etc/ssh/sshd_config.d/ may contain its file with the PasswordAuthentication setting, and that file takes precedence over /etc/ssh/sshd_config. This command shows the value in effect:

sudo sshd -T | grep -i passwordauthentication

6. Enable a basic firewall#

Warning. A firewall enabled without a rule for SSH will cut you off from the server. Allow SSH first, then enable the firewall, and do not close the current session until you have tested a new login from a second window. To roll back, run sudo ufw disable in the open session. If access is lost anyway, contact support (see “If you have lost access”).

Install ufw (on Ubuntu it is usually already there) and find the port you are connected to — the last number in the output of the second command (straight after delivery it is 22):
```
sudo apt install ufw
echo $SSH_CONNECTION
```
Allow SSH (if you have changed the port, use your own) and check that the rule has been added:
```
sudo ufw allow 22/tcp
sudo ufw show added
```
Add a safety net: this command switches the firewall off by itself in 10 minutes unless you cancel it:
```
sudo systemd-run --unit=ufw-rollback --on-active=10min /usr/sbin/ufw disable
```
Enable the firewall (answer y when asked about possibly disrupting SSH connections) and check its status:
```
sudo ufw enable
sudo ufw status verbose
```
Connect to the server again from the second terminal window. If the login works, cancel the safety net:
```
sudo systemctl stop ufw-rollback.timer
```
If it does not, run sudo ufw disable in the first window, or wait for the automatic switch-off, and check the rule. If you ran over the 10 minutes, the safety net has already switched the firewall off: repeat steps 3–5.

By default ufw blocks all incoming connections except the allowed ones and lets outgoing ones through. The rules apply to IPv6 too, and that matters: main-line servers get an IPv6 /64 block (/56 on the Power and Ultra lines, a single address on Lite), and the first address is configured during installation — the command ip -6 addr show scope global shows it. ufw lets ping (ICMP echo) requests through by default — do not block them: the data centre checks that the server is up by pinging it, and monitoring will treat a server that does not answer as down. Ask support which monitoring mode is enabled for your server. Open other ports (for example 80/tcp and 443/tcp for a website) once a service needs them. Reference: the ufw manual.

7. Time zone and time synchronization#

Logs, backups, certificates and document dates in accounting systems all depend on accurate time.

timedatectl
sudo timedatectl set-timezone Europe/Kyiv
timedatectl

The output should contain the lines System clock synchronized: yes and NTP service: active. If the service is inactive, turn it on: sudo timedatectl set-ntp true.

8. Hostname#

A clear name in the command prompt lowers the risk of running a command on the wrong server.

sudo hostnamectl hostname srv1
hostnamectl

The prompt shows the new name after the next login. In /etc/hosts (sudo nano /etc/hosts) replace the old name in the 127.0.1.1 line with the new one; if there is no such line, add it:

127.0.1.1 srv1.example.com srv1

The reverse DNS record for the server address, needed above all by mail servers, is set up by support on request; before you ask, create a forward A record for this name with the server address.

9. Look over the hardware#

Compare what the system sees with the configuration you ordered: processor model, amount of memory, number and size of disks.

lscpu
free -h
lsblk
cat /proc/mdstat

If the server has two or more disks, the system is installed on all of them with software RAID 1 (a mirror). Typical /proc/mdstat output for two NVMe disks (disk names, sizes and the number of arrays may differ on your server):

Personalities : [raid1]
md2 : active raid1 nvme0n1p2[0] nvme1n1p2[1]
      1046528 blocks super 1.2 [2/2] [UU]

md3 : active raid1 nvme0n1p3[0] nvme1n1p3[1]
      497875968 blocks super 1.2 [2/2] [UU]
      bitmap: 1/4 pages [4KB], 65536KB chunk

unused devices: <none>

Here md2 is /boot and md3 is the root /. There is an EFI partition on each disk, outside RAID; only one is mounted, as /boot/efi (on Debian 13 and Ubuntu 26.04 it is mirrored too). Swap, likewise, is a separate partition on each disk outside RAID. [UU] means both disks of a mirror are working, [U_] means one of them has dropped out of the array. A resync line on a newly delivered server is the initial synchronization; it finishes on its own. If the server card says “hardware RAID”, the array is built by the controller: the system sees a single disk, and you check its status with the controller’s utility (for example storcli).

If something does not match your order or an array is incomplete, write to support at once. More in “How to check software RAID and disk health on a server”.

10. Automatic security updates#

On Ubuntu the unattended-upgrades package is usually installed and enabled from the start; on Debian you may have to add it:

sudo apt install unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades
cat /etc/apt/apt.conf.d/20auto-upgrades

Answer “Yes” to the question from the second command. The file should contain two lines:

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";

Security updates will be installed daily, but the server will not reboot by itself: a new kernel takes effect only after a reboot, which you plan yourself. Logs are in the /var/log/unattended-upgrades/ directory; details are on the Debian wiki.

11. Backups from day one#

RAID saves you from a disk failure, but not from accidental deletion, ransomware or a failed update. Set up backups before working data appears on the server. Main-line servers include backup space on separate storage — 500 GB; see the server card for the exact amount. You set the copying up yourself, it is not automatic; support will send the connection details. Where to start: the 3-2-1 rule, backups with restic, database backups.

How to check the result#

What to check	Command	What you should see
Login as your user	`ssh admin@203.0.113.10` from a new window, then `sudo whoami`	Login without errors, the answer `root`
Firewall	`sudo ufw status verbose`	`Status: active`, incoming is `deny`, there is a rule for SSH
Time	`timedatectl`	The time zone you need, `System clock synchronized: yes`
Disks	`cat /proc/mdstat`	With software RAID, `md2` and `md3` show `[UU]`, not `[U_]`
Automatic updates	`systemctl list-timers 'apt-daily*'`	Two timers with the time of the next run

Finally, reboot the server and go through the table again: the settings must survive a reboot.

Common mistakes#

Permission denied when logging in as root: password login as root is disabled — log in as the delivered user and use sudo.
The REMOTE HOST IDENTIFICATION HAS CHANGED warning. After a system reinstall it is expected: remove the old key with ssh-keygen -R 203.0.113.10. If the system has not been reinstalled, do not connect until you know why.
sudo refuses the new user: usermod was skipped or the user has not logged in again — group membership takes effect only after a new login.

If you have lost access#

Check the simple things first: address, port, login, keyboard layout, a connection from another network. If the server still does not let you in, contact technical support — it is available around the clock: phone +38 044 206 08 08, email info@united.net.ua. There is no client area yet, so support carries out a hard reboot or a system reinstall on request. It also provides the remote console — the server’s screen and keyboard in your browser (it may not be available on Lite); the link works for a limited time and only from the public IP address you give in the request. Or support can reboot the server into rescue mode — a temporary Linux system with SSH access where you can mount the disks and fix the settings. Give the server address, what you were doing before access was lost and the text of the error — that way you will get help sooner.

What next#

Basic protection of a Linux server: SSH, firewall, updates — the continuation of this checklist.
Need another server or a standby site? See the dedicated server catalogue and locations.