3

I am trying to copy a file (*.crt) from local to remote server. Unfortunately, I don't have rights to open the sshd_config file on remote server. Someone in our team configured an ssh agent for me; I'm not sure where he put this script, but I can connect to this remote server without a problem. Here is the output of the following command: scp -vvv /cygdrive/c/Users/myaccount/Downloads/certs/*.crt user@server:/tmp

>$ scp -vvv /cygdrive/c/Users/myaccount/Downloads/certs/*.crt user@server:/tmp
Executing: program /usr/bin/ssh host server, user user, command scp -v -d -t /tmp
OpenSSH_7.5p1, OpenSSL 1.0.2k  26 Jan 2017
debug2: resolving "server" port 22
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to server [124.67.80.20] port 22.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file /home/myaccount/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/myaccount/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/myaccount/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/myaccount/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/myaccount/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/myaccount/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/myaccount/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/myaccount/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.5
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.4
debug1: match: OpenSSH_7.4 pat OpenSSH* compat 0x04000000
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to server:22 as 'user'
debug3: hostkeys_foreach: reading file "/home/myaccount/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /home/myaccount/.ssh/known_hosts:1
debug3: load_hostkeys: loaded 1 keys from server
debug3: order_hostkeyalgs: prefer hostkeyalgs: [email protected],[email protected],[email protected],ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
debug3: send packet: type 20
debug1: SSH2_MSG_KEXINIT sent
debug3: receive packet: type 20
debug1: SSH2_MSG_KEXINIT received
debug2: local client KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256,[email protected],ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1,ext-info-c
debug2: host key algorithms: [email protected],[email protected],[email protected],ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,[email protected],[email protected],ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa
debug2: ciphers ctos: [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected],aes128-cbc,aes192-cbc,aes256-cbc
debug2: ciphers stoc: [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected],aes128-cbc,aes192-cbc,aes256-cbc
debug2: MACs ctos: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: [email protected],[email protected],[email protected],hmac-sha2-512-et[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,[email protected],zlib
debug2: compression stoc: none,[email protected],zlib
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug2: peer server KEXINIT proposal
debug2: KEX algorithms: [email protected],diffie-hellman-group-exchange-sha256,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521
debug2: host key algorithms: ssh-rsa,rsa-sha2-512,rsa-sha2-256,ecdsa-sha2-nistp256
debug2: ciphers ctos: aes128-ctr,aes192-ctr,aes256-ctr
debug2: ciphers stoc: aes128-ctr,aes192-ctr,aes256-ctr
debug2: MACs ctos: hmac-sha2-256,hmac-sha2-512
debug2: MACs stoc: hmac-sha2-256,hmac-sha2-512
debug2: compression ctos: none,[email protected]
debug2: compression stoc: none,[email protected]
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug1: kex: algorithm: [email protected]
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: aes128-ctr MAC: hmac-sha2-256 compression: none
debug1: kex: client->server cipher: aes128-ctr MAC: hmac-sha2-256 compression: none
debug3: send packet: type 30
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug3: receive packet: type 31
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:l19LX/CQNR9zxuvQpVrQn764H6u6wVxoprYFe6Z+Pf0
debug3: hostkeys_foreach: reading file "/home/myaccount/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /home/myaccount/.ssh/known_hosts:1
debug3: load_hostkeys: loaded 1 keys from server
debug3: hostkeys_foreach: reading file "/home/myaccount/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /home/myaccount/.ssh/known_hosts:1
debug3: load_hostkeys: loaded 1 keys from 172.27.40.30
debug1: Host 'server' is known and matches the ECDSA host key.
debug1: Found key in /home/myaccount/.ssh/known_hosts:1
debug3: send packet: type 21
debug2: set_newkeys: mode 1
debug1: rekey after 4294967296 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug3: receive packet: type 21
debug1: SSH2_MSG_NEWKEYS received
debug2: set_newkeys: mode 0
debug1: rekey after 4294967296 blocks
debug2: key: /home/myaccount/.ssh/id_rsa (0x600072020), agent
debug2: key: /home/myaccount/.ssh/id_rsa (0x0)
debug2: key: /home/myaccount/.ssh/id_dsa (0x0)
debug2: key: /home/myaccount/.ssh/id_ecdsa (0x0)
debug2: key: /home/myaccount/.ssh/id_ed25519 (0x0)
debug3: send packet: type 5
debug3: receive packet: type 7
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<rsa-sha2-256,rsa-sha2-512>
debug3: receive packet: type 6
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug3: send packet: type 50
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey
debug3: start over, passed a different list publickey
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/myaccount/.ssh/id_rsa
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 60
debug1: Server accepts key: pkalg rsa-sha2-512 blen 279
debug2: input_userauth_pk_ok: fp SHA256:0Ye9/EO8URVsdDLmSgDFlACsxRCJVSTtTmwNYr8SpZE
debug3: sign_and_send_pubkey: RSA SHA256:0Ye9/EO8URVsdDLmSgDFlACsxRCJVSTtTmwNYr8SpZE
debug3: send packet: type 50
debug3: receive packet: type 52
debug1: Authentication succeeded (publickey).
Authenticated to server([124.67.80.20]:22).
debug2: fd 5 setting O_NONBLOCK
debug2: fd 6 setting O_NONBLOCK
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug3: send packet: type 90
debug1: Requesting [email protected]
debug3: send packet: type 80
debug1: Entering interactive session.
debug1: pledge: network
debug3: receive packet: type 80
debug1: client_input_global_request: rtype [email protected] want_reply 0
debug3: receive packet: type 91
debug2: callback start
debug2: fd 3 setting TCP_NODELAY
debug3: ssh_packet_set_tos: set IP_TOS 0x08
debug2: client_session2_setup: id 0
debug1: Sending command: scp -v -d -t /tmp
debug2: channel 0: request exec confirm 1
debug3: send packet: type 98
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel 0: rcvd adjust 2097152
debug3: receive packet: type 99
debug2: channel_input_status_confirm: type 99 id 0
debug2: exec request accepted on channel 0
debug3: send packet: type 1
debug1: channel 0: free: client-session, nchannels 1
debug3: channel 0: status: The following connections are open:

^here everything hangs and after few minutes, I click Ctrl+C then comes this:

  #0 client-session (t4 r0 i0/0 o0/0 fd 5/6 cc -1)

debug3: fd 0 is not O_NONBLOCK
debug3: fd 1 is not O_NONBLOCK
Killed by signal 2.

Where can the problem lie?

@roaima Here is result of ls -ld:

╔═myaccount ▷ w00d76:[~]:
╚> ls -ld /cygdrive/c/Users/myaccount /Downloads/certs/*.crt
-rwx------+ 1 myaccount Domain Users 5037 17. Apr 12:40 /cygdrive/c/Users/myaccount/Downloads/certs/dm.cogist.com_server.crt
-rwx------+ 1 myaccount Domain Users 5033 17. Apr 12:37 /cygdrive/c/Users/myaccount/Downloads/certs/dm1.cogist.ch_server.crt
-rwx------+ 1 myaccount Domain Users 5037 17. Apr 12:41 /cygdrive/c/Users/myaccount/Downloads/certs/dm2.cogist.ch_server.crt
-rwx------+ 1 myaccount Domain Users 5041 17. Apr 12:38 /cygdrive/c/Users/myaccount/Downloads/certs/dm1.cogist.com_server.crt
-rwx------+ 1 myaccount Domain Users 5053 17. Apr 12:35 /cygdrive/c/Users/myaccount/Downloads/certs/dm3.cogist.ch_server.crt
-rwx------+ 1 myaccount Domain Users 5069 17. Apr 12:36 /cygdrive/c/Users/myaccount/Downloads/certs/dm3.cogist.com_server.crt
-rwx------+ 1 myaccount Domain Users 5025 17. Apr 12:30 /cygdrive/c/Users/myaccount/Downloads/certs/dm4.cogist.ch_server.crt
-rwx------+ 1 myaccount Domain Users 5025 17. Apr 12:35 /cygdrive/c/Users/myaccount/Downloads/certs/dm5.cogist.ch_server.crt
-rwx------+ 1 myaccount Domain Users 5021 17. Apr 12:33 /cygdrive/c/Users/myaccount/Downloads/certs/dm6.cogist.ch_server.crt
-rwx------+ 1 myaccount Domain Users 5029 17. Apr 12:39 /cygdrive/c/Users/myaccount/Downloads/certs/dm7.cogist.ch_server.crt
-rwx------+ 1 myaccount Domain Users 5025 17. Apr 12:40 /cygdrive/c/Users/myaccount/Downloads/certs/dm8.cogist.ch_server.crt
-rwx------+ 1 myaccount Domain Users 5029 17. Apr 12:32 /cygdrive/c/Users/myaccount/Downloads/certs/dm9.cogist.ch_server.crt

@roaima I'm logged in using ssh myaccount@server and here was no question.

╔═myaccount ▷ w00d76:[~]:
╚> ssh myaccount@server
Last login: Wed Apr 18 11:38:30 2018 from w00d76.net.ch

      server.net.ch

      Inventory number: 25422250
      OS responsible:   IT245
      APPL responsible: IT245
      APPL description: Gateway Server
      Server function:  Produktion

      Red Hat Enterprise Linux Server release 7.4 (Maipo) (x86_64)

      IT2 Operations [email protected]

      "akunamatata -> no worries mate .."


╔═myaccount ▷ server:[~]:
╚>
6
  • Do you have an anti-virus on your or the remote system? Apr 18, 2018 at 9:20
  • Is this from Cygwin or from the Windows bash? I've had issues with scp from Windows' bash, but sftp seems to work reliably.
    – Kusalananda
    Apr 18, 2018 at 9:43
  • I'm not sure about the antivirus, but there is a firewall. Other staff can do scp but on my PC something wrong. We all have actually same rights. @Kusalananda it's from Cygwin
    – khashashin
    Apr 18, 2018 at 9:46
  • Are you scp’ing something like a socket or pipe?
    – Jeff Schaller
    Apr 18, 2018 at 10:23
  • not sure what do you mean? I'm scp'ing a file from local to remote, What does mean scp'ing socket or pipe?
    – khashashin
    Apr 18, 2018 at 10:32

2 Answers 2

6
debug1: Sending command: scp -v -d -t /tmp
[...]
debug2: exec request accepted on channel 0

SCP works by opening an SSH connection to the remote server, then invoking another copy of the scp program there. The two scp instances communicate with each other through the SSH link.

According to the log, your scp client successfully connected to the server, authenticated, and requested for the remote server to invoke scp to receive the files. However, it appears that the remote scp instance didn't actually start up correctly. One of these reasons seem to be likely:

  1. You have something in your .bashrc, .profile, or similar file on the remote system which prevented scp from starting. The remote server invokes requested commands using your login shell by running the equivalent of $SHELL -c 'the-requested-command'. Some things which you can put in your shell configuration files will prevent the shell from running the command. For example, if your .bashrc exec'ed a different shell, that would prevent scp from working.

  2. Since you authenticated using an SSH key, your probably have an entry for the SSH key in the remote system's .ssh/authorized_keys file. There's a directive named ForceCommand that can be placed in the authorized_keys file. If the key is subject to a forced command, then any request by the client to run a program will invoke the forced command, instead of the command requested by the client.

  3. The scp program on the remote system may be malfunctioning. Or perhaps someone has replaced it with a different program.

3
  • Thanks for explaining. It seems like right answer. I'll give you feedback tomorrow.
    – khashashin
    Apr 18, 2018 at 19:20
  • Thansk. it was really because of my .bashrc file
    – khashashin
    Apr 19, 2018 at 12:46
  • 1
    I had to silence commands in .bashrc by appending 2>&1>/dev/null to them.
    – dr0i
    Feb 4, 2020 at 10:31
3

It looks like your remote server is configured to ask a question when you log in. (You can check this with ssh user@server and see whether you get asked a question.) That code needs to be modified to ask its question only when running in an interactive shell.

For example, if you're using bash then in .bashrc:

read -p "What terminal type: " termtype
# ... other code that uses $termtype ...

you should consider something like this instead:

if [[ -n "$PS1" ]]
then
    read -p "What terminal type: " termtype
    # ... other code that uses $termtype ...
fi

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .