1. What is SSH?
Simply put, SSH is a network protocol used for encrypted logins between computers.
If a user logs in to another remote computer from the local computer using the SSH protocol, we can assume that this login is secure, and even if it is intercepted midway, the password will not be leaked.
In the earliest days, Internet communications were all plaintext communications. Once intercepted, the content would be exposed. In 1995, the Finnish scholar Tatu Ylonen designed the SSH protocol, which encrypted all login information and became a basic solution for Internet security.
It should be pointed out that SSH is only a protocol, and there are multiple implementations, both commercial and open source. The implementation for this article is OpenSSH , which is free software and is widely used.
Also, this article only discusses the usage of SSH in the Linux Shell. If you want to use SSH in Windows system, another software PuTTY will be used , which needs to be introduced in another article.
Second, the most basic usage
SSH is mainly used for remote login. Assuming that you want to log in to the remote host host as the user name user, you only need a simple command.
$ ssh user@host
If the local user name is the same as the remote user name, the user name can be omitted when logging in.
$ ssh host
The default port of SSH is 22, that is, your login request will be sent to port 22 of the remote host. This port can be modified using the p parameter.
$ ssh -p 2222 user@host
The above command indicates that ssh directly connects to port 2222 of the remote host.
3. Man-in-the-middle attack
SSH is secure because it uses public key encryption.
The whole process is as follows: (1) The remote host receives the user's login request and sends its public key to the user. (2) The user uses this public key to encrypt the login password and send it back. (3) The remote host uses its own private key to decrypt the login password. If the password is correct, the user is allowed to log in.
The process itself is safe, but there is a risk when implementing it: if someone intercepts the login request, impersonates a remote host, and sends a fake public key to the user, it will be difficult for the user to distinguish the authenticity from the fake. Because unlike the https protocol, the public key of the SSH protocol is not notarized by a certificate authority (CA), that is, it is signed by itself.
It is conceivable that if an attacker is inserted between the user and the remote host (such as in a public wifi area), with a fake public key, to obtain the user's login password. Then use this password to log in to the remote host, then the security mechanism of SSH is gone. This risk is known as a " Man-in-the-middle attack".
How does the SSH protocol respond?
4. Password login
If you log in to the other host for the first time, the system will show the following prompt:
$ ssh user@host
The authenticity of host 'host (12.18.429.21)' can't be established.
RSA key fingerprint is 98:2e:d7:e0:de:9f:ac:67:28:c2:42:2d:37:16:58:4d.
Are you sure you want to continue connecting (yes/no)?
The meaning of this passage is that the authenticity of the host cannot be confirmed, only its public key fingerprint is known. Do you still want to continue the connection?
The so-called "public key fingerprint" means that the length of the public key is long (the RSA algorithm is used here, up to 1024 bits), which is difficult to compare, so MD5 calculation is performed on it to turn it into a 128-bit fingerprint. In the above example it is 98:2e:d7:e0:de:9f:ac:67:28:c2:42:2d:37:16:58:4d, and it is much easier to compare.
A natural question is, how does the user know what the public key fingerprint of the remote host should be? The answer is that there is no good way, the remote host must post the public key fingerprint on its own website so that users can check it by themselves.
Suppose that after a risk assessment, the user decides to accept the remote host's public key.
Are you sure you want to continue connecting (yes/no)? yes
A prompt will appear in the system, indicating that the host has been recognized.
Warning: Permanently added 'host,12.18.429.21' (RSA) to the list of known hosts.
Then, you will be asked to enter a password.
Password: (enter password)
If the password is correct, you can log in.
When the remote host's public key is accepted, it is stored in the file $HOME/.ssh/known_hosts. The next time you connect to this host, the system will recognize that its public key has been saved locally, thus skipping the warning part and directly prompting for the password.
Each SSH user has its own known_hosts file, and the system also has such a file, usually /etc/ssh/ssh_known_hosts, which holds the public keys of some remote hosts that are trusted by all users.
5. Public key login
To log in with a password, you have to enter the password every time, which is very troublesome. Fortunately, SSH also provides public key login, which can save the step of entering a password.
The so-called "public key login", the principle is very simple, that is, the user stores his public key on the remote host. When logging in, the remote host sends a random string to the user, and the user encrypts it with his private key and sends it back. The remote host decrypts with the pre-stored public key. If successful, it proves that the user is trusted and allows the login shell directly without requiring a password.
This method requires users to provide their own public key. If there is no ready-made, you can generate one directly with ssh-keygen:
$ ssh-keygen
After running the above command, a series of prompts will appear in the system, and you can press Enter all the way. One of the questions is whether to set a passphrase for the private key. If you are worried about the security of the private key, you can set one here.
After the operation is over, in the $HOME/.ssh/ directory, two new files will be generated: id_rsa.pub and id_rsa. The former is your public key and the latter is your private key.
Then enter the following command to transfer the public key to the remote host host:
$ ssh-copy-id user@host
Well, from now on when you log in again, you don't need to enter a password.
If it still doesn't work, open the file /etc/ssh/sshd_config of the remote host, and check whether the "#" comment in front of the following lines is removed.
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
Then, restart the ssh service on the remote host.
// ubuntu system
service ssh restart// debian system
/etc/init.d/ssh restart
Six, authorized_keys file
The remote host saves the user's public key in the $HOME/.ssh/authorized_keys file in the logged-in user's home directory. The public key is just a string, just append it to the end of the authorized_keys file.
Instead of using the ssh-copy-id command above, use the following command to explain the process of saving the public key:
$ ssh user@host 'mkdir -p .ssh && cat >> .ssh/authorized_keys' < ~/.ssh/id_rsa.pub
This command consists of multiple statements, which are broken down in turn: (1) "$ ssh user@host", which means logging in to the remote host; (2) mkdir .ssh && cat >> .ssh/authorized_keys in single quotes , indicating the command executed on the remote shell after login: (3) The function of "$ mkdir -p .ssh" is to create a .ssh directory in the user's home directory if it does not exist; (4) 'cat >> The function of .ssh/authorized_keys' < ~/.ssh/id_rsa.pub is to append the local public key file ~/.ssh/id_rsa.pub redirection to the end of the remote file authorized_keys.
After writing the authorized_keys file, the setting of public key login is complete.