SSH is a remote encryption processing program based on Linux or on Windows. It makes your computer more secure and reduces the possibility of computer information being intercepted by others. When you download Github Desktop, Ubuntu, openSUSE Leap 42 and other software on your computer, these softwares will have ssh client installed by default and do not need to be installed again.
Recently, I saw a very useful SSH usage and basic commands. The content is detailed and hereby shared. The text mainly introduces SSH remote login, SSH data transmission, scp cross-machine remote copy, binding local port and other operations, which will be very useful in protecting personal computer information in the future.
Original link: https://blog.csdn.net/pipisorry/article/details/52269785
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.
SSH is just 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. Only the usage of SSH in the Linux Shell is discussed here. If you want to use SSH in Windows system, you will use another software PuTTY, which needs to be introduced in another article.
Man-in-the -middle attacks
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
It is suggested that the public key of the SSH protocol is not notarized by a certificate authority (CA), that is to say, 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".
ssh installation
SSH sub-client openssh-client and openssh-server
If you just want to log in to the SSH of other machines, you only need to install openssh-client (Ubuntu has a default installation, if not, sudoapt-get install openssh-client). If you want to open the SSH service on this machine, you need to install openssh-server.
Ubuntu has the ssh client installed by default.
#Configure ssh#
echo -e "\033[31;1m ******************************* \033[0m"
echo -e "\033[31;1m ************安装和配置ssh************ \033[0m"
sudo apt-get install -y openssh-server 1> /dev/null
sudo sed -i 's/UsePAM no/UsePAM yes/g' /etc/ssh/sshd_config
sudo sed -i '8a /etc/init.d/ssh start' /etc/profile
sudo /etc/init.d/ssh start
ps -e | grep ssh
echo -e "\033[31;1m ssh授权 \033[0m"
cd ~/.ssh/
ssh-keygen -t rsa
cat ./id_rsa.pub >> ./authorized_keys
$ ps -e|grep ssh
2151 ? 00:00:00 ssh-agent
5313 ? 00:00:00 sshd
ssh-agent indicates that ssh-client is started, and sshd indicates that ssh-server is started.
If sshd is missing, the ssh service is not started or installed.
SSH basic usage
SSH remote login
password 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 For example: ssh [email protected]
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.
If you log in to the other host for the first time, the following prompt will appear:
$ 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)?
This sentence means that the host cannot be confirmed The authenticity of the host, only know its public key fingerprint, ask 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, it will ask for 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.
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 one, you can directly use ssh-keygen to generate one:
$
After ssh-keygen runs 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.
At this time, enter the following command to transfer the public key to the remote host host:
$ ssh-copy-id user@host
Well, from now on, you do not need to enter a password when you log in again.
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
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 The command /id_rsa.pub
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 >> in single quotes .ssh/authorized_keys, indicating the command executed on the remote shell after login: (3) The function of "$ mkdir -p .ssh" is to create one if the .ssh directory in the user's home directory does not exist; (4) The function of 'cat >> .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.
[ SSH principle and application (1): remote login ]
Use ssh to run programs in the remote background without interruption
The program or service running after Linux closes ssh (closes the terminal, etc.) automatically stops, such as python3 a.py &.
Solution: Use the nohup command to let the program continue to run in the background when the program closes the window (switches the SSH connection).
nohup python3 a.py &
[ linux process management and SELinux ]
SSH remote operation
SSH data transfer
SSH can be used not only for remote host login, but also to perform operations directly on the remote host.
$ ssh user@host 'mkdir -p .ssh && cat >> .ssh/authorized_keys' < ~/.ssh/id_rsa.pub
The part between the single quotation marks indicates the operation performed on the remote host; the following input redirection, Indicates that data is sent to the remote host via SSH.
That is to say, SSH can establish command and data transmission channels between users and remote hosts, so many things can be done through SSH.
See a few examples below.
[Example 1]
Copy all files under the $HOME/src/ directory to the $HOME/src/ directory of the remote host.
$ cd && tar czv src | ssh user@host 'tar xz'
[Example 2]
Copy all files under the $HOME/src/ directory of the remote host to the user's current directory.
$ ssh user@host 'tar cz src' | tar xzv
[Example 3]
Check whether the process httpd is running on the remote host.
$ ssh user@host 'ps ax | grep [h]ttpd'
lz recommends using scp for remote copy:
scp cross-machine remote copy
scp is short for secure copy, a command used to copy files remotely under Linux. Similar commands to it are cp, but cp only copies locally and cannot cross servers, and scp transmission is encrypted. It may affect the speed a little. To copy files between two hosts, you must have the copy execution account and operation permission of the two hosts at the same time.
scp command parameters
- -1 force the scp command to use the protocol ssh1
- -2 Force the scp command to use the protocol ssh2
- -4 forces the scp command to use only IPv4 addressing
- -6 forces the scp command to use only IPv6 addressing
- -B use batch mode (do not ask for transfer password or phrase during transfer)
- -C allows compression. (pass the -C flag to ssh, thus turning on compression)
- -p Keep the modification time, access time and access rights of the original file.
- -q Do not display the transfer progress bar.
- -r Recursively copies entire directories.
- -v Display output in verbose mode. scp and ssh(1) will display debug information for the entire process. This information is used to debug connection, authentication and configuration issues.
- -c cipher Encrypt data transmission with cipher, this option will be passed directly to ssh.
- -F ssh_config Specifies an alternative ssh configuration file, this parameter is passed directly to ssh.
- -i identity_file Read the key file used during transfer from the specified file, this parameter is passed directly to ssh.
- -l limit Limit the bandwidth that users can use, in Kbit/s.
- -o ssh_option If you are used to using the parameter passing method in ssh_config(5),
- -P port Note that it is an uppercase P, and port is the port number used to specify data transmission
- -S program Specifies the program to use when encrypting transfers. This program must be able to understand the options of ssh(1).
There are generally six ways to use scp to
copy remote files locally: (copy remote files to local)
scp [email protected]:/val/test/test.tar.gz /val/test/test.tar.gz
Copy local files remotely: (copy the local files to the remote host)
scp /val/test.tar.gz [email protected]:/val/test.tar.gz
copy the remote directory locally: (copy the remote Copy the directory to the local)
scp -r [email protected]:/val/test/ /val/test/
remote copy the local directory: (copy the local directory to the remote host)
scp -r ./ubuntu_env/ root @192.168.0.111:/home/pipi
pika:/media/pika/files/machine_learning/datasets$scp -r SocialNetworks/ [email protected]:/media/data/pipi/datasets
Copy the remote file to the specified directory locally: (Copy the remote file to the local)
scp [email protected]:/val/test/test.tar.gz /val/test/
Copy the local file to the specified directory remotely: ( Copy the local file to the remote host)
scp /val/test.tar.gz [email protected]:/val/
ps: When scp copies files, only the server address is specified without the path, and where is it copied by default???
[ 12 scp command chestnuts to transfer files ]
[ scp cross-machine remote copy ]
bind local port
Since SSH can transmit data, we can change all unencrypted network connections to SSH connections to improve security.
Suppose we want the data on port 8080 to be sent to the remote host through SSH, the command is written like this:
$ ssh -D 8080 user@host
SSH will create a socket to monitor the local port 8080. Once data is sent to that port, it is automatically transferred over the SSH connection to the remote host. It is conceivable that if port 8080 was originally an unencrypted port, it will now become an encrypted port.
local port forwarding
Sometimes, binding a local port is not enough, you must also specify the destination host for data transfer, resulting in a point-to-point "port forwarding". In order to distinguish the "remote port forwarding" later, we call this situation "local port forwarding" (Local forwarding).
Assume that host1 is the local host and host2 is the remote host. For various reasons, there is no communication between the two hosts. However, there is another host3, which can connect to the first two hosts at the same time. Therefore, the natural idea is to connect host1 to host2 through host3.
We execute the following command on host1:
$ ssh -L 2121:host2:21
The L parameter in the host3 command accepts a total of three values, namely "local port: target host: target host port", which are separated by colons. The meaning of this command is to specify SSH to bind the local port 2121, and then specify host3 to forward all data to port 21 of the target host host2 (assuming that host2 runs FTP, the default port is 21).
In this way, as long as we connect to port 2121 of host1, it is equivalent to connecting to port 21 of host2.
$ ftp localhost:2121
"Local port forwarding" makes it seem like a secret tunnel for data transmission between host1 and host3, so it is also called "SSH tunnel".
Below is a more interesting example.
$ ssh -L 5900:localhost:
5900 host3 It means to bind port 5900 of this machine to port 5900 of host3 (localhost here refers to host3, because the target host is relative to host3).
Another example would be to ssh into host2 via port forwarding on host3.
$ ssh -L 9001:host2:22 host3
At this time, as long as ssh logs in to port 9001 of the machine, it is equivalent to logging in to host2.
$ ssh -p 9001 localhost
The -p parameter above indicates the specified login port.
Remote port forwarding
Since "local port forwarding" refers to forwarding bound to a local port, "remote forwarding" of course refers to forwarding bound to a remote port.
Still look at the above example, there is no connection between host1 and host2, and must be forwarded by host3. However, there is a special situation, host3 is an intranet machine, it can connect to the host1 of the external network, but not vice versa, the host1 of the external network cannot connect to the host3 of the internal network. At this time, "local port forwarding" cannot be used, what should I do?
The solution is that since host3 can connect to host1, establish an SSH connection to host1 from host3, and then use this connection on host1.
We execute the following command on host3:
$ ssh -R 2121:host2:21 host1 The
R parameter also accepts three values, which are "remote host port: target host: target host port". The meaning of this command is to let host1 listen on its own port 2121, and then forward all data to port 21 of host2 via host3. Since host1 is the remote host for host3, this situation is called "remote port binding".
After binding, we can connect to host2 on host1:
$ ftp localhost:2121
It must be pointed out here that the prerequisite for "remote port forwarding" is that both hosts, host1 and host3, have sshD and ssh clients.
Other parameters of SSH
SSH has some other parameters that are also worth introducing.
The N parameter means that only the remote host is connected, and the remote shell is not opened; the T parameter means that no TTY is allocated for this connection. These two parameters can be used together, which means that the SSH connection is only used to transfer data and does not perform remote operations.
$ ssh -NT -D 8080 host
The f parameter indicates that after the SSH connection is successful, it will run in the background. This will allow you to perform other operations in your local shell without interrupting your SSH connection.
$ ssh -f -D 8080 host
To close this background connection, only use the kill command to kill the process.
[ SSH principle and application (2): remote operation and port forwarding ]
from: http://blog.csdn.net/pipisorry/article/details/52269785
ref: [ Installation and use of SSH in Ubuntu environment ]