SSH usage and summary

SSH usage and summary SSH service (TCP port 22): the secure command interpreter provides a secure Shell environment for the client to remotely manage SSH based on public key encryption (asymmetric encryption) technology: encrypted data transmission; client and server authentication; the public key and private key are generated in pairs. These two keys are different and can be encrypted and decrypted; you cannot calculate another key based on one key. The public key is made public to the outside, and only the owner of the private key can know it. Data encryption and digital signature of www.2cto.com (based on different functions) the sender uses the public key of the receiver to encrypt the data. The receiver uses its own private key to decrypt the data. Data Encryption ensures the confidentiality of the sent data; digital Signature: (Digital Signature ensures data integrity, authentication, and non-repudiation) Sender: executes the HASH algorithm on the original data to obtain the digest value, and the sender encrypts the digest value with its own private key; sends the encrypted summary value and original data to the receiver. The receiver decrypts the summary value with the sender's public key, and generates another digest value for the received raw data by performing the HASH operation; decrypt The Digest value is compared with the generated digest value. www.2cto.com OpenSSH: Server master program:/usr/sbin/sshd client master program:/usr/bin/ssh server configuration file: /etc/ssh/sshd_config (restart shhd service to take effect) Client configuration file:/etc/ssh/ssh_configSSH user name used for Logon: Account name of the local system user in the server; password verification for SSH Logon: Use the password of the system account on the server; (PasswordAuthentcation yes) key pair verification: use the public key and private key generated on the client; (PubkeyAuthentication yes AuthorizedKeyFile. ssh/authorized_keys) Remote logon using the ssh command: 1.ssh username @ server address 2.ssh-l username server address (rarely used) 3.ssh server address (which user is used by the server) User Logon) Other common SSH-related commands: passwd # modify the current user password groupadd SSH # Add group useradd-g SSH-s/bin/'bash'-d/home/user1 user1 # Add User passwd user1 # create for user user1 password userdel user1 # Delete user1groupdel SSH # delete a group SSH Disabled Account, VIM edit the password file and add ": *" after the user name ":*". Www.2cto.com vim/etc/shadow12service sshd restart # restart sshdps-aux | grep sshd # Check whether the client key is successfully stored ~. The key storage location of the server in the ssh directory/etc/ssh/ssh_host _ * known_hosts stores the Public Key authorized_keys of the accessed server and stores the public key of the client to be verified. the reason why the ssh folder and the group with the following file permissions and other people cannot have the w permission for ssh access is slow and the solution is: when accessing the server, the IP address of the server is reversed to the domain name, if the resolution fails, the login will be slow. The following three methods can solve this problem: 1. Clear/etc/resolv. the nameserver record in the conf file 2. Add the server domain name resolution record in the/etc/hosts file of the client 3. Modify the/etc/ssh/ssh_config file of the client: GSSAPIAuthentication no problem 2: If the public key file is faulty, authentication will fail. The solution is to delete the file rm-rf/root /. ssh/know_hosts service sshd restart configuration case: www.2cto.com password mode: service sshd restart service netstat-anpt | grep sshd view port login HOST: ssh root@192.168.100.127 ssh directly on the remote host New User: ssh root@10.10.10.1 adduser txy in password authentication should look at: Server Side/etc/ssh/sshd_config PasswordAuthentcation yes ,, password Authentication for the first access to the server without entering yes ssh-o StrictHostKeyChecking = no root@10.10.10.1/etc/ssh/ssh_config client file StrictHostKeyChecking no first access to the server without entering the yes key method www.2cto.com here in this example, a common user logs on to the server, it is easier for the root user to log on. There is no need to create a file or modify the permissions. the root user who copies the scp under the place where the key is generated is also under root: the server can view the file: modify PubkeyAuthentication in/etc/ssh/sshd_config to create the file mkdir/home/xiaohua /. ssh file modification permission: chomd-R 600/home/xiaohu /. other users of ssh in this file cannot have the w permission client: useradd xiaolue su-xiaolue ssh-keygen scp/home/xiaolue /. ssh/id_rsa.pub root@192.168.100.127:/home/xiaohua /. ssh/authorized_keys Access Control:/etc/hosts. allow takes precedence over/etc/hosts below. deny first checks hosts. allow file. If a matched policy is found, access is allowed; otherwise, check the hosts. deny file. If a matching policy is found, access is denied. If no matching policy exists in both files, access is allowed; www.2cto.com vim/etc/hosts. allow sshd: 210.13.218. *: the ip address that allow allows to log on to. allow can omit the ip address that can control the service range: 1. It is managed by the super daemon (xinetd) service. 2. libwrap is supported. check whether the service of the so module controls the specific service: ldd/usr/sbin/sshd | grep wrap idd $ (which service) | restart the service after grep wrap is modified: service xined restart