☰

エラーなしでSCPが失敗する

tag-icon • tag-icon scp
エラーなしでSCPが失敗する

私はしばらくSCPで非常に奇妙な動作を経験しました。ファイルをコピーしようとするたびに、SCP の出力にアンダースコアが多く含まれるため、ファイルはコピーされません。

$ scp test.txt 192.168.0.2:~
[email protected]'s password: 
 ________________________________________

Midnight Commanderを使用してSSH接続を作成し、ファイルをコピーすると機能します。

私のコンピュータに関するいくつかの情報：

$ ssh -V
OpenSSH_5.8p1 Debian-1ubuntu3, OpenSSL 0.9.8o 01 Jun 2010

$ uname -a
Linux squatpc 2.6.38-10-generic #46-Ubuntu SMP Tue Jun 28 15:05:41 UTC 2011 i686 i686 i386 GNU/Linux

私はKubuntu 11.04を実行しています。

編集する：コメントで要求された追加情報：

$ scp -v test.txt 192.168.0.2:~
Executing: program /usr/bin/ssh host 192.168.0.2, user (unspecified), command scp -v -t -- ~
OpenSSH_5.8p1 Debian-1ubuntu3, OpenSSL 0.9.8o 01 Jun 2010
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to 192.168.0.2 [192.168.0.2] port 22.
debug1: Connection established.
debug1: identity file /home/job/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: identity file /home/job/.ssh/id_rsa-cert type -1
debug1: identity file /home/job/.ssh/id_dsa type -1
debug1: identity file /home/job/.ssh/id_dsa-cert type -1
debug1: identity file /home/job/.ssh/id_ecdsa type -1
debug1: identity file /home/job/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.8p1 Debian-1ubuntu3
debug1: match: OpenSSH_5.8p1 Debian-1ubuntu3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.8p1 Debian-1ubuntu3
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 28:f3:2b:31:36:43:9b:07:d8:33:ca:43:4f:ca:6c:4c
debug1: Host '192.168.0.2' is known and matches the ECDSA host key.
debug1: Found key in /home/job/.ssh/known_hosts:20
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: Offering RSA public key: /home/job/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/job/.ssh/id_dsa
debug1: Trying private key: /home/job/.ssh/id_ecdsa
debug1: Next authentication method: password
[email protected]'s password: 
debug1: Authentication succeeded (password).
Authenticated to 192.168.0.2 ([192.168.0.2]:22).
debug1: channel 0: new [client-session]
debug1: Requesting [email protected]
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
debug1: Sending command: scp -v -t -- ~
 ________________________________________
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: channel 0: free: client-session, nchannels 1
debug1: fd 0 clearing O_NONBLOCK
debug1: fd 1 clearing O_NONBLOCK
Transferred: sent 2120, received 1872 bytes, in 0.3 seconds
Bytes per second: sent 7783.1, received 6872.6
debug1: Exit status 0

そして

$ type scp
scp is hashed (/usr/bin/scp)

答え1

まぁㅎㅎ問題が何なのか今は分かりました。

私は牛がとても好きなので、ファイルfortune | cowsayの一番上に置きました.bashrc。起動すると、次の出力が生成されますbash。

 _______________________________________
< You will lose an important disk file. >
 ---------------------------------------
        \   ^__^
         \  (oo)\_______
            (__)\       )\/\
                ||----w |
                ||     ||

bashインタラクティブに実行しても大丈夫です（時には面白いこともあります）。ただし、~/.bashrcbashがログインシェルではなく対話型の場合は、次のように読みます。またはログインシェルで、親プロセスrshdがsshd。を実行すると、scpサーバーはリモートscpインスタンスを起動するシェルを起動します。の出力はプロトコルデータが送信されるのと同じ方法で送信されるため、.bashrc混乱します。これは明らかに知られているバグです。scpscpここ詳細については。

また、質問で言及した下線は、テキストバルーンの一番上の行の下線です。

.bashrcしたがって、解決策は簡単です。リモート（ターゲット）システムの上部に以下を配置します。

# If not running interactively, don't do anything
[[ $- == *i* ]] || return

この行はデフォルト値に存在します.bashrcが、私が何度も（明らかに不注意に）編集したために保留されました。

答え2

AFAIK、ブロック解除を有効にする正しい方法scpは、スクリプトのstdout条件ではなく、~/.bashrc単に画面出力をスクリプトに制限することです~/.bash_profile。少なくとも私のディストリビューション（CentOS）ではそうです。

明確にするために編集された：

  1. 「すべての」リモート接続に必要な行だけを〜/ .bashrcファイルに入れます。 （つまり、特定のENV変数を設定するのは問題ありませんが、人間が読めるテキストをエコーすることはできません。）
  2. 青少年MMV

答え3

.bashrcこの問題は、ファイルがいくつかの出力を生成するか、時々MOTD(Message Of The Day)。この-oオプションを次のように組み合わせることができますscp。

SSHにオプションを渡すことができます-o。この場合、このようなオプションを指定すると、端末のRequestTTY=no出力は要求されません。

scp -oリクエストTTY =いいえ源泉 ターゲット

答え4

scpにこのバグがあるかどうかはわかりません。私がこのバグを使ったのはずっと前でした。 scpをrsyncに置き換えましたが、はるかにうまく機能します。 RsyncはほぼすべてのLinuxデバイスに存在する必要があります。

私はrsyncについてここに書いて、ここにscpについて書いた。 scp経由で多数の小さなファイルをコピーする最良の方法は何ですか？

JohnUの投稿では、Rsyncについて説明します。

関連情報