'Not working scp command: Connection closed by remote host (Mac OS X)

I'm working on a remote server through Mac terminal, since I updated it to OSX 10.10 from 10.5 I started receiving this message every time I try to scp from the server to my computer:

ssh_exchange_identification: Connection closed by remote host
lost connection

If I perform scp backwards (copying from mac to server) it works just fine, and it works fine if I do it form another mac.

If I do a verobse scp, it gives me this:

Executing: program /usr/bin/ssh host xx.xx.xx.x, user User, command scp -v -t /Users/User
OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to xx.xx.xx.x [xx.xx.xx.x] port 22.
debug1: Connection established.
debug1: identity file /home/user/.ssh/identity type -1
debug1: identity file /home/user/.ssh/identity-cert type -1
debug1: identity file /home/user/.ssh/id_rsa type -1
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
lost connection

I tried looking in the various host, config, ssh files but I didn't mange to solve much.



Solution 1:[1]

Check the target user's .bashrc or equivalent file. ~/.bashrc is sourced for non-interactive logins. If there's an echo or command that outputs anything, it will break the SCP protocol.

Solution 2:[2]

I got this problem too.

I tried "sudo sshd -t" , but there seemed no problem.

Then I checked my "hosts.allow" & "hosts.deny", no problem ether.

Finally I found out that I use the '~' path int the command, here's it:

scp ~/Downloads/afile root@host2:~/Downloads

I changed it to the following one:

scp /home/Downloads/afile root@host2:/home/Downloads

And it works now. Hope this can help.

Solution 3:[3]

'sudo sshd -t' clearly showed which config line is not valid. Got over the SCP problem once commenting that config line. Thanks a lot for answers.

Solution 4:[4]

System Preferences pane ? Sharing applet ? check the Remote Login checkbox. This will enable SSH, and in turn, SCP.

Solution 5:[5]

I was getting same error when I was using scp -P [wrong_custom_port] user@host:/source /destination

After googling for a while and not finding any direct answers I finally realized that I was using different custom port number for my ssh connection on remote host.

Hope this to help someone with similar problem.

Solution 6:[6]

i'll throw my hat in the ring on this one.

i got bit ? by this issue today trying to scp a file from one computer on my LAN to my macbook, and got presented with the lovely message to STDOUT

scp: Connection closed

that didn't really give me much to work with and adding -VVVV didn't show any glaring issues, though using -VVVV when stuff like this isn't working is not something that i look at everyday (may have missed something).

all that said, the above commands of sudo sshd -t printed nothing to STDOUT.

so where to go from here, fortunately i've experienced issues with ssh in the past, and IMHO the easiest way to get a sane message on why a certain ssh related task ie. scping a file to ssh server of some sort is to stop the currently running server and start it in debug mode from a terminal in a foreground process (it may be possible start another ssh server to prevent stopping the existing one if an ssh config file is set properly (not something i've looked into)), but for my use, stopping the existing server and launching a new instance of it in debug works wonders ????, so running

sshd -d

and then attempting to send a file to the server i see the following lines in STDOUT

debug1: server_input_channel_req: channel 0 request subsystem reply 1
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req subsystem
debug1: subsystem: cannot stat /usr/local/Cellar/openssh/8.8p1/libexec/sftp-server: No such file or directory
debug1: subsystem: exec() /usr/local/Cellar/openssh/8.8p1/libexec/sftp-server
Starting session: subsystem 'sftp' for capin from 10.0.1.42 port 63866 id 0
debug1: Received SIGCHLD.
debug1: session_by_pid: pid 2107
debug1: session_exit_message: session 0 channel 0 pid 2107
debug1: session_exit_message: release channel 0
Received disconnect from 10.0.1.42 port 63866:11: disconnected by user
Disconnected from user capin 10.0.1.42 port 63866
debug1: do_cleanup
debug1: do_cleanup
debug1: PAM: cleanup
debug1: PAM: closing session
debug1: PAM: deleting credentials

which makes me think those error/warning messages are my issue, and to continue troubleshooting from there.

Solution 7:[7]

User on server and on your desktop have to create keys locally before using ssh (or scp). You can create a strong key (algorithm RSA and length 4096) with this command :

ssh-keygen -t rsa -b 4096 -C "username"

If you already have key on your server check permission on ~/.ssh dir

As mentioned here, owner of .ssh dir and file in this directory must be your user. Permission on .ssh dir must be 700 (drwx------), private key files 600 (-rw------) and public key must be 644 (-rw-r--r--). You can check this with :

ls -alh

If it is not the case you can change this :

   chown -R username ~/.ssh
   chmod 700 ~/.ssh
   chmod 600 ~/.ssh/id_*
   chmod 644 ~/.ssh/*.pub

Sources

This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.

Source: Stack Overflow

Solution Source
Solution 1 Vinay Shukla
Solution 2 Norman Bai
Solution 3 Raja Sekhar M
Solution 4 Sandeep Chandel
Solution 5 Mojtaba Rezaeian
Solution 6
Solution 7 Community