scp broken, root now copies to /dev/null on Sid and Mint XFCE 15
Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
scp broken, root now copies to /dev/null on Sid and Mint XFCE 15
BTW, I am not a Linux newbie (Linux Counter number 2419) but this is my first post on this site, so this seems to be the place I am expected to post it.
I use Debian Sid and Linux Mint XFCE. Several months ago I noticed scp transfers as root stopped always working. They sometimes appear to transfer with expected transfer statistics reported using -v, but the files and directories do not actually get incorporated into the receiving host's filesys. Between Sid, Mint XFCE 14, and Mint XFCE 15 (RC), it only works when the scp is invoked from Mint XFCE 14, regardless of transfer direction. I am finally attempting to get to the bottom of this, expecting to find a new config item or a changed default value somewhere, but so far it's not obvious. I guess it's worth a question here before I start using diff on the config files.
What is the exact command that is not doing what you expect?
Thanks for your inquiry.
scp -vp mint14:file14 .fails on mint15 as root in /root scp -vp file14 mint15:works on mint14 as root in /root
Both report appropriate transfer stats, but only the second causes file14 to appear in root's home directory on mint15. Remote host passwords are solicited by both commands.
Does it work if you use full pathnames and hostnames instead of abbreviating?
Like: mint14.example.com instead of mint14, and /root/file14 instead of file14.
To be pedantic, I should also say to use /usr/bin/scp instead of scp.
All of those are depending on other programs to resolve the full names some of which are likely not configured correctly.
Does it work if you use full pathnames and hostnames instead of abbreviating?
None of those changes make any difference, including using dotted-decimal addresses instead of DNS addresses. I am appending two sanitized session logs to provide full details of this issue. The mint14 session successfully transfered xyzzy15 from mint15 as xyzzyDDIPV4. The mint15 session then tried to transfer xyzzyDDIPV4 back from mint14 to mint15.
I was about to suggest running lsof on the target system during transfer to see where the data ends up, but then I noticed this from the successful session:
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LC_COLLATE = C
debug1: Sending env LANG = en_US.UTF-8
debug1: Sending command: scp -v -p -f /root/xyzzyDDIPV4
setterm: $TERM is not defined.
Sink: Sourcing /com/.bash_root...
Sourcing /com/.bash_root...
It looks like the remote scp session never actually runs. You should be able to confirm that by attempting to copy a large file; the session should "complete" almost immediately.
This could be a configuration issue or even a profile issue, but I'd check and compare the sshd/scp versions on all systems just to rule out bugs.
It looks like the remote scp session never actually runs. You should be able to confirm that by attempting to copy a large file; the session should "complete" almost immediately.
This could be a configuration issue or even a profile issue, but I'd check and compare the sshd/scp versions on all systems just to rule out bugs.
They do report themselves to be the same version as I'd expect since I keep mint14 current and 15rc should be the current release within 24 hours. I decided to simply rename .profile to .profile.disable and .bashrc to .bashrc.disable and try another scp. Then I thought to list the remote directory first. The result is puzzling [figured it out--the globbing happens in the local directory before the scp executable is invoked]:
root@mint15[PN]~ # ssh mint14.home /bin/ls -FaCd .* root@mint14.home's password:
/bin/ls: cannot access .bashrc: No such file or directory
/bin/ls: cannot access .config: No such file or directory
/bin/ls: cannot access .profile: No such file or directory
./ ../ .aptitude/ .bash_history .cache/ .dbus/ .ssh/ .synaptic/ root@mint15[PN]~ #
So I popped over to mint14:
root@mint15[PN]~ # ssh root@mint14.home root@mint14.home's password:
Welcome to Linux Mint 14 Nadia (GNU/Linux 3.5.0-23-generic x86_64)
Welcome to Linux Mint
* Documentation: http://www.linuxmint.com
Last login: Fri Mar 15 09:37:38 2013 mint14 ~ # /bin/ls -FaCd .* 2>&1 | tee ls.log
./ .bash_history .dbus/ .profile.disable .ssh/
../ .bashrc.disable .gconf/ .pulse/ .synaptic/
.aptitude/ .cache/ .mateconf/ .pulse-cookie .viminfo mint14 ~ # /bin/ls -l ls.log
-rw-r--r-- 1 root root 175 Jul 12 18:25 ls.log mint14 ~ #
Then returned to mint15 for the actual test:
root@mint15[PN]~ # /usr/bin/scp -pv mint14.home:/root/ls.log /root/ls.log
Executing: program /usr/bin/ssh host mint14.home, user (unspecified), command scp -v -p -f /root/ls.log
OpenSSH_6.1p1 Debian-4, OpenSSL 1.0.1c 10 May 2012
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to mint14.home [10.11.12.18] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/id_rsa type -1
debug1: identity file /root/.ssh/id_rsa-cert type -1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: identity file /root/.ssh/id_dsa-cert type -1
debug1: identity file /root/.ssh/id_ecdsa type -1
debug1: identity file /root/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.0p1 Debian-3ubuntu1
debug1: match: OpenSSH_6.0p1 Debian-3ubuntu1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.1p1 Debian-4
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA 14:14:14:14:14:14:14:14:14:14:14:14:14:14:14:14
debug1: Host 'mint14.home' is known and matches the ECDSA host key.
debug1: Found key in /root/.ssh/known_hosts:1
debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /root/.ssh/id_rsa
debug1: Trying private key: /root/.ssh/id_dsa
debug1: Trying private key: /root/.ssh/id_ecdsa
debug1: Next authentication method: password root@mint14.home's password:
debug1: Authentication succeeded (password).
Authenticated to mint14.home ([10.11.12.18]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LC_COLLATE = C
debug1: Sending env LANG = en_US.UTF-8
debug1: Sending command: scp -v -p -f /root/ls.log
File mtime 1373667935 atime 1373668489
Sending file timestamps: T1373667935 0 1373668489 0
Sink: T1373667935 0 1373668489 0
Sending file modes: C0644 175 ls.log
Sink: C0644 175 ls.log
ls.log 100% 175 0.2KB/s 00:00
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: client_input_channel_req: channel 0 rtype eow@openssh.com reply 0
debug1: channel 0: free: client-session, nchannels 1
debug1: fd 0 clearing O_NONBLOCK
debug1: fd 1 clearing O_NONBLOCK
Transferred: sent 1952, received 2096 bytes, in 0.1 seconds
Bytes per second: sent 25854.6, received 27761.9
debug1: Exit status 0 root@mint15[PN]~ # /bin/ls -l ls.log
-rw-r--r-- 1 root root 175 Jul 12 18:25 ls.log root@dlc-pl[PN]~ #
So mint15 actually performed the transfer! But what has changed in Debian Sid and Mint XFCE 15 that causes those local profile commands to break the transferring since they (still) cause no problem for the Mint XFCE 14 scp command environment? I need to experiment further with .profile and .bashrc invocation enviromental differences. The bash versions are slightly different:
mint14: GNU bash, version 4.2.37(1)-release (x86_64-pc-linux-gnu)
mint15: GNU bash, version 4.2.45(1)-release (x86_64-pc-linux-gnu)
I really appreciate this assistance--my brain has not been at 100% efficiency the last few days.
So mint15 actually performed the transfer! But what has changed in Debian Sid and Mint XFCE 15 that causes those local profile commands to break the transferring since they (still) cause no problem for the Mint XFCE 14 scp command environment? I need to experiment further with .profile and .bashrc invocation enviromental differences.
I found out ssh causes .profile to be invoked but scp invokes .bashrc. But it took a bit of testing insertng tracing echo commands and set -xv commands until I finally hit upon the apparent restriction of the newer scp/bash that it won't tolerate many terminal stdout characters during the .bashrc processing before it decides to quietly shut it down. Once I redirected all echo command stdouts to a file, the new scp/bash is accomodating of the requests.
So, bug or feature? And thanks again for all assistance.
[However, further testing shows problems occur with non-root users transfering in/out of the implicit (remote scp's working) directory, as though it is not being set to the user's home directory. [Issue resolved: the non-root user's local .bashrc processing was resetting the working directory, so the old scp/bash was clearly not processing .bashrc]]
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
