Shulou(Shulou.com)06/01 Report--

This article mainly introduces the "SSH login Linux server slow or login error solution", in the daily operation, I believe that many people have doubts in the SSH login Linux server slow or login error solution, the editor consulted all kinds of information, sorted out a simple and useful method of operation, hope to answer the "SSH login Linux server slow or login error solution" doubt! Next, please follow the editor to study!

Every time you use SSH to log in to a remote Linux for administration, the remote login process is very slow-after entering the user name, you have to wait about 30 seconds before you are prompted for a password. When dealing with problems in practice, especially when there is a need for quick response, this situation is really unbearable.

But later, a specific test, found that this is not a common fault of every system, the problem of the machine is mainly concentrated on the CentOS, the same Debian system, in the process of remote connection is a vigorous pace, without the slightest sense of Catton hesitation. Is this CentOS's problem?

Out of curiosity, I checked the difference between the next two systems in SSH

CentOS:

The code is as follows:

Ssh-v ssh_test@192.168.128.137

The message displayed when SSH logs in remotely is as follows:

OpenSSH_6.0p1 Debian-4, OpenSSL 1.0.1e 11 Feb 2013

... Some sensitive information...

Debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3

Debug1: match: OpenSSH_5.3 pat OpenSSH_5*

Debug1: Enabling compatibility mode for protocol 2.0

Debug1: Local version string SSH-2.0-OpenSSH_6.0p1 Debian-4

Debug1: SSH2_MSG_KEXINIT sent

Debug1: SSH2_MSG_KEXINIT received

Debug1: kex: server- > client aes128-ctr hmac-md5 none

Debug1: kex: client- > server aes128-ctr hmac-md5 none

Debug1: SSH2_MSG_KEX_DH_GEX_REQUEST (1024server aes128-ctr hmac-md5 none

Debug1: sending SSH2_MSG_KEX_ECDH_INIT

Debug1: expecting SSH2_MSG_KEX_ECDH_REPLY

... Some sensitive information...

Debug1: ssh_ecdsa_verify: signature correct

Debug1: SSH2_MSG_NEWKEYS sent

Debug1: expecting SSH2_MSG_NEWKEYS

Debug1: SSH2_MSG_NEWKEYS received

Debug1: Roaming not allowed by server

Debug1: SSH2_MSG_SERVICE_REQUEST sent

Debug1: SSH2_MSG_SERVICE_ACCEPT received

Debug1: Authentications that can continue: publickey,password

Debug1: Next authentication method: publickey

Debug1: Trying private key: / home/mitchellchu/.ssh/id_rsa

Debug1: Trying private key: / home/mitchellchu/.ssh/id_dsa

Debug1: Trying private key: / home/mitchellchu/.ssh/id_ecdsa

Debug1: Next authentication method: password

As you can see above, in CentOS, the system uses publickey,gssapi-keyex,gssapi-with-mic, and password for authentication (color-coded line 23 above), while Debian uses both Publickey and password at this time. When connecting to CentOS, it took a considerable amount of time at line 23. When we start to look down there, we can see the following message very clearly:

# GSSAPI-KEYEX is used for verification below

Debug1: Next authentication method: gssapi-keyex

# but error: no Key is available to exchange information

Debug1: No valid Key exchange context

# the system then uses the next verification method: GSSAPI-WITH-MIC

Debug1: Next authentication method: gssapi-with-mic

# but unfortunately, the GSSAPI-WITH-MIC method also failed.

# reason: unable to determine the domain of the numeric host address

Debug1: Unspecified GSS failure. Minor code may provide more information

Cannot determine realm for numeric host address

Debug1: Unspecified GSS failure. Minor code may provide more information

Cannot determine realm for numeric host address

Debug1: Unspecified GSS failure. Minor code may provide more information

Debug1: Unspecified GSS failure. Minor code may provide more information

Cannot determine realm for numeric host address

# after several attempts, SSH authentication finally gave up this verification. Proceed to the next verification: Publickey

Debug1: Next authentication method: publickey

Is there any other way besides this? This is natural, and CentOS already provides us with a solution-disable GSSAPI authentication when logging in remotely using ssh. Of course, there is another problem you have to pay attention to. If you have UseDNS enabled on your machine, you need to turn it off as well, as shown in the final description.

From the error, you can see that it should be a problem related to the host domain-- it should be that the domain corresponding to the IP cannot be identified, so this problem occurs. GSSAPI is mainly based on Kerberos, so to solve this problem, the system needs to be configured with Kerberos. For people without Kerberos, configuring a Kerberos to solve the login delay problem does not seem to be a wise decision-especially in a production environment! Minimizing the satisfaction of demand is the king.

Let's first show how to deal with GSSAPI.

There are two ways to disable GSSAPI authentication: client and server

1. Client disabled

It is relatively simple, and only a single client user is affected, which can be implemented in the following ways:

The code is as follows:

Ssh-o GSSAPIAuthentication=no your-server-username@serverIP

By logging in remotely using the above method, you can disable GSSAPIAuthentication.

If you find it troublesome, configure your ssh client's file / etc/ssh/ssh_config directly to permanently solve the problem:

The code is as follows:

Vi / etc/ssh/ssh_config

# find the line GSSAPIAuthentication yes in the ssh_config file

# modify to GSSAPIAuthentication no

# Save ssh_config file and exit

This modification method affects all users on this machine. If you do not have so extensive influence, just disable GSSAPIAuthentication on the specified user, then you can find the .ssh directory in the user's directory, add the config file below it, and add the above sentence to the file. If you do not have this file, you can also do this directly:

The code is as follows:

Cat > > ~ / .ssh/config SSH- > Auth-> GSSAPI-> (uncheck) Attempt GSSAPI authentication (SSH-2 only)

If you do not close the GSSAPIAuthentication of PuTTY, you can right-click (or: Ctrl + right-click) in the connection window to view the log, and you can find that PuTTY will automatically try the log of GSSAPI connection:

2014-05-18 23:46:54 Using SSPI from SECUR32.DLL

2014-05-18 23:46:54 Attempting GSSAPI authentication

2014-05-18 23:46:54 GSSAPI authentication request refused

Well, the above basically lists the ways in which the client side forbids GSSAPIAuthentication.

Note: the above methods are more general.

2. If you have already configured Kerberos

Then you can also try the following client solutions to this problem:

Add the hostname of the remote host to your local host file (Linux is / etc/hosts,Windows is the system disk:\ Windows\ System32\ drivers\ etc\ hosts). The following line can be added under both Linux and Windows.

The code is as follows:

# Note: the following IP-Addr should be replaced with the IP address of your remote machine, HostName, which is naturally the hostname.

IP-Addr HostName

After you have added it, save and exit.

If you do not configure Kerberos, configuring this hosts file alone will not solve the problem. When you log in with ssh, you can see that the error log will look like this:

Debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mi

Debug1: Next authentication method: gssapi-keyex

Debug1: No valid Key exchange context

Debug1: Next authentication method: gssapi-with-mic

Debug1: Unspecified GSS failure. Minor code may provide more information

Credentials cache file'/ tmp/krb5cc_0' not found

Debug1: Unspecified GSS failure. Minor code may provide more information

Credentials cache file'/ tmp/krb5cc_0' not found

Debug1: Unspecified GSS failure. Minor code may provide more information

Debug1: Unspecified GSS failure. Minor code may provide more information

Credentials cache file'/ tmp/krb5cc_0' not found

Debug1: Next authentication method: publickey

I also made this mistake at the beginning, which needs to be paid attention to.

3. Disable GSSAPIAuthentication on the server side.

Go directly to / etc/ssh/sshd_config and change GSSAPIAuthentication yes to no. Note that you may also need to change UseDNS to UseDNS no (note that the default values for each system are different. Take CentOS 6 as an example):

The code is as follows:

Sudo vi / etc/ssh/sshd_config

# the permissions of ordinary users are insufficient, and root permissions are required

# find GSSAPIAuthentication yes and modify it to

# GSSAPIAuthentication no

# Note: here you also need to change UseDNS to no,CentOS and default to yes. Even if this line has been commented, you need to add it.

# UseDNS no

# some people say that UseDNS yes does not need to be modified to UseDNS no,Mitchell for testing.

# Save the file and exit

When disabled, we need to restart the SSH service to ensure that the new profile is applied correctly:

The code is as follows:

Service sshd restart

At this time, when you use SSH to log in to this host again, does it feel fast?

I finally finished this long article. It's still a little difficult to get these words out while messing around. However, this will make the problem almost, I hope you can read the article to understand, welcome to discuss.

Description:

1. GSSAPI:Generic Security Services Application Program Interface,GSSAPI itself is a set of API, standardized by IETF. Its most important and famous implementation is based on Kerberos. Generally speaking, GSSAPI refers to the implementation of Kerberos.

2. UseDNS: it is a DNS lookup option on the OpenSSH server, and it is enabled by default. When the client tries to connect to the OpenSSH server, the server automatically performs a DNS PTR reverse query based on the client's IP (IP reverse parsing will have a record), queries the Hostname corresponding to the IP, and then queries the DNS forward A record based on the client's Hostname. Through this query, verify that the IP is consistent with the connected client IP. But most of our machines get IP dynamically, that is, this option is not useful for this situation at all-even a normal static IP server is difficult to apply as long as it doesn't do IP reverse parsing. If you meet these conditions, it is recommended that you turn off UseDNS to improve the speed of authentication when SSH logs in remotely.

Ssh certificate login error

Error description

The following error message is prompted when using the certificate ssh link

Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password). Possible reasons

Authorizedkeys or .ssh permissions too open .ssh directory to 755 permissions authorizedkeys to 600th

Solve

Check the log: cat / var/log/secure found that Aug 8 17:15:13 CentOS62 sshd [5624]: Authentication refused: bad ownership or modes for file / home/abc/.ssh/authorized_keys check .ssh permission is 775. when SSH is manually created, it is 775 permissions, but it is normal after changing to 755 permissions # chmod 755 ~ /. Ssh

At this point, the study on "SSH login Linux server slow or login error solution" is over, I hope to be able to solve everyone's doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.