First Login to a Linux Server: TTY, SSH, and Root vs Regular Users

Your first login to a Linux server sets the tone for everything that comes after it. Whether you are sitting in front of a physical machine or connecting remotely over the network, you will always interact with the system through a login prompt and a user account. Understanding the difference between TTY and SSH, and between the root user and a regular user, is one of the most important first steps for any future Linux sysadmin.

Why the First Login Matters

Many people treat the first login as a quick “enter password and start installing stuff” moment. In reality, it is a critical security and configuration milestone.

On that first login you often:

• Change default passwords.
• Create your own non-root user for daily work.
• Configure remote access (SSH) securely.
• Decide how you will administer the server in the long term.

Before we change anything, let us understand how you actually log in and which account you should use.

What Is a TTY?

The term TTY originally comes from “teletypewriter”, old physical terminals connected to mainframe  computers. In modern Linux, a TTY is a text-only console that accepts your username and password and runs a shell.

You usually meet TTYs in these scenarios:

• Physical server or desktop – You plug in a keyboard and monitor and see a black login prompt.
• Virtual machine console – In VMware, VirtualBox, Proxmox, or a cloud provider’s “console” view.
• Local maintenance mode – When the graphical environment is not available or disabled.

On many Linux systems you can switch between multiple TTYs using key combinations like Ctrl + Alt + F1 to Ctrl + Alt + F6 (exact numbers depend on the distribution). Each one is an independent text login session.

When you log in via TTY, you are working locally on the machine. No network is involved: if the network is down, you can still use a TTY.

Typical TTY Login Flow

1. You see a prompt similar to:

   Debian GNU/Linux 13 <hostname> tty1
   
   <hostname> login:

2. You enter your username, press Enter.
3. You enter your password (characters are not shown), press Enter.
4. You get a shell prompt, for example:

   username@hostname:~$

TTY is ideal for initial server setup, breaking out of broken GUI sessions, or troubleshooting when the network is not working.

What Is SSH?

SSH (Secure Shell) is the standard way to log in to a Linux server remotely over the network. Instead of sitting at the machine, you connect from your laptop or workstation using an SSH client.

Key characteristics of SSH:

• Encrypted connection – Protects your credentials and commands from eavesdropping.
• Runs over TCP port 22 by default.
• Works across networks – LAN, VPN, or even across the internet (with proper firewall and security).
• Supports password login and more secure key-based authentication.

Typical SSH Login Flow

From your local machine:

ssh username@server-ip-or-hostname

On the first connection, SSH asks you to verify the server’s fingerprint, then it prompts for your password or uses your SSH key. If successful, you get a shell prompt similar to the TTY login, but now over the network.

For servers in real environments, SSH becomes your primary way of working. TTY is usually reserved for emergency or out-of-band access (for example through a hypervisor console or IPMI module).

Root vs Regular User: Who Are You Logging In As?

Now that we know how we log in (TTY or SSH), we need to talk about who is logging in. Linux is a multi-user operating system. Every action you perform is tied to a user account. The most important distinction is between the root user and regular users.

The Root User

The root user is the superuser on a Linux system:

• Has permission to read and modify any file.
• Can start and stop any service.
• Can create, modify, or delete any user or group.
• Can change networking, firewall rules, and kernel settings.

You can recognize a root shell prompt because it usually ends with # instead of $:

root@hostname:~#

Powerful, right? Also dangerous. A small typo as root can break the whole system:

• Accidentally removing critical files.
• Changing permissions in the wrong directory.
• Stopping the wrong service on a production server.

For this reason, modern best practice is: do not work as root all the time, especially not over SSH.

Regular Users

A regular user is a normal account created for daily work:

• Has a home directory like /home/username.
• Cannot modify system files by default.
• Needs special privileges to perform administrative actions.

A regular shell prompt usually ends with $:

martin@server:~$

Working as a regular user by default:

• Reduces the risk of accidental damage.
• Makes it clearer when you are doing something dangerous (because you explicitly escalate privileges).
• Is a strong security best practice, especially on internet-facing servers.

Using sudo: Temporary Superpowers for Regular Users

Instead of logging in as root, the recommended approach is:

1. Log in as a regular user.
2. Use sudo to run specific administrative commands with root privileges.

Example:

martin@server:~$ sudo apt update

When you use sudo, the system prompts you for your own password (not the root password, depending on configuration). The command then runs with root permissions, but only for that specific operation.

This gives you:

• Auditability – Commands executed via sudo are logged.
• Control – Only users in the sudo (or wheel) group can run admin commands.
• Safety – If you forget sudo, the command fails instead of silently doing something dangerous.

Creating a New User and Adding It to sudo

On many distributions you can do:

# create a new user
sudo adduser adminuser

# add the user to the 'sudo' group (Debian/Ubuntu style)
sudo usermod -aG sudo adminuser

After this, adminuser can log in and use sudo for administrative tasks.

First Login on the Local Console (TTY)

On a freshly installed server, your first login is often via TTY:

1. Log in as the user created during installation (often a regular user with sudo access).
2. If the installer did not create such a user, you might temporarily log in as root with the password set during installation.

Once you are in, a good first step is to create your personal admin user if it does not exist yet:

# if you are currently root
adduser adminuser
usermod -aG sudo adminuser

Then test the new user:

su - adminuser
sudo whoami

If the last command prints root, sudo works correctly.

First SSH Login to a New Server

Once basic networking and SSH are configured, you will usually switch to administering the server remotely.
Here is a typical safe flow for the first SSH login session:

1. Connect from your workstation:

   ssh adminuser@server-ip

2. Verify the host key fingerprint on the first connection and accept it if it matches your documentation.
3. Run basic checks:

   hostnamectl
   whoami
   uptime
   df -h
   free -h

If you had to log in as root for the first SSH connection (for example, on a VPS that only gives you a root account), use that session to:

• Create a regular admin user.
• Configure sudo access.
• Disable direct SSH login as root.

Disabling Direct SSH Login as root

One of the most important security steps after your first login is to stop logging in as root over SSH.
Instead, you log in as a regular user and use sudo.

To do this, edit the SSH daemon configuration file, usually /etc/ssh/sshd_config:

sudo nano /etc/ssh/sshd_config

Find the line that mentions PermitRootLogin. It might be commented out:

#PermitRootLogin prohibit-password

Change it to:

PermitRootLogin no

While you are in this file, you can also make some other basic hardening changes, for example:

• Ensure only SSH protocol 2 is used (modern default).
• Optionally limit password authentication if you plan to use SSH keys.

After editing, save the file and restart the SSH service:

sudo systemctl restart sshd    # some distros use 'ssh' instead of 'sshd'

Important: always keep your current SSH session open when restarting SSH. Open a second terminal and test a new connection before closing the original one. If you misconfigure something, you still have access to fix it.

Using SSH Keys Instead of Passwords (Optional, but Recommended)

Passwords work, but SSH keys are more secure and easier to manage over time.
The typical flow is:

1. Generate an SSH key pair on your local machine:

   ssh-keygen -t ed25519 -C "your-email@example.com"

2. Copy the public key to the server:

   ssh-copy-id adminuser@server-ip

3. Log in using the key:

   ssh adminuser@server-ip

After confirming that key-based login works, you can optionally disable password authentication in /etc/ssh/sshd_config:

PasswordAuthentication no

Again, test in a second SSH session before closing the first one.

Practical First-Login Checklist

To summarize, here is a practical checklist you can use for your next Linux server:

On the Local TTY (Console)

• Log in as the initial user or root.
• Change default passwords (root and your first user).
• Create a dedicated admin user with sudo:

  adduser adminuser
  usermod -aG sudo adminuser

• Enable and start the SSH service if needed:

  sudo systemctl enable ssh
  sudo systemctl start ssh

On the First SSH Session

• Log in as your regular admin user:

  ssh adminuser@server-ip

• Verify hostname, users, and connectivity.
• Configure SSH:
  • Disable root login: PermitRootLogin no.
  • Optionally set up key-based authentication.
• Update the system and basic packages:

  sudo apt update && sudo apt upgrade -y    # Debian/Ubuntu example

TTY vs SSH and Root vs Regular Users: The Big Picture

Your first login is more than just a password prompt. It is your first decision point as a sysadmin:

• TTY is your local, text-only console, perfect for installation, recovery, and low-level troubleshooting.
• SSH is your secure, remote door to the server for daily work.
• The root user is extremely powerful and should be used carefully and rarely.
• Regular users with sudo give you a safer and more controlled way to administer the system.

If you respect these principles from your very first login, you will develop good habits that scale from a single test machine on your desk to dozens or hundreds of production servers. The combination of TTY, SSH, and a secure user model is the foundation of professional Linux system administration.