SCP небезопасен? Стоит ли его заменить на sftp?

Они не правы!

sftp является производным от ssh. Я думаю, что он имел в виду не использовать FTP и использовать sftp.

SCP и sftp по большей части работают поверх SSH, поэтому, если они хотят, чтобы вы не использовали SCP, они не должны хотеть, чтобы вы использовали ни SSH (, ни sftp в этом отношении ). И sftp, и scp обеспечивают безопасную передачу файлов, шифрование паролей и передаваемых данных.

sftp может делать некоторые вещи, которые не может делать scp, но, насколько мне известно, это не связано с безопасностью

Кроме того, SCP работает быстрее, чем sftp, поскольку использует более быстрые алгоритмы.

Ссылки, показывающие, что sftp является производным от ssh.

https://www.linux.com/tutorials/transfer-files-securely-sftp/

https://www.goanywhere.com/blog/are-ssh-and-sftp-the-samehttps://www.technology.pitt.edu/security/secure-shell-ssh-and-sftp

Я прочитал это так: «это зависит».

Согласно CVE -2019 -6111

However, the scp client only performs cursory validation of the object name returned (only directory traversal attacks are prevented). A malicious scp server (or Man-in-The-Middle attacker) can overwrite arbitrary files in the scp client target directory. If recursive operation (-r) is performed, the server can manipulate subdirectories as well (for example, to overwrite the.ssh/authorized_keys file).

Таким образом, если scpпроходит между хостами в вашем помещении (центром обработки данных ), вполне вероятно (, но не точно ), что MITM-атака не может быть выполнена.

Однако, если вы загружаете бизнес-файлы от клиента/партнера через всемирную дикую сеть, вам следует полагаться на sftpили лучше ftps. (По крайней мере, убедитесь, что scpклиент и sshсервер имеют правильные версии)

человек-объект

scp копирует файлы между хостами в сети. Он использует ssh (1 )для передачи данных, использует ту же аутентификацию и обеспечивает ту же безопасность, что и ssh (1 ). В отличие от rcp (1 ), scp будет запрашивать пароли или парольные фразы, если они необходимы для аутентификации.

Вы спросили небезопасен ли SCP ? Это может быть, как и все остальное, не настроенное и не используемое должным образом.

Человек посередине (MITM )уязвимость, вы знаете, что начальное всплывающее окно, которое вы получаете при первом отправке куда-либо по ssh, которое вы игнорируете и просто нажимаете ОК...

the server's host key is not cached in the registry. you have no guarantee that the server is the computer you think it is. The server's ssh fingerprint is blablabla.

Это не вина SSH (или scp ). Это ваше за неправильное использование протокола.

После того, как вы установили, что ssh-сервер, к которому вы подключаетесь, является тем, кем он должен быть, тогда это просто вопрос (, на мой взгляд, )из с использованием протокола SSH 2 и AES -256. шифр . Это основная часть вашей безопасности; если вы не настроите свойsshd_conf(и клиентский ssh ​​_конфиг )и не оставите его по умолчанию, то это на вас.

вот, кроме конфигурации sshd _, над которой можно подумать

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

according to CVE-2019-6111

the scp client only performs cursory validation of the object name returned (only directory traversal attacks are prevented). A malicious scp server (or Man-in-The-Middle attacker) can overwrite arbitrary files in the scp client target directory. If recursive operation (-r) is performed, the server can manipulate subdirectories as well (for example, to overwrite the.ssh/authorized_keys file).

, вырванное из контекста. Во-первых, не подключайтесь к вредоносному ssh-серверу. Не обвиняйте SSH в том, что кто-то использует протокол, настраивая свой ssh-сервер для перезаписи произвольных файлов в целевом каталоге клиента scp. В первую очередь используйте ключи сервера/клиента, чтобы правильно установить SSH-соединение, и нет вредоносного сервера MITM.

scp, то есть ssh, безопасен. Сказать, что scp небезопасен, по сути означает, что ssh не следует использовать, потому что ssh небезопасен, а это неверно.

SSH = secure shell

scp = secure copy over SSH

ftp = file transfer protocol

sftp = SSH ftp

ftps = ftp over TLS/SSL

Следует ли заменить scp на sftp?

когда вас не беспокоит ключ хоста/отпечаток пальца сервера и вы просто нажимаете ОК,спросите себя, как тогда это нормально с sftp (подключением к серверу, у вас нет гарантии, что вы думаете, что это ).

Как только между двумя точками установлен коммуникационный SSH туннель , семантика связи внутри, будь то безопасная копия или протокол передачи файлов, в этот момент тривиальна. scp, то есть ssh, безопасен. Сказать, что scp небезопасен, по сути означает, что ssh не следует использовать, потому что ssh небезопасен. И это неправда. Если я позвоню вам по телефону, а вы станете причиной чего-то плохого с моей стороны, это не вина телефонной компании.

"The scp protocol is outdated, inflexible and not readily fixed. We recommend the use of more modern protocols like sftp and rsync for file transfer instead."

pleeeasssee.... rsync сам по себе не выполняет шифрование, и вы сталкиваетесь с той же проблемой: нет гарантии, что вы подключаетесь к тому, кем вы его считаете. Но в этой инсинуации rsync получает пропуск? Внимательно относитесь к тому, откуда вы берете рекомендации.

Я бы сказал, что многие команды Unix становятся небезопасными, если вы считаете возможным MITM на SSH. Злоумышленник sudoможет украсть ваш пароль, вредоносный коммуникационный клиент может прочитать вашу почту/мгновенные сообщения и т. д.

Сказать, что замена scpна sftpпри общении со скомпрометированным сервером как-то исправит ситуацию, по меньшей мере, очень оптимистично. Любой ущерб, который scpможет нанести вашим локальным файлам, также может быть нанесен с помощью двоичного файла, сценария оболочки, файла Python, Makefile и т. д., и мошенник sftpс радостью вам их предоставит.

Короче говоря, если вы не обращаете внимания на то, на какие серверы вы подключаетесь по SSH, существует высокий риск того, что вы облажаетесь независимо от того, какие инструменты вы используете, и использование sftpвместо scpбудет только незначительно безопаснее.

Это не означает, что переход на sftp— плохая идея. :Если это лучший инструмент для решения поставленной задачи, то у вас есть веская причина для перехода, которая, впрочем, не связана с безопасность.

Существует много путаницы в отношении новых OpenSSH изменений в scp, сделанных в ответ на CVE -2019 -6111 , и того, насколько они безопасны. сделать все.

Их цель — предотвратить отправку мошенническим сервером, используемым в качестве источника файлов, файлов с именами, отличными от запрошенных, и перезаписать случайные файлы на локальном компьютере.

Но они не действуют при использовании опции -r. Использование -rподразумевает -T.

Несмотря на то, что это совершенно логично, многие люди не осознают этого, и они будут усыплены чувством самоуспокоенности, всегда ожидая, что scpбудут проверять имена файлов. Пока однажды они не столкнутся с суровой правдой. «Безопасность», обеспечиваемая этим, не лучше, чем alias rm='rm -i'.

Поскольку настроить мошеннический сервер ssh/scp только для тестирования может быть довольно запутанно, вы можете использовать параметр -S programв scp(, который предписывает использовать другую программу, а не 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(3)с GLOB_ALTDIRFUNC|GLOB_BRACE, но писать новый код всегда веселее. В любом случае, обратите внимание, что реализация раскрытия фигурных скобок в scp почти csh -похожа на ie. {{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