explain
- Virtual machine network description
All upgraded machines have no external network, which is consistent with the internal network of the production environment, so there is no need to worry about operating their virtual machines according to this document, and there will be problems if there is no external network operation. - Environmental description
The current server version is 7.6, openssh version is 7.4p1, and openssl version is 1.0.2k
Note: if the openssh version is lower than 7.4, you can use the image to upgrade to the default openssh 7.0 of yum warehouse 4p1 version [after mounting the image, execute yum update openssh -y]
[root@controll ~]# cat /etc/redhat-release
CentOS Linux release 7.6.1810 (Core)
[root@controll ~]# ssh -V
OpenSSH_7.4p1, OpenSSL 1.0.2k-fips 26 Jan 2017
[root@controll ~]# sshd -v
unknown option -- v
OpenSSH_7.4p1, OpenSSL 1.0.2k-fips 26 Jan 2017
usage: sshd [-46DdeiqTt] [-C connection_spec] [-c host_cert_file]
[-E log_file] [-f config_file] [-g login_grace_time]
[-h host_key_file] [-o option] [-p port] [-u len]
[root@controll ~]# openssl version
OpenSSL 1.0.2k-fips 26 Jan 2017
[root@controll ~]#
-
The whole process does not need to uninstall the original openssl package and openssh rpm package.
-
The environment of this article is openssh provided by the system and has not experienced manual compilation and installation. If openssh has been manually compiled and installed before [path location needs to be modified], please refer to this article to test whether it can succeed.
-
If you strictly follow this article, I guarantee that you will have no problem upgrading.
-
I will put the complete code in the following commands. It is recommended to copy and paste the code to ensure that the upgrade process is correct.
Configure local source
- This still needs to be configured. It is necessary to install the dependent package later.
- Find a local source with the same image configuration as the system version. If you don't understand, read the following blog to learn:
yum source local configuration and network source configuration - Super complete and detailed
- The following is a process I configured. I only put the command process code without explaining the command [see the blog in the connection above for configuration if you don't understand]:
[root@controll ~]# scp 192.168.59.129:/home/CentOS-7.6-x86_64-DVD-1810.iso /home The authenticity of host '192.168.59.129 (192.168.59.129)' can't be established. ECDSA key fingerprint is SHA256:uvQ2aSyqt5ve6OP4KsUmGPb2P3Gua26u6ggKCAs9RlU. ECDSA key fingerprint is MD5:c6:cc:20:c3:71:cf:69:90:aa:f3:8a:ec:f5:5c:55:cd. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '192.168.59.129' (ECDSA) to the list of known hosts. root@192.168.59.129's password: CentOS-7.6-x86_64-DVD-1810.iso 100% 4376MB 56.6MB/s 01:17 [root@controll ~]# ls /home ccx CentOS-7.6-x86_64-DVD-1810.iso [root@controll yum.repos.d]# mkdir /home/centos [root@controll yum.repos.d]# mount /home/CentOS-7.6-x86_64-DVD-1810.iso /home/centos/ mount: /dev/loop0 is write-protected, mounting read-only [root@controll yum.repos.d]# df -Th |grep /home/centos /dev/loop0 iso9660 4.3G 4.3G 0 100% /home/centos [root@controll yum.repos.d]# [root@controll ~]# cd /etc/yum.repos.d/ [root@controll yum.repos.d]# ls CentOS-Base.repo CentOS-CR.repo CentOS-Debuginfo.repo CentOS-fasttrack.repo CentOS-Media.repo CentOS-Sources.repo CentOS-Vault.repo [root@controll yum.repos.d]# mkdir bak [root@controll yum.repos.d]# mv * bak mv: cannot move 'bak' to a subdirectory of itself, 'bak/bak' [root@controll yum.repos.d]# ls bak [root@controll yum.repos.d]# scp 192.168.59.129:/etc/yum.repos.d/centos.repo . root@192.168.59.129's password: centos.repo 100% 76 51.6KB/s 00:00 [root@controll yum.repos.d]# ls bak centos.repo [root@controll yum.repos.d]# cat centos.repo [7.6-bendi] name=ccx_settin baseurl=file:///home/centos gpgcheck=0 enable=1 [root@controll yum.repos.d]# yum repolist Loaded plugins: fastestmirror, langpacks Loading mirror speeds from cached hostfile 7.6-bendi | 3.6 kB 00:00:00 (1/2): 7.6-bendi/group_gz | 166 kB 00:00:00 (2/2): 7.6-bendi/primary_db | 3.1 MB 00:00:00 repo id repo name status 7.6-bendi ccx_settin 4,021 repolist: 4,021 [root@controll yum.repos.d]#
Configure telnet
explain
- This can be configured without configuration. It is not recommended to configure and enable telnet on the production server. This is just a brief description of the method of configuring and enabling telnet.
- The meaning of configuring telnet is to prevent the connection interruption of remote tools during the upgrade of ssh, but I tried 4 machines and used secureCRT tools for remote connection throughout the whole process. There was no interruption in the middle, so I can operate directly [just go to the background if it is interrupted]
Allow root login
- Now many CentOS 7 versions do not have a configuration file called telnet after installing telnet server and xinetd.
If the following telnet file does not exist, you can skip the change of this part [root login can be used by default]
[root@controll ~]# ll /etc/xinetd.d/telnet ls: cannot access /etc/xinetd.d/telnet: No such file or directory [root@controll ~]#
- If the following files exist, please change the configuration. telnet can log in as root and change disable = no to disable = yes
[root@rhel yum.repos.d]# vim /etc/xinetd.d/telnet
[root@rhel yum.repos.d]# cat /etc/xinetd.d/telnet
# default: on
# description: The telnet server serves telnet sessions; it uses \
# unencrypted username/password pairs for authentication.
service telnet
{
disable = yes
flags = REUSE
socket_type = stream
wait = no
user = root
server = /usr/sbin/in.telnetd
log_on_failure += USERID
}
Terminal login configuration [optional]
Configure the terminal type of telnet login, and add some pts terminals at the end of / etc / secure file, as follows
[root@controll ~]# vim /etc/securetty [root@controll ~]# tail -n 4 /etc/securetty pts/0 pts/1 pts/2 pts/3 [root@controll ~]#
Service installation
- Install the following 2 services
[root@controll ~]# yum -y install telnet* [root@controll ~]# yum -y install xinetd*
- Start these two services
[root@controll ~]# systemctl start telnet.socket [root@controll ~]# systemctl start xinetd [root@controll ~]# systemctl is-active telnet.socket active [root@controll ~]# systemctl is-active xinetd active [root@controll ~]# systemctl enable xinetd systemctl enable telnet.socket
- Check whether port 23 is listening
[root@controll ~]# netstat -ntlp | grep 23 tcp6 0 0 :::23 :::* LISTEN 1/systemd [root@controll ~]#
telnet login virtual machine
- Directly enter: telnet ip enter in the current virtual machine to log in successfully [because there is no / etc/xinetd.d/telnet folder, you can log in directly with root by default]
[root@controll ~]# telnet 192.168.59.133 Trying 192.168.59.133... Connected to 192.168.59.133. Escape character is '^]'. Kernel 3.10.0-957.el7.x86_64 on an x86_64 controll login: root Password: Last login: Thu May 20 00:25:35 from ::ffff:192.168.59.133 [root@controll ~]# logout Connection closed by foreign host. [root@controll ~]#
- If you use the tool, it is recommended to use xshell to connect to telnet. If the secureCRT version is too low, the connection will fail
Create a new session and select Telnet as the protocol
telnet port is 23
Install dependent packages
- Note: the dependent package only needs the local source in the image;
- Upgrading requires several components, some of which are related to compilation, etc
[root@controll ~]# yum install -y gcc gcc-c++ glibc make autoconf openssl openssl-devel pcre-devel pam-devel # I installed 20 packages here, as follows Installed: autoconf.noarch 0:2.69-11.el7 gcc.x86_64 0:4.8.5-36.el7 gcc-c++.x86_64 0:4.8.5-36.el7 openssl-devel.x86_64 1:1.0.2k-16.el7 pam-devel.x86_64 0:1.1.8-22.el7 pcre-devel.x86_64 0:8.32-17.el7 Dependency Installed: cpp.x86_64 0:4.8.5-36.el7 glibc-devel.x86_64 0:2.17-260.el7 glibc-headers.x86_64 0:2.17-260.el7 kernel-headers.x86_64 0:3.10.0-957.el7 keyutils-libs-devel.x86_64 0:1.5.8-3.el7 krb5-devel.x86_64 0:1.15.1-34.el7 libcom_err-devel.x86_64 0:1.42.9-13.el7 libkadm5.x86_64 0:1.15.1-34.el7 libselinux-devel.x86_64 0:2.5-14.1.el7 libsepol-devel.x86_64 0:2.5-10.el7 libstdc++-devel.x86_64 0:4.8.5-36.el7 libverto-devel.x86_64 0:0.2.5-4.el7 m4.x86_64 0:1.4.16-10.el7 zlib-devel.x86_64 0:1.2.7-18.el7 Complete! [root@controll ~]# yum install -y pam* zlib* # I installed three packages here, as follows Installed: pam_krb5.x86_64 0:2.4.8-6.el7 pam_pkcs11.x86_64 0:0.6.2-30.el7 Dependency Installed: pcsc-lite-libs.x86_64 0:1.8.8-8.el7 Complete!
Prepare openssh package and openssl package
-
Download the tar package of openssh and openssl by yourself
-
If you don't want to find it, you can download it directly. The link is as follows:
- openssh and openssl_tar package download
- There are four files in total: openssh-8.0p1 tar,openssh-8.6p1.tar,openssl-1.1.1j.tar,openssl-1.0.2s.tar
-
Note: among the above four packages, OpenSSL can only use openssl-1.0.2s Tar compilation [openssl-1.1.1j.tar will make various errors. This is for your experiment (if you want to toss)]. Both versions of openssh 2 can be used normally.
-
Here we need to give a brief description of this package. Many posts on the Internet say that openssh and openssl packages are compatible, but I found a lot of information and didn't see a formal introduction to the corresponding versions of openssh and openssl.
So I did several version tests and found that as long as openssl can be compiled successfully, the version can be checked using opensll version, and openssh can be compiled successfully later, there is no problem, There is no problem of mutual compatibility [I tested three versions, either openssl can view the version but openssh cannot compile successfully later, or openssl cannot view the version directly and pass directly (I suspect that ssl and ssh are only related to system compatibility, not compatibility between the two)]
Upload openssl and openssh packages to the server
-
The uploaded file has a linux command, which can be called directly in the secureCRT tool:
rz -E, after entering, the file selection will pop up. Select it and click Add to upload it directly.
-
Because I have these packages on other servers, I passed the test.
It's my habit to put the toolkit in / software uniformly [put it casually according to my preferences, which will not affect the installation], but in order to copy and paste my code later, I suggest you put it in / software as well
[root@controll ~]# mkdir /software [root@controll ~]# scp 192.168.59.129:/software/* /software/ root@192.168.59.129's password: openssh-8.0p1.tar.gz 100% 1560KB 37.2MB/s 00:00 scp: /software/openssh-8.6p1: not a regular file openssh-8.6p1.tar.gz 100% 1744KB 38.7MB/s 00:00 scp: /software/openssl-1.0.2s: not a regular file openssl-1.0.2s.tar.gz 100% 5224KB 45.0MB/s 00:00 scp: /software/openssl-1.1.1j: not a regular file openssl-1.1.1j.tar.gz 100% 9593KB 29.6MB/s 00:00 [root@controll ~]# cd /software/ [root@controll software]# ls openssh-8.0p1.tar.gz openssh-8.6p1.tar.gz openssl-1.0.2s.tar.gz openssl-1.1.1j.tar.gz [root@controll software]#
Start installing openssl
Version view before upgrade
It is mainly used to compare whether the upgrade is successful
[root@controll openssl-1.0.2s]# openssl version OpenSSL 1.0.2k-fips 26 Jan 2017 [root@controll openssl-1.0.2s]#
File backup
[root@controll software]# ll /usr/bin/openssl -rwxr-xr-x. 1 root root 555248 Oct 31 2018 /usr/bin/openssl [root@controll software]# mv /usr/bin/openssl /usr/bin/openssl_bak [root@controll software]# ll /usr/include/openssl total 1864 -rw-r--r--. 1 root root 6146 Oct 31 2018 aes.h # There are many more, but for the sake of brevity, I deleted it and only kept the above one [root@controll software]# mv /usr/include/openssl /usr/include/openssl_bak [root@controll software]#
Unzip the tar package
[root@controll software]# ls openssh-8.0p1.tar.gz openssh-8.6p1.tar.gz openssl-1.0.2s.tar.gz openssl-1.1.1j.tar.gz [root@controll software]# [root@controll software]# tar xfz openssl-1.0.2s.tar.gz
Compile and install the new version of openssl
- The three commands of configuration, compilation and installation are executed together
&&The symbol indicates that the following will be executed only after the previous execution is successful
[root@controll software]# cd openssl-1.0.2s/ [root@controll openssl-1.0.2s]# ./config shared && make && make install # This process takes a long time and requires patience
- The following content has been flashing in the middle
- After the above command is executed, echo $? [those who know the shell should know this. This is to check the return value. 0 means successful execution] check whether there is an error in the last make install. 0 means no problem, and any number except 0 is wrong [an error in one of the above steps needs to be done again, and the next step can be carried out until the display result is 0]
The successful interface is as follows
Soft links to directories
Make soft links to the following 2 files or directories [the previous steps mv backed up the original]
[root@controll openssl-1.0.2s]# ln -s /usr/local/ssl/bin/openssl /usr/bin/openssl [root@controll openssl-1.0.2s]# ln -s /usr/local/ssl/include/openssl /usr/include/openssl [root@controll openssl-1.0.2s]# [root@controll openssl-1.0.2s]# ll /usr/bin/openssl lrwxrwxrwx. 1 root root 26 May 20 01:13 /usr/bin/openssl -> /usr/local/ssl/bin/openssl [root@controll openssl-1.0.2s]# ll /usr/include/openssl lrwxrwxrwx. 1 root root 30 May 20 01:13 /usr/include/openssl -> /usr/local/ssl/include/openssl [root@controll openssl-1.0.2s]#
Load new configuration
If you repeat the above steps several times [don't repeat the following echo content, just do it once], / sbin/ldconfig doesn't matter every time you execute it.
[root@controll openssl-1.0.2s]# echo "/usr/local/ssl/lib" >> /etc/ld.so.conf [root@controll openssl-1.0.2s]# /sbin/ldconfig
View confirmed version
- There must be no error reporting, and the error reporting is the end of the calf [see the solution below for error reporting]
- It's time to witness miracles
No error reported, successful.
[root@controll openssl-1.0.2s]# openssl version # OpenSSL 1.0.2k-fips 26 Jan 2017 before upgrade OpenSSL 1.0.2s 28 May 2019 [root@controll openssl-1.0.2s]#
Error reporting examples and Solutions
- If you run openssl version to check the version and report an error, it is probably caused by the incompatibility between the current openssl package and the current system. The solution is to change the version of openssl
- Error report view
[root@centos76_1 openssl-1.1.1j]# openssl version -bash: /usr/bin/openssl: There is no such file or directory #In fact, this file must exist # This is caused by incompatibility. Reinstall other versions directly [root@centos76_1 openssl-1.1.1j]# ll /usr/bin/openssl lrwxrwxrwx. 1 root root 26 5 September 19-17:34 /usr/bin/openssl -> /usr/local/ssl/bin/openssl [root@centos76_1 openssl-1.1.1j]#
- Repeat the above steps for reinstallation. The difference is that the backup of the above files can be replaced by deletion
[root@centos76_1 software]# rm -rf /usr/bin/openssl [root@centos76_1 software]# rm -rf /usr/include/openssl # Just delete the above two soft connection files #If you delete the above two softlinks and reinstall other versions, you can delete the following two source files # I can reinstall 1.0 by deleting the above two files in 1.1, but I can only return to 1.1 by deleting the following two files in 1.0. [root@centos76_1 software]# rm -rf /usr/local/ssl/bin/openssl [root@centos76_1 software]# rm -rf /usr/local/ssl/include/openssl
Install openssh
- My upgrade is 8.6
Version view before upgrade
It is mainly used to compare whether the upgrade is successful
[root@controll software]# ssh -V
OpenSSH_7.4p1, OpenSSL 1.0.2k-fips 26 Jan 2017
[root@controll software]# sshd -v
unknown option -- v
OpenSSH_7.4p1, OpenSSL 1.0.2k-fips 26 Jan 2017
usage: sshd [-46DdeiqTt] [-C connection_spec] [-c host_cert_file]
[-E log_file] [-f config_file] [-g login_grace_time]
[-h host_key_file] [-o option] [-p port] [-u len]
[root@controll software]#
File backup delete
- If there are many things configured in ssh, you can back up and copy this file back after the upgrade [if there is nothing configured, skip the backup and delete it according to the following operations]
Note: after the following compilation and installation operation is successful, restore the backed up file [it is recommended not to restore, but directly refer to the previous configuration for reconfiguration. In extreme cases, the original configuration will lead to unexpected problems in ssh due to inconsistent versions]
[root@controll software]# mkdir /etc/ssh.bak [root@controll software]# cp -r /etc/ssh /etc/ssh.bak/
- Because my server has not made any configuration changes to ssh, I deleted it without considering the configuration problem
[root@controll software]# rm -rf /etc/ssh/*
Unzip the tar package
[root@controll software]# tar xfz openssh-8.6p1.tar.gz [root@controll software]# cd openssh-8.6p1/
Compile and install the new version of openssh
- Configuration, compilation and installation are performed together
The command is a little long. Pay attention to the copy
[root@controll openssh-8.6p1]# pwd /software/openssh-8.6p1 [root@controll openssh-8.6p1]# ./configure --prefix=/usr/ --sysconfdir=/etc/ssh --with-openssl-includes=/usr/local/ssl/include --with-ssl-dir=/usr/local/ssl --with-zlib --with-md5-passwords --with-pam && make && make install # This process takes a long time and requires patience
- The following content has been flashing in the middle
- After the above command is executed, echo $? [those who know the shell should know this. This is to check the return value. 0 means successful execution] check whether there is an error in the last make install. 0 means no problem, and any number except 0 is wrong [an error in one of the above steps needs to be done again, and the next step can be carried out until the display result is 0]
The successful interface is as follows
Configure root to log in
-
As mentioned in the above file backup steps, if there are too many configurations in / etc/ssh, you can restore it here after backup [repeat it, it is not recommended to restore, directly refer to the backed up file and reconfigure it]
-
Only one place in the new file is modified here, that is, the setting allows root login [root login is not allowed by default after upgrading]
In the file / etc / SSH / sshd_ Change permitrotlogin to yes in config.
[root@controll openssh-8.6p1]# cat /etc/ssh/sshd_config | egrep -nC 1 PermitRootLogin 31-#LoginGraceTime 2m 32:#PermitRootLogin prohibit-password 33:PermitRootLogin yes 34-#StrictModes yes
New file copy
- Copy some files from the original unzipped package to the target location [overwrite if the target directory exists]
Maybe the following SSH PAM file is not used because sshd_ The config configuration file doesn't seem to use it. Please test it yourself [I copied it here, but it's not bad anyway]
[root@controll openssh-8.6p1]# cp -a contrib/redhat/sshd.init /etc/init.d/sshd [root@controll openssh-8.6p1]# cp -a contrib/redhat/sshd.pam /etc/pam.d/sshd.pam [root@controll openssh-8.6p1]# chmod +x /etc/init.d/sshd
Add sshd service and set startup
- Let chkconfig manage the sshd service and add sshd to the startup self startup
# --add adds the specified system service so that the chkconfig instruction can manage it, and adds relevant data in the description file of system startup at the same time. [root@controll openssh-8.6p1]# chkconfig --add sshd [root@controll openssh-8.6p1]# systemctl enable sshd [root@controll openssh-8.6p1]#
- Delete or remove or delete the sshd files managed by the original systemd. If they are not removed, it will affect us to restart the sshd service
It can be moved anywhere, but it is recommended to remember the destination of the move so that the source file can be found later if necessary.
[root@controll openssh-8.6p1]# mkdir /data [root@controll openssh-8.6p1]# mv /usr/lib/systemd/system/sshd.service /data/
- Because it is managed by chkconfig, you need to set the sshd service to start
[root@controll openssh-8.6p1]# chkconfig sshd on Note: Forwarding request to 'systemctl enable sshd.socket'. Created symlink from /etc/systemd/system/sockets.target.wants/sshd.socket to /usr/lib/systemd/system/sshd.socket. [root@controll openssh-8.6p1]#
- Finally, restart the sshd service and check whether the port listens normally
[root@controll openssh-8.6p1]# systemctl restart sshd [root@controll openssh-8.6p1]# systemctl is-active sshd active [root@controll openssh-8.6p1]# [root@controll openssh-8.6p1]# netstat -ntlp | grep 22 tcp 0 0 192.168.122.1:53 0.0.0.0:* LISTEN 12737/dnsmasq tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 10403/sshd: /usr/sb tcp6 0 0 :::22 :::* LISTEN 10403/sshd: /usr/sb [root@controll openssh-8.6p1]#
At this point, the openssh upgrade is complete
View confirmed version
- There is no error in the above compilation. Every step has been completed, and there will be no problem.
Note: both ssh -V and sshd - V need to be executed, and both need to be consistent before the real upgrade is successful.
[root@controll openssh-8.6p1]# openssl version
OpenSSL 1.0.2s 28 May 2019
[root@controll openssh-8.6p1]#
[root@controll openssh-8.6p1]# ssh -V
OpenSSH_8.6p1, OpenSSL 1.0.2s 28 May 2019
[root@controll openssh-8.6p1]# sshd -v
unknown option -- v
OpenSSH_8.6p1, OpenSSL 1.0.2s 28 May 2019
usage: sshd [-46DdeiqTt] [-C connection_spec] [-c host_cert_file]
[-E log_file] [-f config_file] [-g login_grace_time]
[-h host_key_file] [-o option] [-p port] [-u len]
[root@controll openssh-8.6p1]#
- The following is the result of my upgrade of 8.0
[root@centos76_3 ~]# openssl version
OpenSSL 1.0.2s 28 May 2019
[root@centos76_3 ~]#
[root@centos76_3 ~]# ssh -V
OpenSSH_8.0p1, OpenSSL 1.0.2s 28 May 2019
[root@centos76_3 ~]# sshd -v
unknown option -- v
OpenSSH_8.0p1, OpenSSL 1.0.2s 28 May 2019
usage: sshd [-46DdeiqTt] [-C connection_spec] [-c host_cert_file]
[-E log_file] [-f config_file] [-g login_grace_time]
[-h host_key_file] [-o option] [-p port] [-u len]
[root@centos76_3 ~]#
Upgrade to 8.6 must be operated [otherwise the tool cannot be connected]
-
If you upgrade openssh8 0, ignore this step
-
After upgrading to 8.6, if you do not do the following operations, the crt tool will be unable to connect [but you can go through ssh from the server], and the error message is as follows:
Key exchange failed.
There is no compatible encryption program. The server supports these encryption programs:
chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
-
reason
After the upgrade of SSH and SSL, some insecure encryption algorithms are cancelled. Clinet does not support new algorithms, so it is unable to exchange keys; -
processing method
- 1. Customers are required to upgrade SecureCRT version to 6.5 or 7.0 x. Or replace the latest version of Xshell, Putty and other tools to log in normally [it is recommended not to use the following method if this method can be solved]
- 2. Modify the ssh configuration and add support for the original encryption algorithm:
Log in to the server that cannot be logged in [you can go to ssh from the normal server] and modify / etc/ssh/sshd_config file, add the following contents at the end of the file, and then restart the ssh service
[root@controll openssh-8.6p1]# tail -n 2 /etc/ssh/sshd_config # The following line of information is very long. Please pay attention to copying it KexAlgorithms diffie-hellman-group1-sha1,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1,diffie-hellman-group-exchange-sha256,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group1-sha1,curve25519-sha256@libssh.org [root@controll openssh-8.6p1]# [root@controll openssh-8.6p1]# systemctl restart sshd
Login test after upgrade [important]
explain
After the openssh upgrade, the following three items must be tested, and each item must be normal before the upgrade is successful. If any test fails, it will not work!
Tool test
- If a newer version of openssh is upgraded, the version of SecureCRT should be 6.5 or 7.0 x. Or replace the latest version of Xshell, Putty and other tools.
- After the upgrade, if the tool is connected, disconnect and reconnect to see if it is normal [for version 8.6, you must see the above step, otherwise the tool cannot be connected. At that time, I thought it was impossible to upgrade 8.6, so I searched a lot of data to get it done]
Other servers ssh this server [very important]
- Find a machine that can ssh to the upgrade server normally before
It is found that an error is reported [the host name of openssh upgraded above is controll, and now the server connection of CentOS 76_2 is used to upgrade the server test]
[root@centos76_2 ~]# ssh 192.168.59.133 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that a host key has just been changed. The fingerprint for the ED25519 key sent by the remote host is SHA256:0uTcB4pn/p0X72gZrtG4b7MrgLJJL9Q8Gr1TrDNFThA. Please contact your system administrator. Add correct host key in /root/.ssh/known_hosts to get rid of this message. Offending ECDSA key in /root/.ssh/known_hosts:7 Host key for 192.168.59.133 has changed and you have requested strict checking. Host key verification failed. [root@centos76_2 ~]#
-
reason
This is because the public key information of the server is changed after the ssh upgrade, so the connection cannot be made. -
resolvent
Edit the configuration file ~ /. On the connection server vi ssh/known_hosts, delete the ip information of the existing upgraded ssh server
[root@centos76_2 ~]# # Previously recorded information has been deleted [root@centos76_2 ~]# cat ~/.ssh/known_hosts | grep 133 [root@centos76_2 ~]# ssh 192.168.59.133 # The connection is normal again The authenticity of host '192.168.59.133 (192.168.59.133)' can't be established. ED25519 key fingerprint is SHA256:0uTcB4pn/p0X72gZrtG4b7MrgLJJL9Q8Gr1TrDNFThA. This key is not known by any other names Are you sure you want to continue connecting (yes/no/[fingerprint])? yes Warning: Permanently added '192.168.59.133' (ED25519) to the list of known hosts. root@192.168.59.133's password: Last login: Thu May 20 00:28:27 2021 from ::ffff:192.168.59.133 [root@controll ~]#
ssh server test
You can connect to any server normally without modifying any information
[root@controll ~]# ssh 192.168.59.129 root@192.168.59.129's password: Last login: Wed May 19 22:25:35 2021 from 192.168.59.1 [root@centos76_2 ~]#
Telnet off [ignore if telnet is not configured]
If telnet is configured and the service is enabled, the telnet service can be shut down after the openssh upgrade test is OK [especially the production server]
[root@controll ~]# systemctl stop xinetd [root@controll ~]# systemctl disable xinetd Removed symlink /etc/systemd/system/multi-user.target.wants/xinetd.service. [root@controll ~]# systemctl stop telnet.socket [root@controll ~]# systemctl disable xinetd [root@controll ~]# [root@controll ~]# netstat -lntp | grep 23 [root@controll ~]# [root@controll ~]# netstat -lntp | grep 22 tcp 0 0 192.168.122.1:53 0.0.0.0:* LISTEN 12737/dnsmasq tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 13277/sshd: /usr/sb tcp6 0 0 :::22 :::* LISTEN 13277/sshd: /usr/sb [root@controll ~]#