The Secure Shell Protocol (SSH) is used in SSH File Transfer Protocol, also known as secure file transfer protocol (SFTP), but it can also be used on its own for secure remote login from one computer to another. SSH was developed by Tatu Ylönen in 1995 and published as freeware for anyone to use.
What is SSH used for?
Before SSH was developed, people were connecting over unsecured networks and had no way to secure them. SSH solves this problem by encrypting the connection between two machines.
SSH can also be used to
- Authenticate the client and server and generate a session key in SFTP file transfers.
- Keep a transmission control protocol (TCP) connection alive with commands so that you can reuse the TCP connection with new SSH connections.
- Remember private keys during a session so you only enter a passphrase once for all windows and applications.
- Connect to insecure/unsecure applications and systems.
- Get to devices on a private network that you need to access by using SSH as a proxy.
How does SSH work?
SSH encrypts data so that someone trying to intercept the message cannot read what’s being sent. They only know that data is being transmitted across and how frequently it’s happening.
- TCP connection is established through a three-way handshake.
- Sending computer sends a message called a SYN.
- Receiving computer sends back an acknowledgement message called a SYN ACK.
- Sending computer sends an ACK RECEIVED MESSAGE to the receiving message.
- The client verifies the server.
- The client and server generate a session key together.
- The server authenticates the client.
- Public key – Encrypts data and can be shared with anyone.
- Private key – Decrypts data and cannot be shared with anyone.
- The data is broken down into packets that have message authentication codes (MACs).
- The packets are encrypted and sent.
- At the receiving end, the data is decrypted and put back together.
TCP is a connection-oriented protocol, which means that both computers verify a connection before data is sent. This keeps data from being sent out of order or in pieces.
TCP verifies the connection with a three-way handshake.
Here’s how it works:
After the handshake is complete, data is delivered. If data doesn’t arrive, TCP will make sure that it is re-sent.
If the client is accessing the server for the first time, the client has to manually authenticate the server by verifying its public key.
If the client isn’t accessing the server for the first time, the client’s known_hosts file already has the server’s public key. The server is authenticated.
The client and server agree on a session key that will be used to encrypt and decrypt the data for that session. Because a different session key is used each time, anyone who figures out one session key can only read data from that session. They wouldn’t be able to read data from past or future sessions.
The client is authenticated with an SSH key pair. The pair consists of two keys:
The server generates a random number, uses the client’s public key to encrypt the number and sends it to the client.
The client uses its private key to decrypt the message and get the server’s random number. The client calculates an MD5 hash of the random number and sends it back to the server.
The server calculates an MD5 hash of the random number and compares it with the client’s value. If they match, the client is authenticated.
A MAC is exactly what it sounds like. It confirms that the message is coming from the stated sender and that it hasn’t been changed in transit.
Is SSH over TCP or UDP?
SSH uses TCP, not UDP (User Datagram Protocol). Unlike TCP, UDP is a connectionless protocol, which means it doesn’t make sure the recipient is ready to receive files before sending them. As a result, data can arrive out of order, in pieces or not at all.
Although SSH typically uses TCP, it doesn’t have to. It can also be run over an RS-232 connection.
Is SSH more secure than telnet?
Yes. Any data transferred with telnet (port 23) is transmitted in clear text, which means anyone with a packet sniffer can read the data and steal it. SSH encrypts data so it cannot be read or stolen by anyone other than the sender and the recipient.
Does SSH use TLS or SSL?
SSH doesn’t use Transport Layer Security (TLS) protocols or Secure Socket Layer (SSL).
To be clear, TLS is the successor to SSL, so they’re considered synonyms. TLS/SSL is used for encryption in the HTTPS and FTPS protocols, not the SFTP protocol.
What is the difference between SSH and SSL?
The biggest difference between SSH and TLS/SSL is in what they’re used for. SSH encrypts a connection between two computers and can execute commands. TLS/SSL encrypts data in transit as well, but it’s typically in a website browser with HTTPS. You can’t issue commands with TLS/SSL.
Here are some other differences between SSH and TLS/SSL:
| SSH | TLS/SSL |
|---|---|
| Based on network tunnels | Based on digital certificates |
| Runs on port 22 | Runs on port 443 |
| Requires client and server to authenticate | Only requires authentication on server side |
| Cryptographic network protocol | Security protocol |
What is the difference between SSH and FTP?
The biggest difference between SSH and FTP is that SSH encrypts data and FTP doesn’t. FTP sends data, usernames and passwords unencrypted, which makes it vulnerable to a man-in-the-middle attack. SSH encrypts the data being sent so that no one can read and steal it.
Is SSH faster than FTP?
SSH is slower than FTP because it encrypts data and has other security measures in place. Data transfer speed can also be affected by the speed of each machine’s disk, the speed of the network, network tuning and machine tuning.
Diving into SFTP
One of the most common use cases of SSH is in SFTP. To see a detailed guide about how SFTP works, visit our What is SFTP page.
