I have linux machine version red-hat 5.5.0

I have problem

if I perform from my machine ssh to other linux machine - node1 then I login quickly to node1

but if I perform ssh to other linux machine node2 then ssh take a long time

please advice why ?

what need to do in order to perform ssh immediately on node2 ?

remark - in ssh debug I get the - GSS failure ?

  • What OS / Software (putty) are you using to initiate the ssh connection? Have you compared the /etc/ssh/sshd_config files between the two machines?
    – NcA
    Mar 20, 2012 at 13:56
  • 1
    Try to use -v option with ssh for more info.
    – Khaled
    Mar 20, 2012 at 13:57
  • in ssh debug I get the - GSS failure - what this mean ???
    – yael
    Mar 20, 2012 at 14:08
  • The GSS failure is unrelated, it's simply another authentication method that you're not using.
    – Kyle Smith
    Mar 20, 2012 at 16:00
  • In my case it was ldap which was configured and I was trying to login using local user and since ldap was down so the server was waiting for ldap timeout before authenticating the user locally!! :(
    – Zelocox
    Jan 3, 2018 at 18:55

7 Answers 7


Since you are getting GSS failure, you can try adding:

GSSAPIAuthentication no

to /etc/ssh/sshd_config. Then restart the service

/etc/init.d/sshd restart
  • This resolved issues I experienced with the last few Ubuntu releases.
    – NcA
    Mar 20, 2012 at 14:23
  • I feel dirty suggesting to turn off the feature (it feels like pressing the Override button above an alarm), but why exactly is it breaking? If you have a bug report or some explanation let us know :)
    – gparent
    Mar 20, 2012 at 14:29
  • do you mean that GSSAPIAuthentication param isnt the problem but I need to find other problem in my linux machine
    – yael
    Mar 20, 2012 at 15:25
  • Well it's hard to say. It could be a Red Hat issue or maybe GSSAPI authentication isn't setup right, but if both servers are supposed to authenticate the same you would probably know if you can enable it or not.
    – gparent
    Mar 20, 2012 at 16:21
  • In short, GSSAPI Auth is looking to resolve kerberos.yourdomain.com when this is enabled. Unless you have a fully configured Kerberos server within your environment, you can safely disable this feature.
    – NcA
    Mar 20, 2012 at 22:06

Try adding the following line to /etc/ssh/sshd_config on node2:

UseDNS no

Then restart sshd:

/etc/init.d/ssh restart

Or if the above doesn't exist:

/etc/init.d/sshd restart
  • UseDNS no already in my machine ( under /etc/init.d/ I have only sshd )
    – yael
    Mar 20, 2012 at 13:58
  • Do you mean on your local machine, or on the server (node2)? Also what OSes are you running on all 3 machines?
    – xofer
    Mar 20, 2012 at 14:01
  • all machine are linux red-hat 5.X
    – yael
    Mar 20, 2012 at 14:06

Edit /etc/ssh/sshd_config on the server and add (if it's not there) at the bottom UseDNS no then restart the SSH daemon.

Will stop your machines from resolving DNS and will speed up the process.

  1. Take a look here: OpenSSH FAQ especially chapter 3.3. It also points to some other possible delay causes.
  2. or Most appropriate method to know the problem is to connect using ssh in debug mode:

    # ssh -v <Server name>
    OpenSSH_5.8p1 Debian-1ubuntu3, OpenSSL 0.9.8o 01 Jun 2010
    debug1: Reading configuration data /etc/ssh/ssh_config
    debug1: Applying options for *
    debug1: Connecting to mysql [] port 22.
    debug1: Connection established.
    debug1: permanently_set_uid: 0/0
    debug1: identity file /root/.ssh/id_rsa type -1
    debug1: identity file /root/.ssh/id_rsa-cert type -1
    debug1: identity file /root/.ssh/id_dsa type -1
    debug1: identity file /root/.ssh/id_dsa-cert type -1
    debug1: identity file /root/.ssh/id_ecdsa type -1
    debug1: identity file /root/.ssh/id_ecdsa-cert type -1
    debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
    debug1: match: OpenSSH_5.3 pat OpenSSH*
    debug1: Enabling compatibility mode for protocol 2.0
    debug1: Local version string SSH-2.0-OpenSSH_5.8p1 Debian-1ubuntu3
    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
    debug1: Server host key: RSA 1a:2c:c4:62:cc:27:1b:76:6b:f7:b2:38:00:7b:3f:63
    debug1: Host 'mysql' is known and matches the RSA host key.
    debug1: Found key in /root/.ssh/known_hosts:5
    debug1: ssh_rsa_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,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 Credentials cache file '/tmp/krb5cc_0' not found<br/>

    Line marked with arrow was causing the delay in my case. I commented out following line on the destination server and it resolved the issue in my case

    #GSSAPI options
    #GSSAPIAuthentication no
    #GSSAPIAuthentication yes
    #GSSAPICleanupCredentials yes
    #GSSAPICleanupCredentials yes
    #GSSAPIStrictAcceptorCheck yes
    #GSSAPIKeyExchange no

    restart the SSH daemon on the remote server and try to reconnect.. it s fine!

  3. Some versions of glibc (notably glibc 2.1 shipped with Red Hat 6.1) can take a long time to resolve “IPv6 or IPv4″ addresses from domain names. This can be worked around with by specifying AddressFamily inet option in ssh_config.
  4. There may be a DNS lookup problem, either at the client or server. You can use the nslookup command to check this on both client and server by looking up the other end’s name and IP address. In addition, on the server look up the name returned by the client’s IP-name lookup. You can disable most of the server-side lookups by setting UseDNS no in sshd_config.
  • To check for #4 above, you can test connecting using IPv4 with ssh -i <servername>. If that's the cause, you can then add AddressFamily inet to your ~/.ssh/config for this host.
    – Cyrille
    Nov 6, 2020 at 9:37

I found this answer too:

  1. Specify the option to disable GSSAPI authentication when using SSH or SCP command, e.g.: ssh -o GSSAPIAuthentication=no [email protected]


  1. Explicitly disable GSSAPI authentication in SSH client program configuration file, i.e. edit the /etc/ssh/ssh_config and add in this configuration (if it’s not already in the config file): GSSAPIAuthentication no


  1. Like 2 but in your private ssh config
    Edit /home/YOURUSERNAME/.ssh/config and add GSSAPIAuthentication no

=== BUG ===

When I try to connect to an ssh server (with ssh -v) I always have (my system is an Ubuntu 8.04):

debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure. Minor code may provide more information
No credentials cache found
debug1: Unspecified GSS failure. Minor code may provide more information
No credentials cache found
debug1: Unspecified GSS failure. Minor code may provide more information
debug1: Next authentication method: publickey

The fact is that on many servers the establishment of ssh connection is very slow because of this issue.



If you changed your hostname recently, update your /etc/hosts.

I have changed my hostname using hostnamectl set-hostname and updated IPv4 address in /etc/hosts, but forgot to update IPv6 address:              localhost            srv1.foobar.com
2a00:abc:123:6432::1   srv1.foobar.com

sshd created systemd sessions. In my case, with systemd with high load (near 100%), the ssh session only started after the systemd session request expired..

in my case, stopping other tasks, trying to restart systemd with systemctl daemon-reexec solved

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .