Change the default SCP command flags in Linux

Question

I am trying to move a file from a virtual machine (Ubuntu 18.04) on my local system to a remote server using a very basic scp command. This issue is present only on one particular server, others work fine so it is not a generic thing.

scp <file name> <user>@<complete_hostname>:~/

But this command does not proceed beyond authentication which is successful.

Same happens when I use FileZilla.

The IT team advised me to use 'WinSCP' which works fine.

scp debug log

debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Trying private key: /home/username/.ssh/id_dsa
debug1: Trying private key: /home/username/.ssh/id_ecdsa
debug1: Next authentication method: password
'user'@'full hostname's password: 
debug1: Authentication succeeded (password).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = C
debug1: Sending env LC_ALL = C
debug1: Sending command: scp -v -t ~/

There is no progress after this, FileZilla times out after 20 seconds in similar fashion. while WinSCP works fine.

What can cause scp to hang, as I am using this in some of my scripts, this issue with one particular server has made my scripts unusable on them, this applies to SFTP methods also.

The IT Team advised me to not use the flags -d and -t while issuing the command as the same shows up on the debug log and is not supported by the remote server. Can these be removed? I did not explicitly issue them with the command.

Edit 2:

SCP Log: (from local machine, Ubuntu 18.04)
==========
debug1: Next authentication method: publickey
debug1: Offering public key: 
RSA SHA256:<key> /home/username/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 279 
debug1: Authentication succeeded (publickey).
Authenticated to 'HOSTNAME' ([10.6.26.145]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: pledge: network
debug1: Sending environment.
debug1: Sending env LANG = en_IN
debug1: Sending command: scp -v -r -d -t ~/received/

Please also add the error log from the server. The configuration of the sshd could also be helpful. — Gerald Schneider, Aug 06 '18 at 06:53
Why are you asking about some "flags"? Why do you assume "flags" have anything to do with your problem? Do you see different "flags" on the other machines? Also note that FileZilla does not support SCP protocol, so your question is not really about SCP. — Martin Prikryl, Aug 06 '18 at 07:23
@MartinPrikryl forgot to add that part to the question, I have added it now. — ArunMKumar, Aug 06 '18 at 08:34
To get the logs as asked by Gerald, it can be advisable tu run sshd in debug mode https://duckduckgo.com/?q=sshd+debug . The configuration file for sshd is usually sshd_config, often in /etc/. — bgtvfr, Aug 06 '18 at 09:12

Martin Prikryl · Answer 1 · 2018-08-06T13:49:13.087

1

The IT Team advised me to not use the flags -d and -t while issuing the command as the same shows up on the debug log and is not supported by the remote server. Can these be removed? I did not explicitly issue them with the command.

-t - That's a total nonsense. SCP protocol cannot work without the -t flag. See How is SCP (secure copy protocol) file transfer working?

-d - It's used, when you specify more than one source. It indicates to the server that the "target should be directory".

In both cases I doubt that the server does not support any of them. As it's Ubuntu, it's running OpenSSH with 99.9% certainty. And OpenSSH supports those flags ever since it exists. See scp.c from 1999.

I'm pretty sure that the advice you got is just a nonsense. The "IT team" probably just didn't found those switches in scp man page and got an easy way out of really helping you. But those flags are internal flags used for communicating between scp as a "client" and scp as a "server". They are not documented by purpose.

Also FileZilla does not even support SCP protocol. What only contributes to the above - Your problem has nothing to do with any "scp flags".

edited Aug 06 '18 at 13:49

answered Aug 06 '18 at 08:47

Martin Prikryl

7,327
2
36
71

The '-d' flag gets added depending upon the machine I try the scp command from, my local machine running ubuntu 18.04 adds a '-d' flag while another remote running RHEL6 does not. – ArunMKumar Aug 06 '18 at 09:58
See my updated answer. – Martin Prikryl Aug 06 '18 at 12:09
well, I contacted the 'IT Team' :P when I lost all options. Don't have many hopes from them anyway. any suggestions to find the cause myself. I do not have any form of elevated access on the remote. – ArunMKumar Aug 06 '18 at 16:13
Ask a new question about your real problem (hang/timeout), instead of asking about a purported solution (the flags). – Martin Prikryl Aug 06 '18 at 16:15
That was exactly my question, they asked for the logs and diverted the answer to 'non-supported flags'. – ArunMKumar Aug 06 '18 at 16:18
I mean, ask a new question here on Server Fault. – Martin Prikryl Aug 07 '18 at 05:23

score -1 · Accepted Answer · answered Aug 09 '18 at 03:01

This turns out to be a firewall blocking the transfer. Reason being the file permission on my default shell's .*rc file. .cshrc in this case.

My default shell is csh, and the File permission were

-rwxr-s---

Changing these to

-rw-r-----

solved the issue.

Thanks all for the help.

Change the default SCP command flags in Linux

2 Answers2