2 of 3

Archives and Remote LoginLesson 2 of 3

Logging in to remote systems with SSH

Open a shell or run one command on another machine, and read host key warnings instead of ignoring them.

  • ssh
  • ssh -p
  • ssh user@host cmd
  • ssh -v
  • ~/.ssh/known_hosts
  • ssh-keygen -R

35 min5 exercises

After this lesson you can

  • Log in to a remote system as a given user, on the default or another port.
  • Run a single command remotely and use its output locally.
  • Understand the first-connection host key prompt and a changed-key warning, and fix the latter correctly.

The idea

SSH gives you an encrypted shell, or a single command, on another machine. You authenticate (a password for now, keys later in this course), and the connection is encrypted so nobody on the path can read or change it.

The first time you connect to a host, ssh shows its host key fingerprint and asks you to trust it. It stores the key in ~/.ssh/known_hosts. On every later connection ssh compares the key: if it changed, someone may be impersonating the server, so ssh stops. That prompt is a security check, not an annoyance.

ssh [options] [user@]host [command]

If you leave out user@, ssh uses your current user name. If you add a command, ssh runs it remotely and returns, with the output on your screen (or in your redirection).

Try it

ssh alex@node2
hostname
exit
The authenticity of host 'node2 (192.0.2.12)' can't be established.
ED25519 key fingerprint is SHA256:Qq3R0b8m...Zk.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'node2' (ED25519) to the list of known hosts.
alex@node2's password:
node2
logout
Connection to node2 closed.
ssh alex@node2 uptime > ~/lab/node2-uptime.txt
cat ~/lab/node2-uptime.txt
 10:42:07 up 3 days,  1:12,  1 user,  load average: 0.00, 0.01, 0.00

Another port, and when it fails

ssh -p 2222 alex@node2
nc -zv node2 2222
Ncat: Version 7.92 ( https://nmap.org/ncat )
Ncat: Connected to 192.0.2.12:2222.
Ncat: 0 bytes sent, 0 bytes received in 0.01 seconds.

When a login fails, ssh -v alex@node2 prints the negotiation step by step. Add more v (-vvv) for more detail. The common causes: wrong user, a firewall blocking port 22, sshd not running (systemctl status sshd on the server), or a changed host key.

A changed host key

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Offending ED25519 key in /home/alex/.ssh/known_hosts:3
Host key verification failed.

If you know why (a reinstall, a new server on the same IP), remove just that entry and check the new fingerprint with the machine’s owner before you accept it:

ssh-keygen -R node2
# Host node2 found: line 3
/home/alex/.ssh/known_hosts updated.
Original contents retained as /home/alex/.ssh/known_hosts.old

Going further

ssh -X forwards graphical programs, ssh -L 8080:localhost:80 node2 forwards a local port to the server, and ssh -J jump node2 connects through a jump host. You can keep per-host settings (user, port, key) in ~/.ssh/config, which the SSH Key Authentication skill covers. On the server side, sshd is the service and /etc/ssh/sshd_config is its configuration.

Practice

0 of 5 done

Do these on your own system. They get harder. Check each result, then tick it off.

  1. Warm-up

    Log in and prove where you are

    Log in from node1 to node2 as alex (use the name or IP of your second machine). Print the host name there, then log out.

    Check your result

    hostname prints node2 (or your second machine's name) and exit returns you to node1.

    Hint

    ssh alex@node2. Answer yes to the host-key question the first time.

    Solution
    ssh alex@node2
hostname
exit
  2. Practice

    Run one command, keep the output

    Without opening an interactive shell, run uptime on node2 and store its output in ~/lab/node2-uptime.txt on node1.

    Check your result

    cat ~/lab/node2-uptime.txt prints an uptime line from node2, and you were never given a remote prompt.

    Hint

    Everything after the host name is run remotely. The redirection happens locally.

    Solution
    ssh alex@node2 uptime > ~/lab/node2-uptime.txt
cat ~/lab/node2-uptime.txt
  3. Practice

    Read the known_hosts file

    After your first connection, find the entry for node2 in ~/.ssh/known_hosts. Show its key type and the fingerprint that ssh would display, then remove the entry and reconnect to see the prompt return.

    Check your result

    ssh-keygen -F node2 shows the stored line. After ssh-keygen -R node2 the next ssh node2 asks about the authenticity of the host again.

    Hint

    ssh-keygen -F host finds an entry, ssh-keygen -lf ~/.ssh/known_hosts prints fingerprints, ssh-keygen -R host removes it.

    Solution
    ssh-keygen -F node2
ssh-keygen -lf ~/.ssh/known_hosts
ssh-keygen -R node2
ssh alex@node2 true
  4. Practice

    Reach a service on another port

    Suppose sshd on node2 listens on port 2222. Write the command that connects as alex, then show how you would find out, from node1 and without logging in, whether the port is open.

    Check your result

    ssh -p 2222 alex@node2 is the connection command. nc -zv node2 2222 (or ssh -v -p 2222 alex@node2) reports succeeded or Connection refused.

    Hint

    -p is the port for ssh (capital -P for scp). nc -z only tests the connection.

    Solution
    ssh -p 2222 alex@node2
nc -zv node2 2222
  5. Challenge

    Handle a changed host key without disabling the check

    You reinstalled node2, and ssh now stops with WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!. Explain what the warning protects you from, then fix it the correct way for this one host without turning off host key checking, and reconnect.

    Check your result

    After removing only node2's old entry and accepting the new key (after you confirm the fingerprint with whoever runs the machine), ssh alex@node2 hostname works.

    Hint

    ssh-keygen -R node2 removes just that host's entry. Never use StrictHostKeyChecking no as a habit.

    Solution
    ssh-keygen -R node2
ssh alex@node2 hostname