scp 不起作用。尋找原因

我正在嘗試將文件 (*.crt) 從本地伺服器複製到遠端伺服器。不幸的是，我無權sshd_config在遠端伺服器上打開文件。我們團隊中有人為我配置了一個 ssh 代理；我不確定他把這個腳本放在哪裡，但我可以毫無問題地連接到這個遠端伺服器。以下是以下命令的輸出：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: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,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,curve25519-sha256@libssh.org,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: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa
debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,aes192-cbc,aes256-cbc
debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,aes192-cbc,aes256-cbc
debug2: MACs ctos: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,zlib@openssh.com,zlib
debug2: compression stoc: none,zlib@openssh.com,zlib
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug2: peer server KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256@libssh.org,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,zlib@openssh.com
debug2: compression stoc: none,zlib@openssh.com
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug1: kex: algorithm: curve25519-sha256@libssh.org
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 no-more-sessions@openssh.com
debug3: send packet: type 80
debug1: Entering interactive session.
debug1: pledge: network
debug3: receive packet: type 80
debug1: client_input_global_request: rtype hostkeys-00@openssh.com 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:

^這裡一切都掛起，幾分鐘後，我點擊 Ctrl+C 然後出現：

 #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.

問題可能出在哪裡？

@roaima 這是以下結果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 我使用 ssh myaccount@server 登錄，這毫無疑問。

╔═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 rspi@ost.ch

     "akunamatata -> no worries mate .."


╔═myaccount ▷ server:[~]:
╚>

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

SCP 通過打開與遠端伺服器的 SSH 連接，然後在那裡呼叫 scp 程序的另一個副本來工作。兩個 scp 實例通過 SSH 連結相互通信。

根據日誌，您的 scp 客戶端成功連接到伺服器，經過身份驗證，並請求遠端伺服器呼叫scp以接收文件。但是，似乎遠端scp實例實際上並未正確啟動。這些原因之一似乎很可能：

1. 您的 .bashrc、.profile 或遠端系統上的類似文件中存在阻止 scp 啟動的內容。遠端伺服器通過執行等效的$SHELL -c 'the-requested-command'. 您可以在 shell 配置文件中添加的一些內容會阻止 shell 執行命令。例如，如果您的 .bashrc 執行了不同的 shell，那將scp無法正常工作。
2. 由於您使用 SSH 密鑰進行身份驗證，因此您可能在遠端系統的.ssh/authorized_keys文件中有一個 SSH 密鑰條目。有一個名為的指令ForceCommand可以放在 authorized_keys 文件中。如果密鑰受制於強制命令，則客戶端執行程序的任何請求都將呼叫強制命令，而不是客戶端請求的命令。
3. 遠端系統上的scp程序可能出現故障。或者也許有人用不同的程序替換了它。

引用自：https://unix.stackexchange.com/questions/438460