15

A server I can ssh into fine has begun refusing to scp.

$ scp ~/tmp/foo [email protected]:~/tmp/ lost connection

With scp -v -v I can see the connection succeeds and the transfer appears to succeed, but no file appears on the other side.

OpenSSH_5.9p1, OpenSSL 0.9.8r 8 Feb 2011 debug1: Reading configuration data /Users/schwern/.ssh/config debug1: /Users/schwern/.ssh/config line 1: Applying options for * debug1: Reading configuration data /etc/ssh_config debug1: /etc/ssh_config line 20: Applying options for * debug2: ssh_connect: needpriv 0 debug1: Connecting to testcurrent01.dev.liquidweb.com [10.30.152.254] port 22. debug1: Connection established. debug1: identity file /Users/schwern/.ssh/id_rsa type -1 debug1: identity file /Users/schwern/.ssh/id_rsa-cert type -1 debug1: identity file /Users/schwern/.ssh/id_dsa type -1 debug1: identity file /Users/schwern/.ssh/id_dsa-cert type -1 debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3 debug1: match: OpenSSH_4.3 pat OpenSSH_4* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_5.9 debug2: fd 3 setting O_NONBLOCK debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received ...lots of authentication details... debug1: Enabling compression at level 6. debug1: Authentication succeeded (publickey). Authenticated to [email protected] ([1.2.3.4]:22). debug2: fd 5 setting O_NONBLOCK debug2: fd 6 setting O_NONBLOCK debug1: channel 0: new [client-session] debug2: channel 0: send open debug1: Entering interactive session. debug2: callback start debug2: client_session2_setup: id 0 debug2: fd 3 setting TCP_NODELAY debug1: Sending environment. debug1: Sending env LANG = en_US.UTF-8 debug2: channel 0: request env confirm 0 debug1: Sending command: scp -v -t -- ~/tmp/ debug2: channel 0: request exec confirm 1 debug2: callback done debug2: channel 0: open confirm rwindow 0 rmax 32768 debug2: channel 0: rcvd adjust 2097152 debug2: channel_input_status_confirm: type 99 id 0 debug2: exec request accepted on channel 0 debug2: channel 0: rcvd eof debug2: channel 0: output open -> drain debug2: channel 0: obuf empty debug2: channel 0: close_write debug2: channel 0: output drain -> closed debug1: client_input_channel_req: channel 0 rtype exit-status reply 0 debug2: channel 0: rcvd close debug2: channel 0: close_read debug2: channel 0: input open -> closed debug2: channel 0: almost dead debug2: channel 0: gc: notify user debug2: channel 0: gc: user detached debug2: channel 0: send close debug2: channel 0: is dead debug2: channel 0: garbage collecting debug1: channel 0: free: client-session, nchannels 1 debug1: fd 0 clearing O_NONBLOCK debug1: fd 1 clearing O_NONBLOCK Transferred: sent 4576, received 2520 bytes, in 0.0 seconds Bytes per second: sent 167737.0, received 92372.6 debug1: Exit status 0 debug1: compress outgoing: raw data 135, compressed 121, factor 0.90 debug1: compress incoming: raw data 66, compressed 52, factor 0.79 lost connection

It is a CentOS 5.9 machine.

Things I've checked...

  • I have permission to write to that directory.
  • The user has a sensible shell (/bin/bash).
  • I tried moving my ~/.ssh/config out of the way.
  • scp'ing to that machine from others with entirely different operating systems also fail.
  • The disk is not full.
  • Restarting sshd.

/var/log/secure contains...

Apr 4 14:23:22 some sshd[12576]: Postponed publickey for user from 1.2.3.4 port 33581 ssh2 Apr 4 14:23:22 some sshd[12575]: Accepted publickey for user from 1.2.3.4 port 33581 ssh2 Apr 4 14:23:22 some sshd[12575]: pam_unix(sshd:session): session opened for user user by (uid=0) Apr 4 14:23:22 some sshd[12575]: pam_unix(sshd:session): session closed for user user

What might I check next?

Improve this question
10
  • 2
    Not the error I would expect, but just in case, do your ~/.bashrc or ~/.profile or /etc/bash.bashrc or /etc/profile print anything to STDOUT? bugzilla.redhat.com/show_bug.cgi?id=20527. And I assume you are using Linux? Commented Apr 4, 2013 at 14:16
  • Nope. I just get the usual Last login: Thu Apr 4 10:15:28 2013 from 1.2.3.4. Commented Apr 4, 2013 at 14:18
  • Anything in any of the system logs on the target host? Commented Apr 4, 2013 at 14:21
  • @Flup Looks normal. I posted what shows up in the logs when I connect. Commented Apr 4, 2013 at 18:25
  • Could you start strace -f -o /tmp/sshd.strace -p [pid of sshd] on the server, try again, then post anything from that file that looks relevant? Commented Apr 5, 2013 at 7:06

6 Answers 6

Reset to default
6

Had the same issue.

If you did a minimal install of Centos, it only install the openssh and openssh-server packages but not the openssh-clients. sudo yum install openssh-clients will fix your issue.

Improve this answer
1
  • I don't have access to that machine anymore, but that seems a likely answer. Commented Nov 13, 2014 at 21:26
8

scp works by invoking the ssh program to make a connection to the remote host, launching another copy of the scp program on that host. The two scp instances communicate through the ssh connection to perform the file transfer.

"lost connection" is printed by the local scp program when the ssh connection drops prematurely. The usual reason for that is the scp program on the remote host either failed to start or else it exited prematurely. This could have happened because the scp program doesn't exist on the remote host, or it's not in your command PATH, or it's not marked executable, or it crashed after starting, or something along those lines.

Improve this answer
2
  • The first paragraph describes a situation where scp uses SCP (the protocol). Nowadays scp (at least from OpenSSH) can and does use SFTP instead. I'm aware the answer is old, I believe it's still useful; and maybe (I really don't know) one cannot get a message saying exactly "lost connection" from scp using SFTP, so maybe the message implies SCP. Nevertheless in 2023, in general, the first paragraph itself is somewhat obsolete. More information in this answer. This is not a criticism (I have upvoted the answer), just some up-to-date facts. Commented Nov 4, 2023 at 17:03
  • I have noticed you know a lot about SSH, so most likely the above comment is not for you, it's for future readers who otherwise might take the first paragraph and imagine that even the modern scp works this way, always. Maybe we should update the answer itself, just for the sake of sharing knowledge. I did not (and do not) want to do this without your consent though. Commented Nov 4, 2023 at 17:10
1

If you happen to be running the ufw package and have port 22 set with sudo ufw limit 22, you will need to open it up with:

sudo ufw allow 22

Check status with:

sudo ufw status
Improve this answer
0

We recently had this issue on one of our systems.

We could appropriately ssh onto the host server, but discovered we could not ssh from the server back onto the machine. This is a good place to investigate, if you cannot do this then you will not be able to use SCP.

In our case, somehow (perhaps a botched install) had replaced our ssh binary files with 0 byte empty files. Whenever "ssh" was executed, nothing happened.

By reinstalling openssh-clients, we rectified the binaries and scp started to work.

yum reinstall openssh-clients

Improve this answer
0

In my case the root cause was burstable virtual machine in Azure which drops the connection once your IOPS credit are expired which happened exactly during scp upload.

Resizing to D series helped.

Improve this answer
0

I had this problem because I made a mistake in my shell startup script. As in this answer, I had replaced the return near the top of .bashrc with an exit. Undoing that change fixed scp, rsync, and non-interactive ssh for me.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.