If you just upgraded your client, you may want to check if the -O
option is relevant. I just upgraded my Cygwin, and the scp client changed to using the newer SFTP protocol by default, which usually works fine but fails badly for one of the old servers we still have running:
-O Use the legacy SCP protocol for file transfers instead of the SFTP
protocol. Forcing the use of the SCP protocol may be necessary for
servers that do not implement SFTP, for backwards-compatibility for
particular filename wildcard patterns and for expanding paths with
a '~' prefix for older SFTP servers.
Even verbose debugging told me nothing useful except that there were no overt errors, but adding -O
to the command line corrected the problem:
scp -O [email protected]:file\* .
The verbose output (below) might indicate that somewhere, but my knowledge of the protocol isn't quite good enough to interpret the packets :)
bash$ scp -vvvv [email protected]:file\* .
Executing: program /usr/bin/ssh host host.net, user user, command sftp
OpenSSH_9.0p1, OpenSSL 1.1.1p 21 Jun 2022
...
debug1: Authentications that can continue: publickey,keyboard-interactive,password
debug3: userauth_kbdint: disable: no info_req_seen
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred:
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
[email protected]'s password:
debug3: send packet: type 50
debug2: we sent a password packet, wait for reply
debug3: receive packet: type 52
Authenticated to host.net ([192.168.1.32]:22) using "password".
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug3: send packet: type 90
debug1: Entering interactive session.
debug1: pledge: filesystem
debug3: receive packet: type 91
debug2: channel_input_open_confirmation: channel 0: callback start
debug2: fd 4 setting TCP_NODELAY
debug3: set_sock_tos: set socket 4 IP_TOS 0x20
debug2: client_session2_setup: id 0
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 16384
debug2: channel 0: rcvd adjust 32768
debug3: receive packet: type 99
debug2: channel_input_status_confirm: type 99 id 0
debug2: subsystem request accepted on channel 0
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: (i0 o1 sock -1 wfd 6 efd 7 [write])
debug2: channel 0: output drain -> closed
debug3: receive packet: type 97
debug2: channel 0: rcvd close
debug2: chan_shutdown_read: channel 0: (i0 o3 sock -1 wfd 5 efd 7 [write])
scp: Connection closed
debug2: channel 0: input open -> closed
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/7 sock -1 cc -1 io 0x00/0x00)
debug3: send packet: type 1
Transferred: sent 1960, received 1512 bytes, in 0.2 seconds
Bytes per second: sent 11090.3, received 8555.4
debug1: Exit status 1
bash$
scp file server:
(assuming "server" is a valid hostname), the file is copied to your account directory.scp
to a different location on the server, then acp
ormv
afterssh