Wetin Be SSH and How E Dey Work?

Wetin be SSH?

SSH (secure shell) na protocol wey you use take log in to computer wey dey another place and run commands for am through encrypted connection. Wetin you type dey go the remote machine, the output dey come back, and nobody wey dey monitor the network for between fit read any of dem. Rented Linux server no get screen or keyboard connected to am, so na SSH make you fit use the machine at all.

The name cover two things. SSH na the protocol, wey RFC 4251 through RFC 4254 describe. OpenSSH na the program wey implement am, and na wetin almost every Linux server and almost every laptop dey actually run. When person talk say "SSH into the server", e mean say client program ssh for the person machine dey talk to server program sshd for the other end.

Wetin SSH bin build to replace

Remote login don old pass SSH. Telnet bin open plain TCP connection go port 23 and send every byte exactly as you type am. Nothing bin dey encrypted, and your password sef dey inside am. Anybody wey fit see the traffic fit read am: person wey dey the same office network, or operator of any router wey traffic pass through. The rlogin family get the same weakness, and e trust client machine by name. This mean say e trust anything wey network claim say na that name.

Tatu Ylönen write the first SSH for 1995 for Helsinki University of Technology, after password sniffing attack happen for the university network. The design keep the useful part of telnet, na byte stream between your terminal and remote shell, then add the two things wey telnet no get answer for: encryption of the stream, and proof say the server for the other end na the one wey you mean reach.

That second part easy to overlook, and na half of wetin SSH be. Encryption by itself no go save you. Machine wey dey middle fit accept your connection, encrypt am perfectly, read everything wey you send, then pass am go the real server. SSH block this by giving every server permanent identity, wey dem dey call host key, and checking am for every single connection.

How client and server model dey work

Two programs dey. For server, sshd dey run all the time and dey wait for connections. For your machine, ssh dey make the connections. Dem na separate programs with separate configuration files, and if you mix dem up, na the most common reason why edit no get any effect.

• Server dey read /etc/ssh/sshd_config. Na there dem dey turn off password login and set the listening port.
• Client dey read /etc/ssh/ssh_config for system defaults, then ~/.ssh/config for your own settings per host.

For Debian and Ubuntu, dem dey call the service unit ssh. For RHEL, Rocky and Fedora, dem dey call am sshd. Recent Ubuntu releases dey install am with socket activation, so systemctl status ssh fit report inactive (dead) while the machine dey reachable well, because ssh.socket na the unit wey dey listen and e go start the service when request come.

Client no need be OpenSSH. PuTTY for Windows, Termius for phone, and the remote support wey editors get all dey speak the same protocol to the same sshd. Windows 10 and 11 also get the OpenSSH client, so ssh you@server go work for PowerShell without installing anything.

Why SSH dey use port 22?

Port na number wey dey tell kernel which listening program incoming connection belong to, and ports for Linux dey work the same way for every service. SSH dey use 22 because IANA assign am for 1995. Ylönen ask for free number wey dey near the protocols wey SSH write to replace: 21 na FTP, 23 na telnet, and 22 no dey used.

Because 22 na the default, everything dey assume say na am. Your Git remote, your backup script, and your provider control panel all dey try 22 first. Every automated scanner for internet dey do the same thing. New server wey password login enable go start collect lines like this for /var/log/auth.log within minutes after boot:

Failed password for invalid user admin from 203.0.113.55 port 43122 ssh2

That traffic dey happen all the time, and e no target you personally. Moving sshd go port 2222 go remove most of those lines, because the scanners dey sweep the whole internet for 22 instead of studying your server. E no make the machine harder to break into for person wey really inspect am. Treat port change as noise reduction and nothing more.

You fit watch how the server dey answer before you even log in:

nc 203.0.113.10 22

For Ubuntu 24.04, that command go print something close to SSH-2.0-OpenSSH_9.6p1 Ubuntu-3ubuntu13. The banner dey send as cleartext, before any encryption dey active, because both sides need agree on the protocol version. Press Ctrl+C to close the connection.

Wetin dey happen for the wire when you connect

The sequence below na wetin one ssh you@server dey do before you see prompt.

1. The client resolve the hostname to an IP address, then e open TCP connection to port 22.
2. Both sides send their version banner for cleartext.
3. Both sides send the list of algorithms wey dem support: key exchange, cipher, message authentication, compression. E still dey for cleartext. The strongest option wey both sides know na the one wey dem go choose.
4. Key exchange run. Current OpenSSH prefer curve25519-sha256. Both ends finally hold the same shared secret, but that secret never cross the network, so person wey record the whole conversation no fit work am out afterwards.
5. The server sign the result of that exchange with its host private key. Your client check the signature against the host public key wey e get for file. Na this step stop machine wey dey middle from impersonate your server.
6. Encryption start. chacha20-poly1305@openssh.com na the default cipher for current OpenSSH.
7. Na only now the client authenticate you, with password or key. Your username and password dey travel inside the encrypted channel.
8. The client open channel and ask for shell.

The order for that list na the full difference from telnet. Authentication happen after the channel don encrypt and after the server don prove its identity, so your password no get any moment wey e dey open for the wire.

Person wey dey monitor the network still fit learn some things. Dem go see your IP address, the server IP address, port 22, both cleartext version banners, plus the timing and approximate size of every packet. Dem no go see your username, password, commands, or their output. The hostname lookup for step 1 no be part of SSH and e usually no private, so the DNS query wey resolve your server name fit reveal which machine you dey about to reach, even though the session itself remain sealed.

Host key, and that first connection fingerprint prompt

When openssh-server dey installed, e go generate host key pairs for the machine and write dem to /etc/ssh/, for example ssh_host_ed25519_key and ssh_host_ed25519_key.pub. The private half no dey leave the server. The public half na the server identity, and na against am dem dey check the signature for step 5.

The first time you connect to new server, your client no get anything to compare with, so e go ask you:

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

The fingerprint na SHA256 hash of the host public key, printed for base64, so e short enough make you compare am by eye. When you type yes, e go write that key inside ~/.ssh/known_hosts for your own machine. Every later connection to the same address go compare the key wey server offer with the one wey dem store. When dem match, nothing go print and you go enter your prompt directly.

Dem dey call this model trust on first use, and e good make you understand wetin e cost. The first connection na the one time wey you no dey protected, because you dey accept key wey you never see before. To close that gap, get the fingerprint through another route and compare am. Most providers dey print am for the boot output wey their web console show, and you fit also print am for the server itself:

ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

That one go print the same SHA256: string wey the prompt show you. The [fingerprint] option for the prompt dey there exactly for this: paste the fingerprint wey you expect, and the client go continue only if e match wetin the server present.

For Debian and Ubuntu, known_hosts dey hashed by default, so the file dey hold lines wey start with |1| instead of hostnames wey person fit read. Run ssh-keygen -F 203.0.113.10 to find the entry for one host.

Why SSH dey talk say host key don change?

Sooner or later, you go see this long message:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!

E end with Host key verification failed., and the client refuse to connect. E also print Password authentication is disabled to avoid man-in-the-middle attacks., because to type your password inside machine wey you no know na exactly the danger wey this check dey prevent.

The message sound like emergency, but most times e no be one. The common causes na:

• You rebuild or reinstall the server, so sshd generate fresh host keys for first boot. This one na the most common reason by far.
• You destroy one VPS and create another one, and the provider give the new machine the old IP address.
• You dey connect through a forward or load balancer wey now reach different backend machine.
• Something really dey intercept the connection.

First decide which one happen before you clear anything. If you reinstall the machine ten minutes ago, the cause clear. If nothing change for your side, stop and investigate, because this warning mean say the check dey work as e suppose. Once you confirm the cause, remove the stale entry and reconnect:

ssh-keygen -R 203.0.113.10

The next connection go show the fingerprint prompt again. This one give you fresh chance to compare am with the provider console.

Password login versus key login

Password authentication dey send your password inside the channel wey encryption don already protect, and sshd dey check am against the account database, normally through PAM (pluggable authentication modules). E no need any preparation, na why provider fit give you new server wey get only root password.

The weakness no be the encryption. Na because password na short secret, you dey send am go server for every login, and machines wey no dey tire dey guess port 22 around the clock.

Public key authentication dey work differently. You create key pair for your own machine. The public half dey go inside ~/.ssh/authorized_keys for your account on the server. The private half dey stay for your laptop and dem no dey transmit am. To log in, client dey sign piece of data wey include session identifier from the key exchange, then server dey verify the signature with the public key wey e already hold. Because signed data tie to this particular session, captured signature no get value against anything else.

Watch the direction, because people dey reverse am often and e dangerous: public key dey go server, private key dey stay with you. If private key enter server, na private key wey you no fit trust again.

Key login get im own ways to fail. sshd dey ignore keys when file permissions too open, and e dey show am for server log:

Authentication refused: bad ownership or modes for directory /home/ubuntu/.ssh

The client only ever tells you Permission denied (publickey), and na the same message for twelve different causes, so learning how to read publickey error correctly worth am before dem lock you out. The practical work of creating keys, protecting dem with passphrase, and loading dem into agent dey inside SSH key management, while turning password login off without trapping yourself dey inside hardening SSH on a VPS.

SFTP, scp and port forwarding dey use the same connection

Na this idea go make the rest of SSH world clear. Authentication dey open encrypted connection, and that connection fit carry several independent channels at the same time. Shell na one kind channel among many.

• Remote shell. ssh you@server dey open session channel and ask for interactive shell.
• Single command. ssh you@server uptime dey open channel, run one command, print the output, then exit.
• SFTP. The client dey ask sshd to start its sftp subsystem, then file transfer dey run inside the same connection. SFTP na file transfer protocol wey dey use SSH, and e no get any shared design with FTP. The protocol wey be FTP with encryption added na FTPS, and e no relate to SFTP.
• scp. E dey copy files with the same login. Since OpenSSH 9.0, wey release for 2022, scp dey use SFTP protocol underneath by default.
• Port forwarding. ssh -L 8080:localhost:80 you@server dey turn port 8080 for your laptop into doorway to port 80 for the server, carried inside the encrypted connection. -R dey forward for the other direction, and -D 1080 dey turn the session into SOCKS proxy.
• Git. Remote like git@github.com:user/repo.git na SSH login wey remote side dey run command handler instead of shell.
• rsync and Ansible na SSH clients too. Dem dey open channel, run something, then read the output back.

Every item for that list dey use the same port, the same host key check, and the same credentials. Na why setting up key authentication once dey pay off immediately: each of those tools dey inherit am. Na also why the same ~/.ssh/config file wey dey shorten your logins na the file wey fit scale when you dey manage several Linux servers from one laptop.

Wetin SSH no dey do

• E no make your server secure. SSH dey protect the path go the door. The door still dey there, and people go continue to try the handle. Block repeated login attempts with fail2ban dey handle the volume, while key-only authentication remove the thing wey dem dey guess.
• E no protect you from your own machine. Anybody wey get access to your laptop get your private key and your loaded agent.
• E no hide say you dey use SSH. The port number and the cleartext version banner dey announce am.
• E no cover wetin happen before the connection exist. The name lookup and your decision about which address to trust both happen first.

Wia to go from here

If you get new server wey dey open for provider console now, the useful order no dey change. Enter am, create normal user, install your key, then close the easy ways wey people fit use enter am. The first ten minutes for new VPS dey explain the order from start to finish, while wetin VPS actually be go explain the machine underneath if the terms still new to you. After that, read the posts about keys and hardening, for that order.

FAQ

Wetin SSH mean?

SSH mean secure shell. Na protocol wey dey allow you log in to remote computer and run commands for am through encrypted connection, as RFC 4251 reach RFC 4254 define am. OpenSSH na the implementation wey almost everybody dey use: the ssh client for your machine, and the sshd server for the remote one. E replace telnet, wey dey send everything, including passwords, across network as plain text.

Why SSH dey use port 22?

IANA assign port 22 to SSH for 1995, beside FTP for 21 and telnet for 23, the protocols wey SSH dey replace. Nothing force that number: Port for /etc/ssh/sshd_config fit change am for the server, and ssh -p fit choose another one for the client. Because 22 na the default, automated scanners dey knock for am all the time. Na why fresh server /var/log/auth.log dey fill with Failed password for invalid user lines. Changing the port reduce that noise, but e no add any real protection.

Wetin I suppose do when SSH warn say host key don change?

Find out the cause before you clear anything. The common reason harmless: dem rebuild the server, so sshd generate new host keys, or dem give new machine the old IP address. If you know say dem rebuild the machine, run ssh-keygen -R <host> to remove the stored key. Connect again, then compare the fingerprint wey e show you with the one wey your provider console report. If nothing change for your side, no connect and no type your password. OpenSSH already dey refuse password authentication for this situation for that exact reason.

SFTP and scp different from SSH?

Dem dey run on top of am. After you authenticate, the SSH connection fit carry several channels, and shell na only one of dem. SFTP na file transfer protocol wey dey use the sftp subsystem of sshd through that same connection, and scp don dey use SFTP protocol underneath since OpenSSH 9.0. Port forwarding and Git over SSH na channels for the same connection too. All of dem dey use the same port, the same host key check, and the same login. Note say SFTP no be FTP wey add encryption; that one na FTPS, and e be separate protocol.

Key authentication really better pass password?

Yes, for any server wey internet fit reach. Password na short secret wey you dey give server for every login, and automated clients dey guess port 22 continuously. With key pair, the private half no ever leave your machine: client dey sign data wey connect to the current session, and server dey check that signature against the public key for ~/.ssh/authorized_keys. Recorded signature no fit replay against another server. Protect the private key with passphrase, because key file wey no get passphrase na working login for anybody wey copy am.