SSH into your Linux lab and recognize both sides

Your Linux VM is running in its own window. You want to ask it a question from your usual terminal instead: run a command on that machine and bring the answer back. SSH makes that connection and encrypts what travels between the two computers.

Before the command runs, each side needs to recognize something. Your computer checks which server it reached. The server checks whether a credential is allowed into your account. Those checks share a connection, but they answer different questions. Keeping them separate makes the first login easier to understand.

This illustrative practice exercise uses the disposable Ubuntu VM you control, its trusted console window and an approved private route from your host computer. Have the actual guest username and reachable address ready. Do not open an Internet-facing firewall for the lesson. If the VM manager offers only console access, prepare and study the keys now, and wait for an approved route before connecting.

Recognize the machine before connecting to it

At the trusted VM console, install the SSH server and display the fingerprint of its ED25519 host key:

sudo apt update
sudo apt install openssh-server
sudo systemctl status ssh --no-pager
sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

The host key identifies the server. Its fingerprint is a compact representation of that key, small enough to compare without reading the whole thing. Save the fingerprint from this console, where you know which VM is in front of you. It will give you something trusted to compare with the key presented over the network.

Find the address reachable from your host using the VM manager’s documented network configuration. A plausible address copied from an example might lead nowhere, or to a machine that is not your guest.

Make a login key that belongs only to this lab

On the host computer, inspect ~/.ssh/dispatch_lab_ed25519 and ~/.ssh/dispatch_lab_ed25519.pub, including any symbolic-link entries at those paths. If either name already exists, stop. Do not overwrite, delete or reuse it for this exercise; it may belong to earlier work. If you cannot establish that both names are unused, stop rather than guess.

Only with both names confirmed unused, create the lab’s dedicated key. If the tool nevertheless asks to overwrite a file, decline and cancel. Do not continue with that existing key.

mkdir -p ~/.ssh
chmod 700 ~/.ssh
ssh-keygen -t ed25519 -f ~/.ssh/dispatch_lab_ed25519

Choose a passphrase when prompted. The command creates two files: the private dispatch_lab_ed25519 and its public partner ending in .pub. The client proves that it holds the private key; the server checks that proof using the public key. The private key itself does not travel to the server.

On the host, run cat ~/.ssh/dispatch_lab_ed25519.pub and copy that one public-key line. Then use the trusted VM console to log in as the ordinary guest account you intend to reach. Run:

mkdir -p ~/.ssh
chmod 700 ~/.ssh
cat >> ~/.ssh/authorized_keys

Paste the public line, press Enter, then Ctrl+D to end the input. The >> appends it without replacing keys already in the file. Run chmod 600 ~/.ssh/authorized_keys, followed by ls -ld ~/.ssh ~/.ssh/authorized_keys. The directory and file should belong to that guest user. If not, have the approved administrator correct ownership before you continue.

The guest can now recognize your login credential without having your private key. Keep that private file on the client and out of tickets, articles and chats. Its passphrase protects the stored key; it does not establish that a server you meet over the network is the right server.

We now have two public keys doing two jobs. The VM’s host key identifies the machine. Your public login key lets that machine check a credential for a particular account. Their filenames may look related, but one cannot stand in for the other.

Compare the introduction with the machine you know

Use the actual guest username and address in place of these placeholders:

ssh -i ~/.ssh/dispatch_lab_ed25519 LAB_USER@LAB_ADDRESS

On the first connection, compare the displayed ED25519 fingerprint with the one saved from the trusted console. Accept only a match. SSH records the accepted host in known_hosts, allowing a later connection to notice if that address presents a different key.

A rebuilt VM may legitimately have a new host key. So may a different machine now answering at that address. Return to the trusted console and determine which happened before updating the stored entry. Disabling host-key checking would remove the comparison that helps distinguish those cases.

A failed login still tells you where it got to

A timeout suggests looking at the route or filtering. “Connection refused” suggests an endpoint without the expected listener. “Permission denied (publickey)” means an SSH server was reached, but login authentication failed. These messages locate a stage to investigate; they are not complete diagnoses by themselves.

ssh -v shows more of the client’s exchange, while sudo journalctl -u ssh at the guest shows server messages. Keep usernames, addresses and key paths out of public reports. Start from the last successful stage rather than replace keys to solve a connection that never reached authentication.

Once logged in, run hostname and id. They should identify the expected guest and account. Exit, then try ssh -i ~/.ssh/dispatch_lab_ed25519 LAB_USER@LAB_ADDRESS hostname with your real values. Instead of leaving a prompt open, this connection runs one command as the remote account, returns the output and ends.

Keep access tied to the lab’s lifetime

Record the trusted host fingerprint, network route and authentication method without copying key material into the note. When retiring the VM, remove its lab public key. Delete the dedicated private key only after confirming that nothing else uses it.

A production environment may add gateways, certificates or organizational identity controls. Here the returned hostname completes a smaller, visible journey: your client recognized the machine, that machine accepted a credential for the intended account, and the account ran a command. You can now explain what happened between typing ssh and seeing that answer.

The SSH client, keys and server

The OpenSSH manuals cover ssh, ssh-keygen and authorized keys. Ubuntu’s OpenSSH server documentation explains the distribution’s service setup.