I challenge you to read the whole thing, as I am sure you will better understand how SSH works. Let’s go.
Here are important keywords that you need to understand before reading further. Quick note here, just read this part where I explain what those terms mean, and you do not need to understand, like how they work. Just understand the concept of what I am talking about here:
Cryptography’s main purpose is to encode data in order to hide it or keep private. In cryptography, plain text or clear text is text that can be read by humans or machines. That plain text is then converted to what is called ciphertext, in order to prevent other people and machines from reading it. Now, process of converting plaintext to ciphertext is called encryption, and converting ciphertext to plaintext is called decryption.
Now, in order to encrypt something, that is convert it to ciphertext, there must be a way to make that simple text encoded into something totally unreadable. For that, some smart people created cryptographic algorithms that use special data called keys to encrypt and decrypt that data. You really don’t need to understand how is this done, trust me. I used to bang my head all the time, trying to figure out how the heck those keys work, what they do, can really someone un-hash my data and read it like plain text? Don’t think about these things, just know that it works and forget about rest.
Private and public keys – We mentioned above that cryptographic alghoritms use keys to encrypt and decrypt data. Alright, now there are two types of keys: private keys, and private/public keys:
Private keys – Here, we have just two private keys. Now, as we know, in order for two parties to communicate, you must share your private key with him, and he has to share his private key with you. That’s just how this works. You must have other parties private key, in order to decrypt his data. So, two keys are needed – one for each machine on both sides of the connection. The disadvantage, or security risk here, is that you need to share your private key with someone, and someone needs to share his private key with you, in order for you do read his encrypted data using his private key, and also in order for him to read yours’ encrypted data using your private key. Hope that makes sense.
Public/private keys – Things change here a bit. There is still a situation with private keys, however, you have your extra public key, and on the other side of the connection, he has his public key. Now, you and he will keep your private keys and never share them with anyone. However, you give him your public key, and he gives you his public key. When he wants to send you data, he encrypts that data with your public key, and sends it to you. Now, you only can decrypt that data with your private key. Hope this makes sense too. Same thing happens when you want to send data to him. You encrypt data with his public key, send that gibberish to him, and he can decrypt it with his private key. So, it is crucial to have someone’s public key in order to send him a message. SSH uses private/public keys (often called asymmetric keys), and we are going to discuss how it works.
SSH uses private/public key pairs (asymmetric keys) for its encryption. When an SSH connection is established between two systems, each sends its public key to the other. On CentOS you would install openssh, openssh-client, openssh-server packages, and on Debian systems install openssh-server and openssh-client packages. The OpenSSH application keeps track of all previously connected hosts in the ~/.ssh/known_hosts file. Inside that file, you will find all public keys that this system has.
When you login to another host first time, an error message will pop-up. It is normal, as it says that this remote host does not have your public key inside ~/.ssh/known_hosts file, and you agree to add it there by typing “yes”.
Connection to remote host is straightforward:
# ssh 192.168.100.100
If you want to execute command on the remote system, type this:
# ssh 192.168.100.100 "ls /home"
Main configuration files for SSH:
- ~/.ssh/config – Contains SSH client configurations. If you want to modify individual user’s connections to a remote system, edit this file.
- /etc/ssh/ssh_config – Contains SSH client configurations. If you want to modify settings for all users, modify this file.
- /etc/ssh/sshd_config – Contains SSH daemon (sshd) configurations. If you need to modify incoming connection requests, modify this file on the server side. Important directives or keywords inside this file are listed: AllowTcpForwarding allows SSH port forwarding, ForwardX11 allows X11 forwarding, PermitRootLogin allows users to login as root, Port sets the port number for sshd on which it listens for incoming connections.
Generating SSH keys
As we said, keys are inside .ssh directory inside home directory of a user. Also, we mentioned that SSH needs two keys to work. The way to create those keys is with single command ssh–keygen. But first, let me write the most important algorithms you need to know:
- rsa (Rivest-Shamir-Adleman) – oldest type, highly supported
- dsa (Digital Signature Algorithm) – deprecated
- ecdsa (Ellipticall Curve Digital Signature Algorithm)
- ed25519 – variation of ecdsa that provides better security than dsa and ecdsa.
Full names are not important. We need to know abbreviations of those algorithms. And now, to create one of those keys, we use ssh-keygen command with -t argument to specify type, and -f argument to save to a file.
Keys are stored there (in /home/aldin/.ssh directory), and we can share public one with SSH server. Steps to be made are shown below, and after that you have connected two systems which can encrypt/decrypt data between one another:
- Login to client system
- Generate pair of keys
- Transfer public key to remote server
- Login to SSH server
- Add public key in ~/.ssh/authorized_keys file
Tunneling and securing SSH
Another way to provide security through SSH is via SSH port forwarding, or SSH tunneling. SSH port forwarding allows you to redirect a connection from a particular network port to port 22, where SSH service is waiting for connections.
There are few things to do to enhance SSH security:
- Use different port for SSH than the default port 22 – Just modify the /etc/sshd_config file and change Port to something else. This way, network scanners will see port 22 as closed but our custom port, let’s say we configured it to be 2202, is listening for SSH connections and with port forwarding, connection is internally forwarded to our port 22.
- Disable root logins via SSH – Edit the /etc/ssh/sshd_config file, and set PermitRootLogin to no, reload the service and we disabled anyone to login as root on this remote server.
- Ensure OpenSSH protocol 2 is in use – in /etc/sshd_config file, find Protocol directive and set it to 2, then reload the service.
This was just introduction post on SSH and public/private key pairs. Please, click here to read more about SSH, how to connect to remote host, how to configure SSH and much more.