Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.
debug1: Connection established.
debug1: identity file /home/DAMS/.ssh/id_rsa type 1
debug1: identity file /home/DAMS/.ssh/id_rsa-cert type -1
debug1: identity file /home/DAMS/.ssh/id_dsa type -1
debug1: identity file /home/DAMS/.ssh/id_dsa-cert type -1
ssh_exchange_identification: Connection closed by remote host

hello this one is different . no missing or anything. im using cygwin. and it just stop when im doing git push production on my server. usually its ok, but i dont know why its stop connections

i wonder whats wrong.

share|improve this question
    
Was this ever solved ? I have the same issue. –  Zitrax Jan 25 '11 at 17:41

6 Answers 6

I still don't understand the issue, but this worked for me:

echo "sshd:ALL" >> /etc/hosts.allow 

Depending on your system, you may need to sudo this.

share|improve this answer

Another possibility is that the server is using tcp wrappers and your IP is not whitelisted.

share|improve this answer

You can start sshd in debug mode on your server to find out what's actually going wrong, but I have a pretty good feeling that your problem is that either your ~/.ssh directory or your ~/.ssh/authorized_keys file is world-readable on the server.

share|improve this answer
    
what should i do then ? –  user51684 Dec 16 '10 at 4:00
    
btw there is no dir ~/.ssh or ~/.ssh authorized key. but yesterday it allwork fine. –  user51684 Dec 16 '10 at 5:36
    
bash: /root/.ssh/authorized_keys: No such file or directory –  user51684 Dec 16 '10 at 5:37
    
authorized_keys2 –  Zayne S Halsall Dec 26 '12 at 11:27

likely cannot write to /var/ area for process accounting. check for full or readonly file systems on the host system.

share|improve this answer
    
how can i do that ? on my server ? –  user51684 Dec 16 '10 at 5:24

If you are using shared keys it looks like either:

  1. you haven't specified the correct private key; or
  2. your public key is (no longer?) in your server's authorized_keys file; or
  3. as jgoldshrafe suggests, the permissions on your authorized_keys file is incorre
share|improve this answer

The error suggests that the connection was closed during the initial negotiation. I would guess that if you telnet to the server on port 22 that the connection is accepted and then closed again straight away?

share|improve this answer

Your Answer

 
discard

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.