Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm having problem with logging into my local-network-linux (server) ssh with Putty (and with Linux terminal, too)

When my server shows me request to insert username, I insert "root" and I do press enter.

I am waiting about seven seconds before it requests my password!

I also looked at this question

and tried accepted answer, also with command

/etc/init.d/ssh restart

It didn't work. My friend told me that I should have to use another SSH deamon, but I don't know which. What could I do now?

my current /etc/ssh/ssh_config config:

# configuration file, and defaults at the end.

# Site-wide defaults for some commonly used options.  For a comprehensive
# list of available options, their meanings and defaults, please see the
# ssh_config(5) man page.

Host *
#   ForwardAgent no
#   ForwardX11 no
#   ForwardX11Trusted yes
#   RhostsRSAAuthentication no
#   RSAAuthentication yes
#   PasswordAuthentication yes
#   HostbasedAuthentication no
  GSSAPIAuthentication no
   GSSAPIDelegateCredentials no
   GSSAPIKeyExchange no
#   GSSAPITrustDNS no
#   BatchMode no
#   CheckHostIP yes
#   AddressFamily any
#   ConnectTimeout 0
#   StrictHostKeyChecking ask
#   IdentityFile ~/.ssh/identity
#   IdentityFile ~/.ssh/id_rsa
#   IdentityFile ~/.ssh/id_dsa
#   Port 22
#   Protocol 2,1
#   Cipher 3des
#   Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc
#   MACs hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160
#   EscapeChar ~
#   Tunnel no
#   TunnelDevice any:any
#   PermitLocalCommand no
#   VisualHostKey no
#   ProxyCommand ssh -q -W %h:%p gateway.example.com
    SendEnv LANG LC_*
    HashKnownHosts yes
share|improve this question
up vote 2 down vote accepted

You don't need another SSH daemon. You may need to explicitly disable (as opposed to simply commenting out) GSSAPIAuthentication and GSSAPIKeyExchange in the client; the other question didn't mention the latter, probably because it's a recent addition and I think it's still vendor-applied third party patches. (Debian Squeeze, at least, definitely has it.) GSSAPIDelegateCredentials doesn't need to be touched, as it is only looked at when GSSAPIAuthentication is enabled.

If the above doesn't do it, your nest step is to use strace to see what it's doing during the pause.

strace /usr/bin/ssh -vvv host

This assumes it's the client end; the server is a bit harder to debug. If it comes to that, you will need to disable the normal server (in the modern world this is service ssh stop) and then do something like

sudo strace -f /usr/sbin/sshd -ddd

Don't forget to reactivate the normal server with service ssh start afterward!

share|improve this answer
It still takes a long of time to show it, maybe the same – genesis Jul 12 '11 at 19:02
@genesis: was editing when you commented; see revision. – geekosaur Jul 12 '11 at 19:05
I'll have to try it on linux (PC) right? – genesis Jul 12 '11 at 19:06
when I tried "root@kufr:/etc/ssh# ssh localhost root@localhost's password: " it was imediatelly :/ – genesis Jul 12 '11 at 19:08
your last edit: "root@kufr:~# service sshd stop sshd: unrecognized service " – genesis Jul 12 '11 at 19:13

Could be a DNS issue, if so try uncommenting:

#   GSSAPITrustDNS no

so that it becomes

   GSSAPITrustDNS no

It will work around the issues for now, however the real fix is to fix the DNS problem. As a side note adding -vvv to your SSH command will print out a lot more information and give you a better idea of where to look e.g.:

ssh -vvv <user>@<server>
share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.