scpは安全ではありませんか？ sftpに置き換える必要がありますか？
私はUn * xで20年以上の経験があり、scpを太古の昔から使用しています。 scpはSSH経由なので、後者と同じくらい安全だと思います。さて、私が最近仕事を始めた私の会社では、セキュリティ担当者はscpは安全でなく、時代遅れなので使用しないでくださいと言っています。 sftpはそれよりも優先されます（まだSSHでも...）
Scpの下のインフラストラクチャ、およびプロコミュニティでのscpの人気度と信頼度、および私の元会社の他の同僚の間で、これにすぐには同意しません。一部のCSOが言ったからといって、考えを変えたくありません。
- これは言った、ここに主題がありますか？
scpは突然ブラックシープですか？- より高い領域での単なるセキュリティ専門家の議論ですか？
- または、
scpを使用するだけでよいですか？
わずかに「安全でない」
それはwas OpenSSH 8.0で_scp -T_を追加する前にわずかに「安全」であり、それでも__is _scp -r_を使用するとわずかに「安全ではありません」。
他の回答が述べたように、scpが安全でないという主張は、クライアントが以前に、要求したものを受け取っていることを確認できないことから来ています。 scpが検証できなかったのは、サーバーの環境で（サーバーの状態と共に）実行されているシェルコードを使用して要求が行われたためです。
たとえば、サーバーのシェルが拡張グロブ付きのzshに設定されており、プロジェクトディレクトリをzsh動的名前付きディレクトリに設定して、すばやくアクセスできるとします。 Rails project fooからファイルを取得したい場合は、次のようにして取得できます。
_scp server:~foo/config/database.yml .
_サーバー上のzshは_~foo_を_~/work-for/client/$client_name/foo_に展開します。
サーバーの最新の10個の通常ファイルを取得したい場合は、次のようにします。
_scp server:'*(.oc[1,10])' .
_サーバーにプレーンbashがある場合、次のようにできます。
_scp server:'$(ls -t | head -10)' .
_コンテンツにパターンfooを含むファイルを取得したい場合は、次のようにします。
_scp server:'$(grep -l foo *)' .
_Scpクライアントがシェルコードを使用するこのような種類のリクエストを検証する方法はありません。ただし、悪意のあるサーバーが以下に応答できるようになることは懸念事項です。
_scp -r server:foo/ ~
__.ssh/authorized_keys_を上書きします。 scpの目には、_foo/_は、誰が何を知っているかを評価するサーバーシェルコードです。
_scp -T_を入力：
-T厳密なファイル名チェックを無効にします。デフォルトでは、リモートホストからローカルディレクトリにファイルをコピーするときに、scpは受信したファイル名がコマンドラインで要求されたファイル名と一致することを確認して、リモートエンドが予期しないファイルや不要なファイルを送信しないようにします。さまざまなオペレーティングシステムとシェルがファイル名のワイルドカードを解釈する方法が異なるため、これらのチェックにより、必要なファイルが拒否される場合があります。このオプションは、サーバーが予期しないファイル名を送信しないことを完全に信頼する代わりに、これらのチェックを無効にします。
要約すると、scpの以前のデフォルトの動作は_-T_に移動しました。現在のデフォルトでは、再帰的なコピーを実行していないときに、提供された引数を単純なパターンとして使用して、何が受信されているかを確認します。私はそれが単純なグロブとエスケープを認識すると信じています（ ソースを見て 、それは照合に fnmatch（3） を使用し、フラグは0に設定されています）。つまり、シェルコードでファイルを指定するという独自の機能を利用したくない場合に、より予測どおりに動作します。
したがって、_-T_を使用せず、_-r_を使用しない場合、_.bashrc_などを上書きする唯一の方法は、明示的に要求することです。シェルコードを使用する場合は、サーバーを信頼する代わりに_-T_を使用する必要があります。
_scp -T server:'*(.oc[1,10])' .
_したがって、scpやsftpなどの他のユーティリティよりもrsyncをより便利にする独自の機能を完全に放棄することなく、単純な非再帰的なケースで安全性を確保できます。
Can scpはsftpに置き換えられますか？
sftpはシェルコードで必要なファイルを指定できません。実際のファイルパスのみを受け入れます。その方が制限されます。単純なファイルパスにscpのみが必要な場合は、そうです。ただし、サーバー側のシェルコードを使用した単純なコマンドからファイルを指定できるようにしたい場合は（サーバーを信頼する必要はありますが）、選択肢はscpだけだと思います。
"unsafe"を引用する理由
安全ではありませんでしたが、サーバーが危険にさらされないことを信頼できない場合のみです。私の場合、そしておそらく大多数の人々にとって、私たちはとにかく他の方法で完全に信頼するサーバーでscpを使用します。特に、ラップトップからデスクトップへ、またはその逆へのログインに使用します。自分のデバイスを信頼できない場合、何を信頼できますか？だから私はそれを単なる安全でないと呼ぶのは双曲的だと思います。たとえば、Telnetを安全でないと呼ぶ方法とは異なります。
ただし、_-T_を要求するように変更されたことに感謝します。 isより安全です。また、_-T_によって有効化される機能を必要としない人々にとって、sftpやrsyncよりもscpを使用してもそれほどメリットがないことは確かです。
私がそれを読む方法は、「それは依存する」です。
CVE-2019-6111 によると
ただし、scpクライアントは返されたオブジェクト名の大まかな検証のみを実行します（ディレクトリトラバーサル攻撃のみが防止されます）。悪意のあるscpサーバー（または中間者攻撃）は、scpクライアントのターゲットディレクトリにある任意のファイルを上書きする可能性があります。再帰的な操作（-r）が実行されると、サーバーはサブディレクトリも操作できます（たとえば、.ssh/authorized_keysファイルを上書きするため）。
したがって、scpがオンプレミス（データセンター）のホスト間を移動する場合、MITM攻撃を実行できない可能性が高くなります（確実ではありません）。
ただし、顧客/パートナーから世界中のワイルドなWebを介してビジネスファイルをフェッチする場合は、sftp以上、ftpsを使用する必要があります。 （少なくとも、scpクライアントとsshサーバーのバージョンが適切であることを確認してください）
SSH上のMITMが可能だと考えると、多くのUnixコマンドが安全でなくなると思います。悪意のあるSudoはパスワードを盗む可能性があり、悪意のある通信クライアントはメールやインスタントメッセージを読み取る可能性があります。
侵害されたサーバーと通信するときにscpをsftpに置き換えると、状況がどうにか修正されると言っても、控えめに言っても非常に楽観的です。 scpがローカルファイルに与えるダメージは、バイナリファイル、シェルスクリプト、Pythonファイル、Makefileなど）、および不正なsftp喜んでこれらを提供します。
つまり、SSHで接続するサーバーに注意を払わないと、使用するツールに関係なくねじ込まれる危険性が高く、sftpの代わりにscpを使用すると、 わずかにだけ安全になる。
これはsftpへの切り替えが悪い考えであると言っているのではありません。それが手元のタスクに優れたツールである場合、切り替えることに十分な理由がありますが、これは偶然にもセキュリティに関係しません。
CVE-2019-6111 に応じて作成された新しいOpenSSH changes からscpへの混乱、およびそれらがすべてを作成することの安全性については、多くの混乱があります。
それらの目的は、ファイルのソースとして使用される不正なサーバーが要求された以外のファイル名を送信するのを防ぎ、ローカルマシン上のランダムファイルを上書きすることです。
しかし、それらは-rオプションが使用されている場合には効果がありません。 -rを使用すると、-Tが暗黙的に使用されます。
完全に論理的ですが、多くの人はそれを理解できず、常にscpがファイル名をチェックすることを期待することで、彼らは自己満足の感覚に落ち着きます。彼らが難しい真実に出会うまで、ある日。これによって提供される「セキュリティ」は、alias rm='rm -i'と同じです。
テストのためだけに不正なssh/scpサーバーを設定するのはかなり複雑なため、scpの-S programオプションを使用して（ssh以外のプログラムを使用してチャネルを設定するように指示）、私の主張を確認できます。
ここでは、小さな実行可能スクリプトssh_from_hellを使用しています。これは、何が要求されても、常にlolcats.lolファイルを送信します。
$ chmod 755 ssh_from_hell
$ scp -S ./ssh_from_hell user@Host:foo.txt .
protocol error: filename does not match request
# OK, as expected
$ scp -S ./ssh_from_hell -r user@Host:foo/ .
lolcats.lol 100% 12 62.0KB/s 00:00
$ cat lolcats.lol
LOL LOL LOL
$ cat ssh_from_hell
#! /usr/bin/Perl
use strict;
$|=1; # autoflush
sub readack { local $/=\1; <STDIN> }
sub ack { print "\0" }
my $data = join '', <DATA>;
readack;
printf "C%04o %lld %s\n", 0666, length($data), "lolcats.lol";
readack;
print $data;
ack;
__DATA__
LOL LOL LOL
新しい変更による別の欠点は、リモートファイル名の代わりにリモートファイル名を引用できなくなるという事実です。
scp 'user@Host:"a file with spaces and * love *.txt"' .
あなたは使うべきです
scp 'user@Host:a\ file\ with\ spaces\ and\ \*\ love\ \*.txt' .
ただし、影響力のある一部の開発者は中括弧が大好きなので、中括弧をサポートする アドホックパターンマッチング実装 をscpに追加しました-GLOB_ALTDIRFUNC|GLOB_BRACEでglob(3)を使用した可能性がありますですが、新しいコードを書く方が常に楽しいです。とにかく、fwiw、scpのブレース展開の実装がalmostcshに似ていることに注意してください。 {{foo}}はfooに展開されます：
$ scp -S ./ssh_from_hell 'user@Host:{{lolcats.lol}}' .
lolcats.lol 100% 12 61.6KB/s 00:00
しかし、csh、Perl、およびglob(3)の場合とまったく同じではありません。
$ scp -S ./ssh_from_hell 'user@Host:lolcats{}.lol' .
protocol error: filename does not match request
そしてバギー：
$ scp -S ./ssh_from_hell 'user@Host:lolcats{,}.lol' .
protocol error: filename does not match request
man scp
scpは、ネットワーク上のホスト間でファイルをコピーします。データ転送にssh（1）を使用し、ssh（1）と同じ認証を使用し、同じセキュリティを提供します。 rcp（1）とは異なり、scpは認証に必要な場合にパスワードまたはパスフレーズを要求します。
あなたはscp unsafe？それは、正しくセットアップおよび使用されていない他のものと同様に、可能です。
Man in the Middle（MITM）の脆弱性、最初のポップアップがどこかに初めてsshすることを知っています。無視してOKをクリックするだけです...
サーバーのホストキーはレジストリにキャッシュされません。 サーバーが想定しているコンピューターである保証はありません。サーバーのsshフィンガープリントはblablablaです。
SSH（またはscp）の障害ではありません。プロトコルを適切に使用しないのはあなたの責任です。
接続先のsshサーバーを確立したら、それは（私の意見では）SSHプロトコル2とAES-256暗号を使用の単純な問題です。これがセキュリティの大部分です。 sshd_conf（およびクライアントのssh_config）を調整せず、デフォルトのままにしておけば、それはあなた次第です。
ここにあなたが熟考できるsshd_configの例外があります
Protocol 2
Ciphers aes256-ctr
MACs hmac-sha2-512,hmac-sha2-256
# MACs hmac-sha1
PermitRootLogin no
AuthorizedKeysFile .ssh/authorized_keys {set this up}
IgnoreRhosts yes
IgnoreUserKnownHosts yes
StrictModes yes
UsePAM yes
cVE-2019-6111に準拠
scpクライアントは、返されたオブジェクト名の大まかな検証のみを実行します（ディレクトリトラバーサル攻撃のみが防止されます）。悪意のあるscpサーバー（または中間者攻撃）が、scpクライアントのターゲットディレクトリにある任意のファイルを上書きする可能性があります。再帰的な操作（-r）が実行されると、サーバーはサブディレクトリも操作できます（たとえば、.ssh/authorized_keysファイルを上書きするため）。
それは文脈から外されます。そもそも、悪意のあるsshサーバーに接続しないでください。プロトコルを悪用し、sshサーバーを設定して、scpクライアントのターゲットディレクトリにある任意のファイルを上書きすることについて、SSHを責めないでください。サーバー/クライアントキーを使用してSSHを確立しますそもそも適切に接続され、MITM悪意のあるサーバーはありません。
sshであるscpは安全です。 sshは安全ではないため、scpは安全ではないと言うことは本質的にsshを使用すべきではないと言うことです。
SSH =セキュアシェル
scp = SSH経由の安全なコピー
ftp =ファイル転送プロトコル
sftp = SSH ftp
ftps = TLS/SSL経由のFTP
scpをsftpに置き換えますか？
サーバーのホストキー/フィンガープリントに煩わされず、[ok]をクリックするだけの場合は、sftpでそれが問題ないかどうかを自問してください（サーバーに接続すると、誰であるかは保証されません）。
2点間でSSH通信tunnelが適切に確立されると、セキュアコピーでもファイル転送プロトコルでも、その点での通信のセマンティクスは簡単です。 sshであるscpは安全です。 sshは安全ではないので、scpが安全ではないと言うことは本質的にsshを使用すべきではないと言っていることです。そして、それは真実ではありません。 私が電話であなたに電話をかけ、あなたが私の側で悪いことを起こした場合、それは電話会社の責任ではありません。
「scpプロトコルは古く、柔軟性がなく、簡単に修正できません。代わりに、sftpやrsyncなどの最新のプロトコルを使用してファイルを転送することをお勧めします。」
pleeeasssee .... rsyncはそれ自体では暗号化を実行しないため、接続先が本人だと思う人が誰であるかが保証されないという同じ問題が発生します。しかし、このほのめかしでrsyncはパスを取得しますか？あなたがどこから推薦するのか注意してください。