回答:
の代わりに-oオプションを追加できます。scp.ssh/config
scp -o ProxyCommand="ssh $jump_host nc $host 22" $local_path $host:$destination_path
$jump_host この場合の「サーバーB」です。
OpenSSHを想定して、.ssh / configでSSH構成に追加します
Host distant
ProxyCommand ssh near nc distant 22
これにより、SSHはnearという名前のマシンを介してプロキシすることにより、distantという名前のマシンに「直接」接続できるようになります。その後、遠方のマシンに対してscpやsftpなどのアプリケーションを使用できます。
これが機能するためには、「nc」、つまりnetcatがnearというマシンにインストールされている必要があります。しかし、多くの最新のシステムにはすでに搭載されています。
towoのtarソリューションは、tarの構文と操作規則を覚えていると仮定すると、1回限りの問題に対してより効果的です。
nearがユーザー名on と異なる場合distant、近いユーザーはに行きProxyCommand ssh nearuser@near...、遠いユーザーは別のUser distantuser行に入ります。
（B）マシンの近くにあるサーバー上の最新バージョンのsshでは、netcatがなくても以下が機能します。
Host distant
ProxyCommand ssh near -W distant:22
ただし、近くの（B）マシンでAllowTcpForwardingをyes（デフォルト）にする必要があります。
編集：BのOpenSSH 5.4+が必要です
あなたは次のようなものを使用してサーバーBにsshすることができます
ssh -L 5022:<server C IP>:22 <user_serverB>@<server B IP>
その後、次を使用してサーバーCにsshできます
ssh -p 5022 <user_serverC>@localhost
同様にscpは以下を使用して動作します
scp -P 5022 foo.txt <user_serverc>@localhost:
scpとsshでpの大文字と小文字を正しく使用することを忘れないでください
認証に証明書を使用する必要がある場合でも（AWS環境で一般的）可能であり、比較的簡単です。
以下のコマンドは、ファイルをremotePathon からserver2直接あなたのマシンにコピーしますlocalPath。内部的には、scpリクエストはを介してプロキシされserver1ます。
scp -i user2-cert.pem -o ProxyCommand="ssh -i user1-cert.pem -W %h:%p user1@server1" user2@server2:/<remotePath> <localpath>
他の方法も機能します（アップロードファイル）：
scp -i user2-cert.pem -o ProxyCommand="ssh -i user1-cert.pem -W %h:%p user1@server1" <localpath> user2@server2:/<remotePath>
代わりにパスワード認証を使用する場合は、で試してください
scp -o ProxyCommand="ssh -W %h:%p user1@server1" user2@server2:/<remotePath> <localpath>
両方のサーバーで同じユーザー資格情報を使用する場合：
scp -o ProxyCommand="ssh -W %h:%p commonuser@server1" commonuser@server2:/<remotePath> <localpath>
これを逆に行うこともでき、おそらくもっと簡単です。
ファイルの送信先のマシンでsshセッションが開かれていると仮定します。この最遠ホップのPC、これをhop2と呼びます。「プロキシ」ホストはhop1です。ファイルを起源とするPCを、その起源と呼びます。
origin:~/asdf.txt --> hop1 --> hop2:~/asdf.txt
トンネルを構築して、リモートPCでローカルポートを使用可能にすることができます。これにより、リモートPCで開くポートを定義します。これは、トンネルを構築したときに引き渡したポートへのリダイレクトになります。
hop2で：
ssh -R 5555:127.0.0.1:22 <hop1_user>@<hop1_IP>
#this has the effect of building a tunnel from hop2 to hop1, making hop2's port 22 available on hop1 as port 5555
これで開かれたトンネルセッションで、hop1からfile_originまで同じことができます。
hop1で：
ssh -R 6666:127.0.0.1:5555 <origin_user>@<origin_IP>
#this has the effect of building a tunnel from hop1 to origin while also pulling the active tunnel with it, making hop1's port 5555 (hop2's port 22) available on origin as port 6666.
これで、hop2からhop1を起点にトンネルされます。偶然にも、今ではポート5555と6666の両方がオリジンで開いており、hop2のポート22にリダイレクトされています。このセッションでは、次の両方がhop2への有効なscpルートです。
起源：
scp -P 6666 ~/asdf.txt <hop2_user>@<127.0.0.1>:~/asdf.txt
この方法では、間に任意の数のホップを入れることができ、3つ以上のホップを連結するという点で作業が簡単になります。
複数のホストに使用できるセットアップの次のサンプルopenssh構成を採用してみてください。
Host uat-*
ProxyCommand ssh bastion-uat nc %h %p
これは、jumpbox / gatewayサーバー「bastion-uat」を介してのみアクセス可能な「uat-」で始まるサーバーのセットを前提としています。ForwardAgent yesログインにキーを使用している場合は、おそらく追加することもできます。
ForwardAgent yesこれには使用しないでください。要塞ではsshクライアントが実行されないため、この場合、エージェント転送は必要ありません。また、エージェントが不要なときに転送すると、セキュリティが低下するだけです。そして、私sshはあなたの命令に欠けていると思います。ssh必要のない最新バージョンが使用されている場合はnc、ssh -W %h:%p bastion-uat代わりに入力できます。
これは（OPが要求した）scpではありませんがrsync、次のように単一のホップを介してローカルからリモートにコピーするのに使用するのが非常に簡単であることがわかりました。
rsync -v -e 'ssh -A -t user@jumpserver ssh -A -t user@destinationserver' /path/to/sourcefile :/path/to/destination
ソース：http : //mjbright.blogspot.com/2012/09/using-rsync-over-multi-hop-ssh.html
上記の-o ProxyPassの提案を試しましたが、私のニーズの変化に合わせて構成を変更したくありませんでした。上記リンクの作成者が述べているように、コロン（:)の前の宛先ファイルは、指定されたパスが宛先サーバー上にあることを示すために重要です。また、rsyncを使用すると、日付比較、フォルダー同期などのオプションがあります。これが誰かの助けになることを願っています。