skip to Main Content

This command will succeed from a local Fedora-36 VM to a local CentOS 7.9 VM (same host) but will fail to an almost identical but remote CentOS 7.9 VM:

$ scp -vvv foobar user@host:

The verbose log in both cases is:
Successful case:

...
debug1: Sending subsystem: sftp
debug2: channel 0: request subsystem confirm 1
debug3: send packet: type 98
debug2: channel_input_open_confirmation: channel 0: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel 0: rcvd adjust 2097152
debug3: receive packet: type 99
debug2: channel_input_status_confirm: type 99 id 0
debug2: subsystem request accepted on channel 0
scp: debug2: Remote version: 3
scp: debug2: Server supports extension "[email protected]" revision 1
scp: debug2: Server supports extension "[email protected]" revision 2
scp: debug2: Server supports extension "[email protected]" revision 2
scp: debug2: Server supports extension "[email protected]" revision 1
scp: debug2: Server supports extension "[email protected]" revision 1
scp: debug3: Sent message fd 6 T:17 I:1
scp: debug3: Recevied stat reply T:105 I:1 F:0x000f M:40700
scp: debug3: source_sftp: copying local foobar to remote ./foobar
scp: debug3: Sent dest message SSH2_FXP_OPEN I:2 P:./foobar M:0x001a
scp: debug3: Sent message SSH2_FXP_WRITE I:4 O:0 S:2
scp: debug3: SSH2_FXP_STATUS 0
scp: debug3: In write loop, ack for 4 2 bytes at 0
scp: debug3: Sent message SSH2_FXP_CLOSE I:3
scp: debug3: SSH2_FXP_STATUS 0
debug2: channel 0: read<=0 rfd 4 len 0
debug2: channel 0: read failed
debug2: chan_shutdown_read: channel 0: (i0 o0 sock -1 wfd 4 efd 6 [write])
debug2: channel 0: input open -> drain
debug2: channel 0: ibuf empty
debug2: channel 0: send eof
debug3: send packet: type 96
debug2: channel 0: input drain -> closed
debug3: receive packet: type 98
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug3: receive packet: type 96
debug2: channel 0: rcvd eof
debug2: channel 0: output open -> drain
debug2: channel 0: obuf empty
debug2: chan_shutdown_write: channel 0: (i3 o1 sock -1 wfd 5 efd 6 [write])
debug2: channel 0: output drain -> closed
debug3: receive packet: type 97
debug2: channel 0: rcvd close
debug3: channel 0: will not send data after close
debug2: channel 0: almost dead
debug2: channel 0: gc: notify user
debug2: channel 0: gc: user detached
debug2: channel 0: send close
debug3: send packet: type 97
debug2: channel 0: is dead
debug2: channel 0: garbage collecting
debug1: channel 0: free: client-session, nchannels 1
debug3: channel 0: status: The following connections are open:
  #0 client-session (t4 r0 i3/0 o3/0 e[write]/0 fd -1/-1/6 sock -1 cc -1)

debug3: send packet: type 1
Transferred: sent 3428, received 3156 bytes, in 0.3 seconds
Bytes per second: sent 12806.6, received 11790.4
debug1: Exit status 0

Failure case:

...
debug1: Sending subsystem: sftp
debug2: channel 0: request subsystem confirm 1
debug3: send packet: type 98
debug2: channel_input_open_confirmation: channel 0: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug3: send packet: type 1
client_loop: send disconnect: Broken pipe
scp: Connection closed

What I’ve tried:

  • use the original scp protocol instead of sftp with option -O
  • check that sftp-server is available and configured in the target sshd configuration
  • reduce the MTU from 1500 to 1000 on the client side
  • add option -o ServerAliveInterval=600 on the client side
  • removed the client key from ~/.ssh/authorized_keys on the target

2

Answers


  1. Chosen as BEST ANSWER

    The fix was provided by this answer:

    Add this to ~/.ssh/config on the client side:

    Host github.com
      IPQoS 0x00
    

    • Did you check 22 port? Is it open?
    • Did you have any activated firewall?
    • Did you try using an ftp client? filezilla for exemple?
    Login or Signup to reply.
Please signup or login to give your own answer.
Back To Top
Search