scp: cannot see file in local directory after seemingly successful copy
by Shaggy1 from LinuxQuestions.org on (#5AD7X)
Client side environment:
$ cat /etc/centos-release
CentOS Linux release 7.8.2003 (Core)
$ uname -a
Linux localhost.localdomain 3.10.0-1127.el7.x86_64 #1 SMP Tue Mar 31 23:36:51 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
$ ssh -V
OpenSSH_7.4p1, OpenSSL 1.0.2k-fips 26 Jan 2017
Serverside environment:
$ cat fedrelver.txt
Fedora release 23 (Twenty Three)
Linux larry-aceraspire 4.8.13-100.fc23.x86_64 #1 SMP Fri Dec 9 14:51:40 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
OpenSSH_7.2p2, OpenSSL 1.0.2j-fips 26 Sep 2016
Hi
I am having an issue with scp seeming to successfully copy a file from the server, but the file not appearing in the directroy when I do it.
The command I am executing is :
$ scp -vvv -P 2305 larry@192.168.88.250:/home/larry/wirelesscmds.txt .
or this
$ scp -vvv -P 2305 larry@192.168.88.250:/home/larry/wirelesscmds.txt wirelesscmds.txt
But though everything seems to go through fine I do not see wirelesscmds.txt in the local directory once the command has completed.
I can successfully ssh on to the server, so ssh works fine (using keys)
I can even run the following command to successfully get a copy of it:
$ ssh -T -p 2305 larry@192.168.88.250 'scp -v -f /home/larry/wirelesscmds.txt < /dev/zero' > tst.txt
Sending file modes: C0666 1621 wirelesscmds.txt
The logs output on client and server side do not seem to be indicating any errors.
I do see the following output when I run the command (with no verbose flag):
POST /usr/local/bin:/usr/bin
Not sure if that indicates what the problem is ?
Are there any commands that could be in the ssh config files which may be affecting the outcome - for example something directing the output to somewhere else (I canoot see anything obvious in them) ?
I have read somewhere in my searches that suggested the ssh key in authorized_keys could contain something that restrict scp - is that possible ?
Does anyone have any suggestions on how I might go about troubleshooting this further ?
Below I have printed out the client-side output when using single -v option. Can anyone see what the error might be from that ? (debug1: Exit status 1 suggests maybe something went wrong - but I cannot tell what) :
larry@localhost mywritedir]$ scp -v -P 2305 'larry@192.168.88.250:/home/larry/wirelesscmds.txt' .
Executing: program /usr/bin/ssh host 192.168.88.250, user larry, command scp -v -f /home/larry/wirelesscmds.txt
OpenSSH_7.4p1, OpenSSL 1.0.2k-fips 26 Jan 2017
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 58: Applying options for *
debug1: Connecting to 192.168.88.250 [192.168.88.250] port 2305.
debug1: Connection established.
debug1: identity file /home/larry/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /home/larry/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/larry/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/larry/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/larry/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/larry/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/larry/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/larry/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.4
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.2
debug1: match: OpenSSH_7.2 pat OpenSSH* compat 0x04000000
debug1: Authenticating to 192.168.88.250:2305 as 'larry'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256@libssh.org
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: curve25519-sha256@libssh.org need=64 dh_need=64
debug1: kex: curve25519-sha256@libssh.org need=64 dh_need=64
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:E2yU8+XJUDIq6jbga0jumXVg3RhZP8oRPK5Gj+j+iSI
debug1: Host '[192.168.88.250]:2305' is known and matches the ECDSA host key.
debug1: Found key in /home/larry/.ssh/known_hosts:1
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<rsa-sha2-256,rsa-sha2-512>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure. Minor code may provide more information
No Kerberos credentials available (default cache: KEYRING:persistent:1000)
debug1: Unspecified GSS failure. Minor code may provide more information
No Kerberos credentials available (default cache: KEYRING:persistent:1000)
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/larry/.ssh/id_rsa
debug1: Server accepts key: pkalg rsa-sha2-512 blen 279
debug1: Authentication succeeded (publickey).
Authenticated to 192.168.88.250 ([192.168.88.250]:2305).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: pledge: network
debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
debug1: Sending environment.
debug1: Sending env LANG = en_GB.UTF-8
debug1: Sending env LANGUAGE =
debug1: Sending command: scp -v -f /home/larry/wirelesscmds.txt
Sink: POST /usr/local/bin:/usr/bin
POST /usr/local/bin:/usr/bin
[larry@localhost mywritedir]$ debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
Sending file modes: C0666 1621 wirelesscmds.txt
debug1: channel 0: free: client-session, nchannels 1
debug1: fd 0 clearing O_NONBLOCK
debug1: fd 1 clearing O_NONBLOCK
Transferred: sent 3076, received 2556 bytes, in 1.3 seconds
Bytes per second: sent 2316.2, received 1924.7
debug1: Exit status 1
$ cat /etc/centos-release
CentOS Linux release 7.8.2003 (Core)
$ uname -a
Linux localhost.localdomain 3.10.0-1127.el7.x86_64 #1 SMP Tue Mar 31 23:36:51 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
$ ssh -V
OpenSSH_7.4p1, OpenSSL 1.0.2k-fips 26 Jan 2017
Serverside environment:
$ cat fedrelver.txt
Fedora release 23 (Twenty Three)
Linux larry-aceraspire 4.8.13-100.fc23.x86_64 #1 SMP Fri Dec 9 14:51:40 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
OpenSSH_7.2p2, OpenSSL 1.0.2j-fips 26 Sep 2016
Hi
I am having an issue with scp seeming to successfully copy a file from the server, but the file not appearing in the directroy when I do it.
The command I am executing is :
$ scp -vvv -P 2305 larry@192.168.88.250:/home/larry/wirelesscmds.txt .
or this
$ scp -vvv -P 2305 larry@192.168.88.250:/home/larry/wirelesscmds.txt wirelesscmds.txt
But though everything seems to go through fine I do not see wirelesscmds.txt in the local directory once the command has completed.
I can successfully ssh on to the server, so ssh works fine (using keys)
I can even run the following command to successfully get a copy of it:
$ ssh -T -p 2305 larry@192.168.88.250 'scp -v -f /home/larry/wirelesscmds.txt < /dev/zero' > tst.txt
Sending file modes: C0666 1621 wirelesscmds.txt
The logs output on client and server side do not seem to be indicating any errors.
I do see the following output when I run the command (with no verbose flag):
POST /usr/local/bin:/usr/bin
Not sure if that indicates what the problem is ?
Are there any commands that could be in the ssh config files which may be affecting the outcome - for example something directing the output to somewhere else (I canoot see anything obvious in them) ?
I have read somewhere in my searches that suggested the ssh key in authorized_keys could contain something that restrict scp - is that possible ?
Does anyone have any suggestions on how I might go about troubleshooting this further ?
Below I have printed out the client-side output when using single -v option. Can anyone see what the error might be from that ? (debug1: Exit status 1 suggests maybe something went wrong - but I cannot tell what) :
larry@localhost mywritedir]$ scp -v -P 2305 'larry@192.168.88.250:/home/larry/wirelesscmds.txt' .
Executing: program /usr/bin/ssh host 192.168.88.250, user larry, command scp -v -f /home/larry/wirelesscmds.txt
OpenSSH_7.4p1, OpenSSL 1.0.2k-fips 26 Jan 2017
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 58: Applying options for *
debug1: Connecting to 192.168.88.250 [192.168.88.250] port 2305.
debug1: Connection established.
debug1: identity file /home/larry/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /home/larry/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/larry/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/larry/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/larry/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/larry/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/larry/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/larry/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.4
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.2
debug1: match: OpenSSH_7.2 pat OpenSSH* compat 0x04000000
debug1: Authenticating to 192.168.88.250:2305 as 'larry'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256@libssh.org
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: curve25519-sha256@libssh.org need=64 dh_need=64
debug1: kex: curve25519-sha256@libssh.org need=64 dh_need=64
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:E2yU8+XJUDIq6jbga0jumXVg3RhZP8oRPK5Gj+j+iSI
debug1: Host '[192.168.88.250]:2305' is known and matches the ECDSA host key.
debug1: Found key in /home/larry/.ssh/known_hosts:1
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<rsa-sha2-256,rsa-sha2-512>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure. Minor code may provide more information
No Kerberos credentials available (default cache: KEYRING:persistent:1000)
debug1: Unspecified GSS failure. Minor code may provide more information
No Kerberos credentials available (default cache: KEYRING:persistent:1000)
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/larry/.ssh/id_rsa
debug1: Server accepts key: pkalg rsa-sha2-512 blen 279
debug1: Authentication succeeded (publickey).
Authenticated to 192.168.88.250 ([192.168.88.250]:2305).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: pledge: network
debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
debug1: Sending environment.
debug1: Sending env LANG = en_GB.UTF-8
debug1: Sending env LANGUAGE =
debug1: Sending command: scp -v -f /home/larry/wirelesscmds.txt
Sink: POST /usr/local/bin:/usr/bin
POST /usr/local/bin:/usr/bin
[larry@localhost mywritedir]$ debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
Sending file modes: C0666 1621 wirelesscmds.txt
debug1: channel 0: free: client-session, nchannels 1
debug1: fd 0 clearing O_NONBLOCK
debug1: fd 1 clearing O_NONBLOCK
Transferred: sent 3076, received 2556 bytes, in 1.3 seconds
Bytes per second: sent 2316.2, received 1924.7
debug1: Exit status 1