Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I cant connect to a server via sftp any more, I could yesterday. Here is the full sftp -vvv log, maybe you could help me out? Tried deleting ~/.ssh, tried hosts.allow / hosts.deny. No solution at all.

Any suggestions?

sftp -vvvvvv -P 1313 user@xx.dyndns.org
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to xx.dyndns.org [xx.xx.xx.xx] port 1313.
debug1: Connection established.
debug3: Incorrect RSA1 identifier
debug3: Could not load "/home/user/.ssh/id_rsa" as a RSA1 public key
debug1: identity file /home/user/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: identity file /home/user/.ssh/id_rsa-cert type -1
debug1: identity file /home/user/.ssh/id_dsa type -1
debug1: identity file /home/user/.ssh/id_dsa-cert type -1
debug1: identity file /home/user/.ssh/id_ecdsa type -1
debug1: identity file /home/user/.ssh/id_ecdsa-cert type -1
ssh_exchange_identification: Connection closed by remote host
Couldn't read packet: Connection reset by peer
share|improve this question
Try from another computer. If it has the same problem, your computer is not the cause. –  SPRBRN Mar 26 '13 at 14:50

2 Answers 2

The remote host's SSH server appears to be trying to treat /home/user/.ssh/id_rsa as a public key, which, judging by the debug output, it is not -- if it's a keyfile at all, most likely it's a private key, as 'id_rsa' is the default filename for output from the ssh-keygen command.

Move or delete that file on the remote host, as well as any corresponding entries in /home/user/.ssh/config on the remote host (assuming you can get to it by some other means, of course), and you'll most likely be able to connect successfully and authenticate via password, assuming that's enabled in /etc/ssh/sshd_config -- once you're able to connect and get a shell as the remote user, you can debug further from there.

share|improve this answer

I disagree with Aaron - this is normal behavior. See this - I also just tested a successful SFTP connection with -vvvvv, and got the same message.

I think you should check /var/log/auth.log (if Debian/Ubuntu/etc.) or /var/log secure (if RH, Fedora, etc.) on the remote computer. You should see a more informative error.

Also check the file permissions on the files on the remote server - ~/.ssh, ~/.ssh/authorized_keys They should be readable by your user, and authorized_keys should have 600 as its permissions. Can you still SSH to that 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.