Unlike ssh, scp uses the uppercase P switch to set the port instead of the lowercase p:
scp -P 80 ... # Use port 80 to bypass the firewall, instead of the scp default
The lowercase p switch is used with scp for the preservation of times and modes.
Here is an excerpt from scp's man page with all of the details concerning the two switches, as well as an explanation of why uppercase P was chosen for scp:
-P port Specifies the port to connect to on the remote host. Note that this option is written with a capital 'P', because -p is already
reserved for preserving the times and modes of the file in rcp(1).
-p Preserves modification times, access times, and modes from the original file.
Bonus Tip: How can I determine the port being used by the/an SSH daemon to accept SSH connections?
This question can be answered by using the netstat
utility, as follows:
sudo netstat -tnlp | grep sshd
Or, using the far more readable word based netstat option names:
sudo netstat --tcp --numeric-ports --listening --program | grep sshd
The output you will see, assuming your ssh daemon is configured with default values its listening ports, is shown below (with a little trimming of the whitespace in between columns, in order to get the entire table to be visible without having to scroll):
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State ID/Program name
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 888/sshd: /usr/sbin
tcp6 0 0 :::22 :::* LISTEN 888/sshd: /usr/sbin
Important Note
For the above examples, sudo
was used to run netstat with administrator privs, in order to be able to see all of the Program Names. If you run netstat as a regular user (i.e., without sudo and assuming you don't have admin rights granted to you, via some other method), you will only see program names shown for sockets that have your UID as the owner. The Program Names for sockets belonging to other users will not be shown (i.e., will be hidden and a placeholder hyphen will be displayed, instead):
Proto Recv-Q Send-Q Local Address Foreign Address State ID/Program name
tcp 0 0 127.0.0.1:46371 0.0.0.0:* LISTEN 4489/code
...
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN -
tcp 0 0 127.0.0.53:53 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN -
...
Update and aside to address one of the (heavily upvoted) comments:
With regard to Abdull's comment about scp
option order, what he suggests:
scp -r some_directory -P 80 ...
..., intersperses options and parameters, since the -r
switch takes no additional arguments and some_directory
is treated as the first parameter to the command, making -P
and all subsequent command line arguments look like additional parameters to the command (i.e., hyphen prefixed arguments are no longer considered as switches).
getopt(1)
clearly defines that parameters must come after options (i.e., switches) and not be interspersed with them, willy-nilly:
The parameters getopt is called with can be divided into two parts: options which modify the way getopt will do the parsing (the options and the optstring in the SYNOPSIS), and the parameters which are to be parsed (parameters in the SYNOPSIS). The second part will start at
the first non-option parameter that is not an option argument, or after the first occurrence of '--'. If no '-o' or '--options' option is found in the first part, the first parameter of the second part is used as the short options string.
Since the -r
command line option takes no further arguments, some_directory
is "the first non-option parameter that is not an option argument." Therefore, as clearly spelled out in the getopt(1)
man page, all succeeding command line arguments that follow it (i.e., -P 80 ...
) are assumed to be non-options (and non-option arguments).
So, in effect, this is how getopt(1)
sees the example presented with the end of the options and the beginning of the parameters demarcated by gray text:
scp -r some_directory -P 80 ...
This has nothing to do with scp
behavior and everything to do with how POSIX standard applications parse command line options using the getopt(3)
set of C functions.
For more details with regard to command line ordering and processing, please read the getopt(1)
manpage using:
man 1 getopt