Якуб Елень (Jakub Jelen), инженер по обеспечению безопасности из компании Red Hat, предложил перевести протокол SCP в разряд устаревших. SCP концептуально близок к протоколу RCP и наследует фундаментальные архитектурные проблемы, которые являются источником потенциальных уязвимостей...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=54039
> инженер по обеспечению безопасности из компании Red Hat, предложил
> в репозиторий copr уже помещён альтернативный пакет c opensshтак и надо написать: шляпа планирует дропнуть протокол. а то ведь не каждый "предложил" может похвастаться что его предложения "уже" в репозитории тестируют
А вы как работаете? Неужели ваш груплидер вас не имеет в хвост и гриву. Необходимо изгиляться и извращаться предлагая улучшения продукта или вылетишь в этом квартале с голой попой на мороз. Приходится человеку доказывать что он не лузер цеплясь зубвми за повышение и не только зряплаты.
Очевидно же, что эти детские проблемы на раз-два чинятся, но нет - живьем закапывают.P.S. литнеграм на заметку: чем больше в подобных "новостях" серьезной воды, тем очевиднее реальная их суть.
> Очевидно же, что эти детские проблемы на раз-два чинятсяНет, не очевидно. Ты сам подумай. Во-первых, список файлов. Но список файлов может содержать glob'ы, а промеж файлов могут быть ссылки. Это решаемая проблема, тут я не спорю, но её не удастся решить создав на стороне клиента ассоциативный массив запрошенных имён файлов, и потом проверяя каждый прилетающий файл на наличие в этом ассоциативном массиве. Придётся полностью разбираться со всеми квирками юниксовых путей, с тем чтобы заткнуть все дыры. А чтобы это сделать, надо сесть на неделю разбирать историю уязвимостей во всевозможных программах, чтобы составить список тех дыр, которые возникают при работе с unix'овыми путями. Это не детская проблема, а очень даже взрослая.
Во-вторых, интерпретация имён файлов на стороне сервера. Насколько это нужная штука в scp и зачем она там? Можно ли её просто вырезать? Я не знаю, не заглядывал в scp, но предположу, что дело в glob: шеллу прокидывают строчки как есть, чтобы тот раскрывал бы все *[] в именах, и тому подобные символы. Если я прав, то тогда, напрашивается вырезать использование шелла насовсем, и та потеря функциональности scp, которая последует за этим, станет частью "во-первых", который выше. Если же дело в чём-то ещё, то ситуация может оказаться резко сложнее, вплоть до обычной unix'овой дилеммы: либо реализовывать половину шелла в своей программе, либо затыкать бесконечные дыры, накладывая один за другим экранирующие фильтры на строчки.
Я к тому, что это существенно _не_детские_ проблемы, детский подход к ним (типа тяп-ляп, заработало, и учитель уже хлопает в ладоши от радости, потому что дитё хоть что-то сделало) не поможет тут.
> P.S. литнеграм на заметку: чем больше в подобных "новостях" серьезной воды, тем очевиднее реальная их суть.
Кому-то очевиднее, кому-то, как мы видим, нет.
> промеж файлов могут быть ссылки.Не так страшны ссылки как их малюют дилетанты.
> Во-вторых, интерпретация имён файлов на стороне сервера. Насколько это нужная штука в scp и зачем она там?
Ordu, а Вы, вообще, вменяемый?
Сервер *не может* не интерпретировать имена файлов! как и клиент.
Если клиент перезаписывает существующие имена, либо пишет их в непредназначенный каталог, то это ошибка в клиенте."непредназначенный каталог" - это все что мимо cd /каталог/предназначенный/для/приема_файлов
Хочешь перезаписать - добавь ключик --force.
> Сервер *не может* не интерпретировать имена файлов! как и клиент.Так ли необходимо распознавать в именах файлов конструкции `rm -rf ~/*` и интерпретировать их?
Вообще, я не припомню когда последний раз видел в дикой природе -- всё больше rsync используется. Ещё fish был, потому что в mc при подключении к ssh он, а так везде и всегда rsync.
Rsync есть не всегда и не на всех системах. Да и единичные файлы дергать по scp удобно.
Наверно большинство пользователей scp на самом деле используют sftp, иного объяснения у меня нет. В таком случае, никаких проблем. А fish удобно в kde и mc использовать -- можно посмотреть файлы и выбрать нужный.
Sftp удобно открывать когда нужно много чего скопировать или используешь какой нибудь фм. А если сидишь в консоли и нужно скопировать то что известно где лежит то проще scp дёрнуть. Но я думал что scp в качестве транспорта sftp использует. А оказалось что нет :(
Выглядит ненадёжно, rsync хотя бы старается не пролюбить данные в процессе. У меня с некоторых пор пунктик на тему повреждённых данных (в идеале нужно ещё и верифицировать дополнительно после перезагрузки, но мне каждый раз лень тратить на это время).
Это называется паранойя
> Это называется паранойяесли у вас паранойя - это не значит, что за вами не следят
Глупость это называется. Испортить файлы при передаче криптографически-стойким протоколом можно, но ровно при тех же условиях, при которых "rsync старается" бестолку.Варианта сверки хэшей при этом никто не отменял, особенно для очень больших или очень ценных файлов, поскольку портиться битики могут, внезапно, уже после передачи - или до ее начала.
Так именно поэтому и rsync -- он может верифицировать файлы не только в процессе (он это делает), но и постфактум. Для локальных файлов использовать что-либо кроме rsync тоже абсурдно (это помимо различных исключительно удобных и полезных опций вроде ограничения пропускной способности).
> Так именно поэтому и rsync -- он может верифицировать файлы не только в процессе (он это делает)и чаще всего - даром жрет при этом ресурсы.
Потому что работает поверх ssh, внезапно. В 99% случаев этого достаточно, чтобы не забивать себе голову глупостями.> Для локальных файлов использовать что-либо кроме rsync тоже абсурдно
пока не перепутаешь семантику последней / в пути чего-нибудь большого. После этого тебе абсурдно покажется использование столь кошмарно кривой утилиты там, где она нафиг не нужна.
У rsync одна единственная ниша - обеспечивать идентичность копии, когда большая часть уже скопирована и неизменна. Больше ни для чего он не нужен со своими миллиардами ключей и бредовым синтаксисом.
Кстати, уязвимостей в нем было совершенно чудовищное количество, как и во всем, что придумано кенгуроидами.
Как ещё ты предлагаешь бороться с бит флипом? Знаешь ли можно прочитать не то и записать не то, не только передать не то. Нормальные там ключи, может не всем расширенные атрибуты копировать надо. А насчёт жора ресурсов, это тоже достаточно гибко настраивается (и можно использовать md4 вместо md5, например).
> Как ещё ты предлагаешь бороться с бит флипом?покинуть секту свидетелей битфлипа. Ты его в своей жизни с высочайшей вероятностью никогда не увидишь.
Это актуально либо на терабайтах (причем не все терабайты одинаково полезны - многим пофиг что там один бит поменяется) либо на криптографической информации. И только при условии что ее нельзя восстановить или заменить. То есть почти никогда.
Ну например если один из твоих многотерабайтных архивов побился в процессе, это сразу принесёт много проблем и потерю рандомного количества данных. А вообще, если, скажем, в процессе бэкапирования используются 2 копии данных, чтобы повреждения не стали фатальными, необходимо сразу замечать и битрот, и битфлип, и посыпавшиеся диски.
> Ну например если один из твоих многотерабайтных архивов побился в процессе, это сразу принесёт
> много проблем и потерю рандомного количества данных.нет. Это с высочайшей вероятностью не будет замечено никем, никогда и ни при каких обстоятельствах.
Предполагаю, что архивы все же не .tar.gz на многотерабайтов или потоковый шифр.> А вообще, если, скажем, в процессе бэкапирования используются 2 копии данных
и тем более в этом случае - несчастный один битик будет безвозвратно перезаписан прямо завтра, на следующей же итерации. Никто даже не узнает о его печальной судьбе.
Как узнать, повредилась сегодняшняя версия, или вчерашняя? Да если у нас не btrfs и вообще хэшировать терабайты по кд несколько весьма субоптимально? Наверное, примерно так же думали те ребята, которые преодолели скорость света (аж несколько раз).
А ещё бывает неисправная память, с ней разнообразные ошибки случаются постоянно.
это просто отличный вариант для бэкапа, ну конечно же.
Ну заранее ведь не знаешь. Чем больше раз перепроверишь, тем меньше риск остаться с кашей вместо данных.
> Ну заранее ведь не знаешь.Знаешь. Вероятность мизерная, на исправной аппаратуре. На неисправной вероятнее всего навернется сам ssh - и вот это звоночек, что надо что-то чинить.
> Чем больше раз перепроверишь, тем меньше риск остаться
> с кашей вместо данных.Без многих данных вполне можно пережить. Более того, большая часть тех данных никем и никогда вообще не будет прочитана. Что-то будет жалко потерять. Но не смертельно. При этом вероятность хоть раз в жизни своими глазами увидеть перевернувшийся битик - повторю, почти нулевая.
Гораздо больше шансов словить невосстановимую ошибку fs из-за неудачного сбоя электричества, пробившего фильтры. Причем повредить может уже перепроверенные тобой сто раз файлики, неудачно убив метаданные.Поэтому секта потерянных битиков - просто трата твоего времени. А вот оно как раз - невосполнимо.
Кроме того бывает контроллер посыпался… Нет, знаешь, я, пожалуй, буду использовать правильные подходящие задаче инструменты, а не уповать на рандом.
> в идеале нужно ещё и верифицировать дополнительно после перезагрузки,Да. Но это без связи с копированием данных по сети.
Например https://wiki.debian.org/CheckingDebsums> но мне каждый раз лень тратить на это время
Лень в неправильном месте. Собственно верификацию легко автомаризировать. Интересно становится, когда верификацалка радостно рапортует "с прошлого раза поменялись такие-то файлы", и надо решать что с этим делать. Они же могли и вполне легально поменяться.
Это не так просто всё же. Затраты времени людей, затраты машинного времени, потенциальные внезапные траты на анализ и исправление проблем, вероятные ошибки самого разного толка. Одно время я применял par2 как дополнительную меру, вроде пару раз даже пригодилось. Но это тоже в отрыве от "космические лучи нам нагадили в тапки".
> Вообще, я не припомню когда последний раз видел в дикой природе -- всё больше rsync используется. Ещё fish был, потому что в mc при подключении к ssh он, а так везде и всегда rsync.ну я, например, пользуюсь. Потому что rsync ставить лень.
То чувство, когда узнаёшь, что ездил на пороховой бочке каждый день.> например, вместо запрошенного "test.txt" сервер может передать файл с именем ".bashrc" и он будет записан клиентом
(O_o) т.е. при scp /root/kittens.jpg я могу получить по сети незаметно новую систему? классно.
Странно что из openbsd это ни кто не предложил раньше. Раз уж в опенке пилят tmux, bgp, smtp и др., то могли бы из замену scp сделать. А там бы уже растащили по др реалезациям.
что странного? openbsd у нас оплот света в тёмном современном мире IT, носитель здравых идей? или просто знамя, объединяющее изобретателей велосипедов, отягощенных поиском фатальных недостатков в существующих и (немаловажно) работающих концепциях?
А можно для тупых уточнить. Ладно когда что-либо меняют просто потому что. Но тут же возможность создавать и перезаписывать файлы, да еще и выполнение команд. По-моему отличный вариант - заменить. Что я не так понял?
Сабж вообще не при делах, речь о том, что некие любители похэйтить линукс используют ровно тоже ре-шето и молчат в тряпочку. А вообще я хз что это за scp всю жись ssh использовал, полагаю тяжОлое насление тех самых бсд и прочих тру-юникс.
> По-моему отличный вариант - заменить. Что я не так понял?что если "отличный вариант" только заменить тормозным дерьмом с bloated-протоколом для нескучной эмуляции ftp (кривой и бесполезной) - то что-то с этим отличным вариантом не так.
Возможно он отличный от хорошего, а с такими руками не стоило и браться.
SFTP это не FTP в обертке как ftps, это нормальный современный протокол
Нет, это кривой рукожопый косплей ftp как его поняли и "улучшили" модные-современные разработчики (вероятно видевшие исключительно в агитках гугля "как все там неправильно", поэтому пропустившие и fxp, и on-the-fly archiving и много чего еще).
Ничего нормального в нем нет - что и доказывает тормознутость в сравнении с банальным scp 1996 года разработки. Авторам ftp такое "достижение" и не снилось - казалось бы - ну как?!
Я правильно понимаю, что вы сейчас FTP хвалите? Тот самый FTP в котором нужно настраивать настройки настроек чтобы не получить после передачи битые либо не до конца переданные файлы (о чём ни один FTP-клиент не скажет)? И к которому SSL прикручен так коряво что в 99% случаев не работает и подлежит упорной НАСТРОЙКЕ НАСТРОЕК НАСТРОЙКАМИ НАСТРОЙКИ при помощи системного администратора и такой-то матери???
> Я правильно понимаю, что вы сейчас FTP хвалите?Если у вас возник вопрос "Я правильно понимаю ...." это означает что вы не соответствуете интеллектуальному уровню беседы.
Куда уж нам, простым пользователям FTP, до ваших высот.Если у вас не получается FTP, то зачем вы мучаете себя и FTP?
Тут либо вы не умеете его готовить, либо он вам не подходит.
По пунктам, где? sftp - вот совершенно не похож на ftp. Скорее, уж на Plan9 больше похож.
> SFTP это не FTP в обертке как ftps, это нормальный современный протоколПохоже слова "хороший" и "современный" в айти-мире скоро станут антонимами.
Тяп-ляп и шифрование сбоку :-(
Производительность и эффективность не важны, железо дешёвое, "закон" Мура (кстати, где он?) и ты.пы. Печаль :-(
Потом ещё клеймят людей, не желающих обновлять рабстанции.
Первая мысль при необходимости обновиться: "что сломали на этот раз?"
Так, падажжи, но ведь если по теореме Эскобара, то решение-то какое?
> Так, падажжи, но ведь если по теореме Эскобара, то решение-то какое?Известно, какое - растить коку на погибель мирового империализма, стать миллиардером и почти святым.
Главное - с телефоном поаккуратнее, хотя и не поможет.
Там сказано "до недавних пор". Незнаю насколько недавних, но во всяком случае сейчас проверяет, см. ключ -T в man-е.
>5 лет назад как минимум. У меня OpenSSH_6.6 от Jan 2014, это когда я последний раз обновлялся. И ключ -T у scp уже был.
> Для тестирования в репозиторий copr уже помещён альтернативный пакет c openssh, в котором применён патч с реализацией утилиты scp поверх протокола SFTP.Это хорошо, если саму утилиту scp оставят: она все же очень удобная. Еще лучше, если бы какое-то время новая реализация умела подключаться к серверам без sftp тоже.
*данные_удалены*, инженер по обеспечению безопасности из компании *данные_удалены*, предложил перевести протокол SCP в разряд устаревших.
Проект закрыт, все монстры умерли от старости.
Все монстры перешли на руководящие должности, содержание провалено, [данные удалены], сопротивление бесполезно.
а COPR - это они на что намекают?
Там ещё логотип характерного цвета
> а COPR - это они на что намекают?На то самое. Не стесняются даже.
прям стыдно стало...
постоянно использую 😮
Используешь устаревшие технологии?
ФФФУУУУУУУ!!!
Поддерживаю.
Не просто пользуюсь каждый день, а по десятку раз. Именно так - "удобно копировать единичные файлы".
Только сегодня по работе копировал файлик ~180ГБ. Сначала попробовал с помощью sftp, получил ~10МБ/с и почти 5 часов. Запустил через scp и скопировал за 40 минут со скоростью ~60МБ/с. Нафиг нужен такой sftp...
Попробуйте rcp. У меня упёрся в шпиндели на 600 Мб/сек.
> Попробуйте rcp. У меня упёрся в шпиндели на 600 Мб/сек.https://www.opennet.ru/openforum/vsluhforumID3/122347.html#24
И чё? Вот у меня была вполне себе практическая задача скопировать около 26Тб по 10Гбит сетке как можно оперативнее. rcp упёрся в шпиндели, остальные популярные решения - в свой код и, местами, в процессор. Потребность в безроасности тупо преувеличена.
Было бы наверняка проще на харды скопировать и переставить ручками в нужный сервер.
Там чел говорит - "rcp упёрся в шпиндели".Неужели при подключенном диске у него шпиндели быстрее?
Надо будет поэкспериментировать.PS. а, блин, не получиться. В серверную пропуск/допуск/анализ на яицеглист/не собираешься скоро уволиться оформлять.
Увы, не подходит. Если на рабочую машину я ещё смогу поставить, то на сервер, на который копировал, не разрешат. В этом ещё одно преимущество и scp, и sftp перед другими решениями. Они есть практически везде.
Гм. Если по дороге проблемный канал (может отвалиться), я бы предпочёл rsync с докачкой (--append-verify).
А так, "ssh host -- cat /path/to/src > /path/to/dst"
Если сеть узкая, тут же можно и пожать. А если нужно много чего, есть tar.
И никаких сюрпризов от scp. Всё явно расписано.С той стороны что-то очень слабое? Можно подкрутить шифры, вплоть до "выкл". Или лить через netcat|nc (в отличие от rcp, его никто не депрекейтит).
Спасибо за варианты, буду иметь ввиду.
Сеть достаточно стабильно работает, а scp ещё и показывает прогресс в отличии от вариантов с cat и nc. rsync - да, забыл про него. А вообще было лень экспериментировать и просто открыл mc и там запустил копирование. Просто и удобно.
sftp попал под руку как раз из-за новости.
> Из ограничений предложенного подхода упоминается невозможность обмена данными с серверами, не запускающими подсистему sftpНу так сам же сказал:
"для каких-то особых случаев в утилите предусмотрена опция "-M scp" для отката на протокол SCP"
- Вот и выход.
Если реализация утилиты scp полноценная, то решение можно только приветствовать.
В философии юникс важно выполнение программой своих задач, а не конкретный способ.
Т.е. погодите, клиент запрашивает файл X, сервер отдаёт данные и говорит "это по чесноку файл Y", а клиент такой "я спрашивал, конечно, X, но запишу в Y раз такое дело". Что-то мне подсказывает, что проблема тут не только в сервере.
> Что-то мне подсказывает, что проблема тут не только в сервере.Просто эту проблему кривожопики из федоры исправить не в силах. А испортить клиент чтобы он просто не работал с "небезопастным" протоколом - с легкостью.
Какая проблема?! scp по умолчанию строго проверяет файлы.
Как насчёт * ?
По умолчанию проверяет. Вот если укажешь -T, тогда не будет.
Что проверять-то? "Скачай мне все файлы" - что тут можно проверить? С чем сравнить?
Ты шутишь чтоль?
Как минимум:
1. Проверять что нет попытки выйти за текущую директорию (ну типа ../../ либо /хочу/в/root)
2. Проверять что файл уже есть (может был, может только что скачали)По умолчанию поведение такое - в текущую директорию, не перезаписывать уже существующие.
Нет никакой проблемы уже чёрт знает сколько пятилетокman scp
-T Disable strict filename checking. By default when copying files
from a remote host to a local directory scp checks that the
received filenames match those requested on the command-line to
prevent the remote end from sending unexpected or unwanted files.
Because of differences in how various operating systems and
shells interpret filename wildcards, these checks may cause
wanted files to be rejected. This option disables these checks
at the expense of fully trusting that the server will not send
unexpected filenames.Вот и всё, по дефолту - строгая проверка, а кому нужны разношаблонные гетерогенные системы - пусть -T юзают на трастовых серваках..
> Нет никакой проблемы уже чёрт знает сколько пятилетокafair, всего пару лет, и то в апстриме. После соответствующей CVE.
Причем не факт, что проблема полностью решена, не так это и тривиально для современных кодерков.
> всего пару летКакие пару лет?! У меня дистр уже больше 5 лет не обновлялся, а ключ -T есть.
Эта доработка появилась в OpenSSH 8.0.
ssh -V
OpenSSH_7.5p1, OpenSSL 1.0.2s-freebsd 28 May 2019понятно, что у любителей обмазываться свежайшим только-что-из-под-хвоста-прилетело, уже пять лет назад в их раче была самая распоследняя версия (в которой, попутно, сломали пару куда более важных вещей), еще даже недописанная.
> Эта доработка появилась в OpenSSH 8.0.Врёшь, у меня ssh -V
OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.13, OpenSSL 1.0.1f 6 Jan 2014
и ключ -T уже был тогда.
SCP (от англ. secure copy) — утилита и протокол копирования файлов между компьютерами, использующий, в отличие от утилиты RCP, в качестве транспорта не RSH, а шифрованный SSH. Сходная по функционалу утилита — sftp.
Да, пришлось поискать, спасибо мне за инфу.
Давно пора. Но -3 нужна, конечно. Хоть синей изолентой, но надо её прикрутить.
Снова рэдхатовские копрофаги предлагают выбросить что-нибудь работающее и заменить...ах да, ничем не заменить :-(
научись читать, дегенерат
> научись читать, дегенератЗамены нет, а это дропнут в пару лет, "интеллектуал".
На openwrt роутерах с ограниченными аппаратными возможностями часто не лезет sftp сервер, пользуемся scp потому. И тут х... компания redhat предлагает грохнуть scp, взамен не предлагая реальной альтернативы для роутеров.
scp ещё и быстрее sftp
Наверно зависит ещё и от того как поток зашифрован. Ну а так меньше надёжности - выше скорость, всё как обычно.
"для каких-то особых случаев в утилите предусмотрена опция "-M scp" для отката на протокол SCP"
Ну это пока предусмотрена. Годик-другой - и дропнут, потому что "не пользуется популярностью". Как будто ты красношапку не знаешь.
> Ну это пока предусмотрена. Годик-другой - и дропнут, потому что "не пользуется
> популярностью". Как будто ты красношапку не знаешь.Форкни и поддерживай, это ж опен сорс.
Ах, у сообщества сил нет? Тогда жрите что дают.
> Форкни и поддерживайТы забыл добавить: "затолкай во все дистры ко всяким поттерингам".
>> Форкни и поддерживай
> Ты забыл добавить: "затолкай во все дистры ко всяким поттерингам".Тебе надо — ты и делай.
передайте это в SCP foundation
Эм... а нафига scp пользовать не в локалке / VPN?
А почему SCP не проверят название файлов, которые получает? Это же, блин, очевидный баг.
Субординация.
читай man, по умолчанию - как раз проверяет. Нет никакого бага.
КАК ? Как, например, tar будет проверять какие файлы он распаковывает?
> КАК ? Как, например, tar будет проверять какие файлы он распаковывает?молча. Если ты укажешь ему destination - то будет проверять. Все что не совпадает - просто не будет распаковано вообще. Кстати, в этом месте много лет назад была очередная дырка, ага.
Что он будет проверять?
Когда там ждать systemd-copyd?
Завтра волью в мастер
Спасибо!
печет, ретроград? это хорошо
Вообще, идея использовать sftp как замену scp при сохранении синтаксиса команды scp вполне здравая, пусть будет.
> Вообще, идея использовать sftp как замену scp при сохранении синтаксиса команды scp
> вполне здравая, пусть будет.Ну да, скорость не нужна, сойдёт и так. Здравствая идея.
На одном-двух файлах разница в пределах погрешности, а когда нужна скорость на пачку файлов, надо делать tar cf - | ssh tar xf -. Быстрее всяких scp и sftp на порядок.
> Быстрее всяких scp и sftp на порядок.сказочник... На четыре порядка!
И да, конечно же эти приседания с кучей лишних команд очень безопастны (в tar ведь не было никогда точно таких же ляпов с ../.. в разных вариациях) и охренеть как удобны.
В то время, пока одни выпиливают ftp ото всюду, другие вспомнили и пытаются его использовать...
Ну и причём тут FTP?
А ctrl+C, ctrl+V оно в линуксах нельзя так?
На удаленный хост, где есть только шелл? Поумнее вопрос не мог придумать?
А ты сайты также смотришь - ctrl+C, ctrl+V?
Нет, по-моему. Я как-то искал fuse поверх scp и не нашёл. Может плохо искал, конечно. Но, полагаю, всех потенциальных написателей такого отпугивает то, что scp не предусматривает исследования файловой системы на том конце провода. Что можно обойти, но... эмм... в общем вот.
sshfs?
Почему "?" в конце сообщения? Ты хочешь, чтобы я сходил в гугл, нашёл, посмотрел, что это такое, и сказал тебе, оно или нет? Или надо ещё поставить и оттестировать, чтобы ответить на твой вопрос?
? в данном случае означает "не подошёл?" или ты нам предлагаешь угадать что именно нужно твоей тупой голове?
> ? в данном случае означает "не подошёл?"Это вовсе неочевидно. Разговор о Ctrl-C/Ctrl-V, и о принципиальной возможности использовать их для копирования через scp. И тут ты такой приходишь и переводишь тему, забыв объяснить свои намерения. Но в любом случае я не могу ответить на этот вопрос -- я чё помню, что ли?
Да и вообще, тебе должно быть виднее можно ли при помощи sshfs подмонтировать систему доступную по ssh и потом копировать через C-c/C-v, или нельзя. Вон ответь анониму, он переживает очень из-за этих C-c/C-v.
Да я не то чтобы переживаю. Просто в Win10, Win Server 2016 это есть и работает удобно и без проблем. Когда-нибудь и линуксы до этого дорастут. Я надеюсь.
> Да я не то чтобы переживаю. Просто в Win10, Win Server 2016
> это есть и работает удобно и без проблем. Когда-нибудь и линуксы
> до этого дорастут. Я надеюсь.Я, наоборот, надеюсь, что не дорастут. Если бы мне нужен был win server, я бы поставил win server. Он мне не нужен, у меня linux.
> Ты хочешь, чтобы я сходил в гугл, ...Да!
И "сходил" не подразумевает "вернулся", можешь там оставаться, можешь сходить дальше.
>> Ты хочешь, чтобы я сходил в гугл, ...
> Да!
> И "сходил" не подразумевает "вернулся", можешь там оставаться, можешь сходить дальше.Хорошо. Хоти дальше.
sshfs удобно когда нужно больше чем один файл передать или покопаться в файлах. А просто скопировать 1 файл, если знаешь имя, то нет ничего проще scp.
> А ctrl+C, ctrl+V оно в линуксах нельзя так?В Nautilus-е можно, даже Ctrl-Z в некоторых случаях.
И в консоли тоже можно, но там это Ctrl-й совсем про другое.
Да, мне тоже эти протоколы нравятся!
При копировании спулфайлов с AS400 только Ctrl+C, Ctlr+V кодировку не портят.
Линуксу до этого ещё развиваться и развиваться.
В последнее время, при при смотре сабжа выбираю именно плов - кажется, так оно будет аутенчичнее)
scp -T ? По-умолчанию выключено , так что это все пук в лужу не более.
А что, хорошая идея. Достало уже пробелы два раза эскейпить.
Очередные дибилы хотят что-то простое убрать, а в замен оставить только сложное и "правильное" для них. Пропатчить scp, нет! Поставить еще одно дырявое корыто, да!
> Пропатчить scpуже, scp -T
sftp сложно, как и ftp команды.
> устранить без нарушения обратной совместимости, например, некоторые пользователи используют запуск команд для проверки наличия каталога перед копированием.Уж вот таких-то остроумцев девляпса не жалко...
> В Fedora предложили перевести протокол SCP в разряд устаревшихПора предложить перевести Fedorу в разряд устаревших
Страннвя инициатива
Напоминает systemd-аргументацию. Корпорасты как всегда. Сначала они присосались и помогали, как все привыкли — обнаглели и стали шарить ручками, выкидывать добрые старые решения в пользу своего внутрикорпорастного продукта.Небизопасно, запретить, удалить ради детей!
Интересно, это инженер с тем самым временным дипломом
У него ещё и диплом какой-то есть?!
Да целых шесть!
Маникюр, Педикюр, Кирби супервайзер, Наращивание ногтей и ещё пару каких-то. Я не запомнил.
Он там смузи прокисшего навернул?
Куда они полезли. Ведь scp же простая и удобная обёртка над ssh. Какую команду передашь такую и исполнит. Хотя передавать что-то кроме имени файла не порядок. А если у тебя есть доступ с ключём к серверу, то кто тебе даст запретить исполнять команду просто по ssh. Какое отношение это имеет к безопасности.
А все scp это по сути сокращённые команды ssh и можно использовать ванильный ssh и перенаправление вывода.
> Куда они полезли. Ведь scp же простая и удобная обёртка над ssh.
> Какую команду передашь такую и исполнит. Хотя передавать что-то кроме имени
> файла не порядок. А если у тебя есть доступ с ключём
> к серверу, то кто тебе даст запретить исполнять команду просто по
> ssh. Какое отношение это имеет к безопасности.
> А все scp это по сути сокращённые команды ssh и можно использовать
> ванильный ssh и перенаправление вывода.Они не понимают перенаправление вывода, как не понимают регулярно. От этого дико ненавидят perl.
>> Куда они полезли. Ведь scp же простая и удобная обёртка над ssh.
>> Какую команду передашь такую и исполнит. Хотя передавать что-то кроме имени
>> файла не порядок. А если у тебя есть доступ с ключём
>> к серверу, то кто тебе даст запретить исполнять команду просто по
>> ssh. Какое отношение это имеет к безопасности.
>> А все scp это по сути сокращённые команды ssh и можно использовать
>> ванильный ssh и перенаправление вывода.
>Регулярные выражения, конечно. Горите в аду, сотрудники говнугля за создание своей клавиатуры.