| |
Each using PuTTY SSH to log in to a remote Linux to manage time, remote login process is very slow - after you have finished entering a user name, not wait for about 30 seconds before it prompt for a password. In the actual deal with the problem, especially when the need to respond quickly, the situation is really unbearable.
But then specifically tested it and found it is not a common problem and each system, the problems are mainly concentrated in the machine CentOS, Debian same system, a remote connection is in the process of eighty, did not hesitate Caton feeling. Is this the CentOS problem?
Out of curiosity to see the differences between the two systems at the time of the SSH
CentOS:
ssh -v ssh_test@192.168.128.137
SSH remote login when the information is displayed as follows:
OpenSSH_6.0p1Debian-4, OpenSSL1.0.1e11Feb2013
... 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.0p1Debian-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 (1024 <1024 <8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
... Some sensitive information ...
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roamingnot allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey, gssapi-keyex, gssapi-with-mic, password
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
Can not determine realm for numeric host address
debug1: Unspecified GSS failure.Minor code may provide more information
Can not 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
Can not determine realm for numeric host address
debug1: Next authentication method: publickey
debug1: Tryingprivate key: /home/mitchellchu/.ssh/id_rsa
debug1: Tryingprivate key: /home/mitchellchu/.ssh/id_dsa
debug1: Tryingprivate key: /home/mitchellchu/.ssh/id_ecdsa
debug1: Next authentication method: password
The results of Debian using the same command to test for:
OpenSSH_6.0p1Debian-4, OpenSSL1.0.1e11Feb2013
... Some sensitive information ...
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.0p1Debian-4
debug1: match: OpenSSH_6.0p1Debian-4 pat OpenSSH *
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.0p1Debian-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: 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: Roamingnot 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: Tryingprivate key: /home/mitchellchu/.ssh/id_rsa
debug1: Tryingprivate key: /home/mitchellchu/.ssh/id_dsa
debug1: Tryingprivate key: /home/mitchellchu/.ssh/id_ecdsa
debug1: Next authentication method: password
Can be seen from the above, in CentOS, the system uses the publickey, gssapi-keyex, gssapi-with-mic, and password to authenticate (above color-coded lines, line 23), but this time using the Debian Publickey and password two kinds. When connecting CentOS at 23 at line spent a considerable amount of time. We started to look down there, you can very clearly see the following information:
# The following are used for authentication GSSAPI-KEYEX
debug1: Next authentication method: gssapi-keyex
# But given: Key is not available to exchange information
debug1: No valid Key exchange context
# The system then they use the next authentication method: GSSAPI-WITH-MIC
debug1: Next authentication method: gssapi-with-mic
# Unfortunately, GSSAPI-WITH-MIC method also fails.
# Cause: The host address can not be determined digital domain
debug1: Unspecified GSS failure.Minor code may provide more information
Can not determine realm for numeric host address
debug1: Unspecified GSS failure.Minor code may provide more information
Can not 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
Can not determine realm for numeric host address
# After several attempts, SSH authentication finally abandoned this verification. Proceed to the next verification: Publickey
debug1: Next authentication method: publickey
In addition to this method there are other ways it? The nature is there, CentOS fact, has provided us with a solution - the use of ssh remote login is disabled when GSSAPI authentication. Of course, there is a problem had to be aware that if your machine is enabled UseDNS then need to be closed, the final details, see the instructions.
As can be seen from the error should be the host and domain-related - should be unable to confirm the corresponding IP domain, so there will be the problem. GSSAPI is mainly based on Kerberos, so to solve this problem will become to be configured with Kerberos system, which for no cheese are Kerberos, the Kerberos configuration on a log in order to solve a latency problem, it does not seem a wise decision - especially in a production environment! Minimize meet demand is crucial.
GSSAPI method for processing prior release below
There are two ways to disable GSSAPI authentication: client and server
1. The client is disabled
Relatively simple, only a single client user impact, you can use the following ways:
ssh -o GSSAPIAuthentication = no your-server-username @ serverIP
Remote login using the above method, you can achieve disabled GSSAPIAuthentication.
If you troublesome, directly configure your ssh client file / etc / ssh / ssh_config to achieve a permanent solution to this problem:
vi / etc / ssh / ssh_config
### Ssh_config file found inside this line GSSAPIAuthentication yes
### Is amended as GSSAPIAuthentication no
Save the file and exit ### ssh_config
This modification method is to place all the users on the machine are affected, if you impact was not so widely, as long as the user specified implementation disable GSSAPIAuthentication, then you can be in the user's directory, locate the .ssh directory, Add the following in its config file, and add the phrase in the document above, if it does not, you can do this:
cat >> ~ / .ssh / config << EOF
GSSAPIAuthenticationno
EOF
When using the cat, the inputs are directly exported to a file, this time, you use ssh to connect to remote target host, it will no longer use GSSAPI authenticated.
These files are above the client, not the server-side. That is, to modify this file, your client will have to be Linux job.
If you are using PuTTY client tools such under Windows, do not use the above method, the next you can try before you connect PuTTY settings:
PuTTY Configuration -> Connection -> SSH -> Auth -> GSSAPI -> (uncheck) Attempt GSSAPI authentication (SSH-2 only)
If you do not close the PuTTY GSSAPIAuthentication, you can connect the right window: View log (or Ctrl + right), you can be found PuTTY will automatically try to log GSSAPI connection:
2014-05-1823: 46: 54Using SSPI from SECUR32.DLL
2014-05-1823: 46: 54Attempting GSSAPI authentication
2014-05-1823: 46: 54 GSSAPI authentication request refused
Well, substantially above the client list of prohibited methods GSSAPIAuthentication a bit.
NOTE: The above methods are more generic.
2, if you have configured your Kerberos next
Then you can also try under the following clients to solve this issue:
Add the host name of the remote host to your native host file (Linux is the / etc / hosts, Windows is a system disk: \ Windows \ System32 \ drivers \ etc \ hosts). Under Linux and Windows can add the following line.
### NOTE: The following such an IP-Addr asked to replace the IP address of your remote machine, HostName, nature is the host name
IP-AddrHostName
After the addition is complete, save and exit.
If you do not have to configure Kerberos, then only the hosts file configuration is the same as not solve the problem, use ssh to log in, you can see the error log similar to the following:
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
This error in the beginning I was also guilty of, need attention.
3, the server is disabled GSSAPIAuthentication.
Directly to the / etc / ssh / sshd_config inside the GSSAPIAuthentication yes to no to, and also note that you may also need to change it back to the UseDNS UseDNS no (pay attention to this, different default values for each system, CentOS 6 here for an example):
sudo vi / etc / ssh / sshd_config
### Ordinary user permissions is not enough, you need root privileges
### Found GSSAPIAuthentication yes, modify
### GSSAPIAuthentication no
### Note that here you also need to be modified to UseDNS no, CentOS default is yes, even though the line is a comment, you need to add
### UseDNS no
### Have seen people say UseDNS yes do not need to modify UseDNS no, Mitchell test down is needed.
### Save the file and exit
When disabled, we need to restart the SSH service to ensure that the new profile is applied properly:
service sshd restart
At this time, again using SSH to log the host, you are not feeling the fast?
Call ~ finally completed this long article, to come up with these side while Daoteng a text, or really a bit difficult. However, this problem will also Daoteng almost, I hope you can see the article see and understand, welcome to the discussion.
Explanation:
1. GSSAPI: Generic Security Services Application Program Interface, GSSAPI itself is a set of API, standardized by the IETF. Its implementation is the most important and famous Kerberos-based. Speaking generally are alluding GSSAPI Kerberos implementations.
2. UseDNS: a DNS lookup on the OpenSSH server option, and the default is left open in the open state, whenever a client attempts to connect to OpenSSH server, the server will automatically DNS PTR anti-user according to the client's IP to the query (IP reverse analysis will have a record), check out the corresponding IP Hostname, then according to the client's DNS Hostname carried forward a record queries. Through this inquiry, verification IP and whether the connected client IP agreement. But the vast majority of our machines is dynamic IP, which means that this option for this case did not even use - even ordinary static IP server, as long as not doing IP reverse analysis, it is difficult to apply. If you meet these conditions, it is recommended to close UseDNS to improve SSH remote login when the authentication speed. |
|
|
|