If I want to send something via scp to server:
scp file server:
_____ _____ _____
Then three lines are printed and file is not copied. However I can connect to server via ssh without problem:
ssh server
How to make scp work?
One possible cause of this type of behavior is having any message print out during the login process on server. Scp depends on ssh to provide a totally transparent encrypted tunnel between the client and the server.
Check all of the login scripts on the server, and also try using a different user. Another method of identifying the source of the error is to use the -v in the command, to trace the progress of the transaction, and see where it fails. You can use up to -vvv to increase the verbosity, if necessary. Checking the various forms of scp can also be instructive, as listed in the post by InChargeOfIT.
scp, under the hood, sets up a tunnel using ssh, and then transfers the file over that tunnel, with a ssh command on the far end to catch the file as it comes over. This is illustrated by the use of tar and ssh to copy a directory structure preserving ownership and creation times with the following commands:
tar czf - ./* | ssh jf@otherserver.com tar xzf - -C ~/saved_tree
to send it over, and
ssh jf@otherserver.com "tar czf - ~/saved_tree" | tar xzvf - -C ./
to get it back.
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.
Are you positive you are entering in a valid path in the scp command? For example:
scp test.txt username@remoteserver.com
will fail (in fact, it will just print out the command like you are seeing). In this case, you will need to provide a valid path to the remote server.. e.g., scp test.txt username@remoteserver.com:~/
Example usages:
Send a file:
scp /path/to/local/file yourremoteusername@servername.com:/path/to/remote/directory
Get a file:
scp yourremoteusername@servername.com:/path/to/remote/file /path/to/local/directory
Examples:
Send a file from my Desktop to my home folder on a remote server:
scp ~/Desktop/myfile.txt john_doe@10.1.1.10:~/
Remember the ~ is a shortcut for your home directory... e.g., /home/
Send a file to the the webroot:
scp ~/Documents/working/index.html john_doe@johndoe.com:/var/www/index.html
In this example, the user john_doe would need write privileges on the remote /var/www directory.
On some hosts they incorrectly source .bash_profile for non-interactive logins like scp. Messages that get printed to the terminal can possibly cause scp to not function correctly. If you have messages in your .bash_profile this can be the cause.
To still have your login messages, banner, etc. display on interactive logins and still be able to use scp via a non-interactive login add the following before any message that would print out in your .bash_profile file.
# ********** If not running interactively, don't do anything more! ***********
[ -z "$PS1" ] && return
Alternative code is:
[[ $- == *i* ]] || return
And another alternative code:
case $- in
*i*) ;;
*) return;;
esac
Which I believe is the longer version of the first alternative code. I have found on some hosts the first code does not work correctly but the second one does.
During a non-interactive scp login it will abort further execution of .bash_profile and allow scp to work, but will display your login messages when you login via ssh.
Note: This can also be used in your .bashrc file if you source it from .bash_profile (for $PATH) so only part of it is sourced during non-interactive logins.
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 user@host.net: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 user@host.net: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
user@host.net'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$
When troubleshooting ssh/scp, it's a good idea to add the -v option for verbose output. You may also want to specific the user on the remote server. Lastly, it is sometimes helpful to copy the file to a temporary place such as /tmp where you know you have write permissions. For example, to send a hello world file to the remote server with verbose on, the syntax would be:
scp -v hello_world.txt username@server-uri:/tmp
Replace username with a user that exists on that system and of course replace the server-uri with the actual server FQDN or IP Address.
This does not answer the question directly, but might be helpful for folks like me, looking for a solution with a freezing scp when transferring files between 2 remote hosts.
If scp hangs because of messages from ssh, it could helpt to surpress them:
scp -o "StrictHostKeyChecking no"
and / or
scp -B
From the scp man:
-B Selects batch mode (prevents asking for passwords or passphrases).
-o ssh_option Can be used to pass options to ssh in the format used in there is no separate scp command-line flag. For full details of the options listed below, and their possible values, see ssh_config(5).
In my case that seemed to help, but did not solve the whole issue. We could not find out why scp hangs when transferring from remote to remote. It hung in the middle of the file. 9 times it worked, attempt number 10 did not. We suspected it could be that it hangs when our VPN connection gets a traffic spike for a moment and then scp does not recover. It really just hangs forever and does not even give an error message.
However, I gave up and switched to sftp. This is reasonably faster, as it uses a direct connection between the remote hosts. You have to enable
Host example.com
AgentForward yes
in the ~/.shh/config file of the machine that is running the script though. Of course this is only a solution if the remote machines are both within your trusted network.
One reason scp can fail, even when ssh works, is that the port number needs to be specified before the host. I don't know why. But this is wrong:
scp pi@localhost:/home/pi/paula-bean -P 3022 /mnt/home/
instead, it should be
scp -P 3022 pi@localhost:/home/pi/paula-bean /mnt/home/
The SCP uses the -P (capital p) option to specify the port, while SSH uses lower case -p.
Upd: I seldom use SSH with a non-standard port, and apparently, I never used SCP with a non-standard port. It took me a few minutes of agony to figure out that SCP was not working because it wanted the capital 'P'.
I suspect I am not the only one who hit this issue.
