Комментарии 131
Для меня магия SSH была, когда я научился копировать файлы между серверами напрямую, с помощью scp
scp -3 user@from-server:/home/user/backup.sql.gz user@to-server:/home/user/backup.sql.gz
Конечно при этом не работает прогресс-бар, но он и не нужен, достаточно посматривать на конечном сервере размеры и количество файлов.
А самое главное, что scp поддерживает конфиг из .ssh/config и не нужно дублировать параметры подключения к серверу
помнится я делал прогресбар для scp прогоняя пайп через pv.. если мне не приснилось то можете попробовать
С scp у меня не получилось, потому что оно не умеет читать stdin, но связка pv | ssh "cat" сработала. Для желающих попробовать можно взять код отсюда (строки 99-112).
ssh -L удобно использовать для всяких webui из внутренней инфры. Конечно их можно вывести наружу, но это лишние риски. ssh -L 9090:localhost:9090 prometheushost и можно открыть prometheus из внутреней сетки без паролей, только по ключам.
ssh -J должен быть знаком всем плюс минус серьезным админам. В окружение лучше прыгать через bastion ноды, которые редко где отсвечивают, а не напрямую. Понятно, что может быть VPN, но так вроде проще, чем постоянно прыгать по разным приватным сетям.
Запуск графических приложений на удалённой машине.
но в теле статьи не НА а С..
Putty может копировать файлы - в составе есть отдельный консольный клиент pscp.exe
Вот только в десятке из коробки есть родной scp и ssh
Но из коробки нет ssh-copy-id :(
Не велика потеря, или в виндовой консольке нет пайпов?
Гораздо хуже как по мне то что виндовый ssh клиент не умеет в контролпасы из-за того что винда не умеет в юникс сокеты..
винда не умеет в юникс сокеты..
Умеет с 2017 года https://devblogs.microsoft.com/commandline/af_unix-comes-to-windows/
Как видно, графические приложения удалённого сервера прекрасно взаимодействуют с мышью.
Но к сожалению — не всё так радужно. Конечно, можно весь оконный менеджер так запустить, и оно будет работать, но будет дико тормозить.
ну не дико, вполне приемлемо если в пределах одной локалки, ну а в пределах тырнетов тут много факторов одно время у меня так главбух из дома в 1С заходила пока vpn починяли, печально, но работать можно.
а чтобы работало шустрее и поддерживало аппаратное ускорение есть vglconnect/vglrun, правда сам я не пробовал
VcXsrv как-то очень сильно похож на XMING который я когда-то юзал для тех же целей
а вот вместо Putty рекомендую попробовать Bitvise
Пользую https://wiki.x2go.org/doku.php
которая надстройка над VcXsrv
А еще есть MobaXterm, она со встроенным X сервером.
Это какой-то адски перегруженный комбайн.
Уж лучше портабл софт с тремя файлами, чем иксервер в систему имхо
Уж лучше портабл софт с тремя файлам
Нет там никакого portable. Ну да, пара файликов, только по факту при запуске "портабельной" версии она все равно устанавливается в AppData — там почти 2000 файлов.
чем иксервер в систему имхо
Не вижу проблем его поставить или использовать честную портабельную версию какого-нибудь VcXsrv.
VcXsrv is a open source project under GPLv3 license about building reliable X Server using Visual Studio in potentially optimal manner. It's common knowledge Microsoft Compilers are very good for Windows platform, since there are free variants it's tempting option. It was my first choice for X Server when I tried Windows Subsystem for Linux for the first time in Windows 10.
Xming is a weird project which under term Donation hides a price for the installable binaries. I always though donations are voluntary, but it seems the author has different perception. This project was the only option to have X Server on Windows natively for very long time, but since we have VcXsrv, there is choice.
I personally have very good experience with VcXsrc, it's easy to install and works very fast. I'm surprised it's not more popular. As far as I know their code is more clean version of original X server and doesn't relate to Cygwin.
Отсюда.
по личному опыту, xming имел странные глюки при синхронизации clipboard-а и с клавиатурными раскладками. Перенос клипборда просто переставал работать в рандомные моменты. Переход на VcXsrv это существенно облегчил.
Хотя я это наблюдал во время Windows 7 и xming 6.x, возможно, сейчас в xming 7 это починили.
Немного странный порядок действий в статье — сначала отключить root-доступ с перезапуском ssh-демона, и только потом проверить "успешность подключения от своего аккаунта" — может быть стоит делать наоборот, ну или хотя бы отключать доступ руту, войдя для этого со своего аккаунта?
Следует также упомянуть о том, что в некоторых случаях вместо PermitRootLogin no вполне безопасно можно использовать PermitRootLogin prohibit-password.
Кстати да, я последнее время не понимаю этой мантры "закройте рута по ssh", ведь вся проблема исходит только от паролей и возможности их перебора, отключите парольную авторизацию (ну и еще можно fail2ban сверху воткнуть) и проблема чаще всего решена.
Другое дело, что это провоцирует работу от рута, но это уже совсем другая тема для обсуждения.
Догадаться какой пользователь на сервере сильно сложнее, чем пытаться сбрутить рута. Хотя без сомнения и это тоже брутится.
ну догадались, и что дальше? пытаться сбрутить ключ, серьёзно?
Ключ root брутить сильно проще?
Если вы внимательно читали эту ветку комментариев, то вам рекомендовали вместо отключения входа рута по ssh отключить парольную аутентификацию для рута:
Следует также упомянуть о том, что в некоторых случаях вместоPermitRootLogin noвполне безопасно можно использоватьPermitRootLogin prohibit-password.
Впрочем, я обычно полностью отключаю парольную аутентификацию на ssh.
текстовый пароль можно сбрутить
geVUsge9cdj2cRG - то что генерирует парольный менеджер. Удачи ;)
И в таком случае, даже при длинном текстовом пароле шанс брута далеко не нулевой.
Там 6615 ≈ 2 · 1027 вариантов, из которых надо перебрать до успеха в среднем половину, то есть 1027. Если делать 1000 попыток в секунду (чего никто не делает) — это займёт 6 · 1016 лет. Да блин, вселенная ещё столько не просуществовала!
И это в предположении что атакующий знает длину пароля. Удачи.
1. Не учитывается что пароль может быть в словарях.
2. Не учитывается то, что пароль может быть скомпрометирован.
3. Не учитывается глупость создателя сервера.
4. Не учитывается в банальной математике, что пароль может быть перебран за меньшее количество итераций.
Поэтому, лучший вариант — это ключи, которые тоже могут быть скомпрометированы. Однако, если сюда добавить поиск пользователя, а не только рута, то время увеличивается на порядки.
И, то что вы не заметили, что ваш сервер взломан, ещё не говорит, о том что там никто не побывал ;).
И, спасибо, за удачу!
пароль может быть в словарях.
Рандомый пароль очень вряд ли
пароль может быть скомпрометирован
Как и ключ
ЗЫ: ключи, конечно же, удобнее. management ключей проще и надежнееё
В завершении ветки, скажу, что я использую парольный вход, потому что ключ не всегда удобно с собой таскать. Но вход по руту отключаю однозначно, это вопрос, конечно же удобства, но не вижу смысла, для себя, оставлять логин по суперпользователю.
ключ не всегда удобно с собой таскать
Точно так же, как и пароль вида geVUsge9cdj2cRG. Вы же его не запоминаете, правда? Наверное в файлик записываете, или в программу какую то?
ключ не всегда удобно с собой таскатьКлюч кладётся в KeePass и ставится плагин KeeAgent.
Не знал, что так можно. Правда, переносимые ключи вроде как противоречат идеологии ключей, они в таком случае превращаются в очень длинный пароль просто. И на сервере уже нельзя отключить вход для конкретного клиента.
переносимые ключи вроде как противоречат идеологии ключей
Можно подробнее, что это за идеология?
они в таком случае превращаются в очень длинный пароль просто
Не просто. Пароль можно попытаться подслушать с помощью MITM, фишинга, подмены DNS... Ключ (публичную часть) сниффить бесполезно - он и так общедоступен.
Кажется, тут просто столкнулись точки зрения двух веток линуксов - в Debian-based дистрибутивах, работать от рута не принято, а в Red Hat-based - (ну, по крайней мере, на момент получения мной RHCSA), работать под рутом - мэйнстрим.
Другое дело, что это провоцирует работу от рута, но это уже совсем другая тема для обсуждения.
настало время для каминг-аута: я существенную долю времени на серверах сижу под рутом.
ибо если я зашёл на сервер, то обычно я собираюсь там что-то настраивать.
не понимаю, как набор sudo перед каждой командой улучшит безопасность.
а вот на домашнем/рабочем компьютере я обычно сижу под обычным пользователем. хотя и тут рутовая консоль обычно открыта )
не понимаю, как набор sudo перед каждой командой улучшит безопасностьКогда на одной машине нужно набирать, а на другой нет, это не очень удобно, постоянно путаешься.
По поводу винды. В Windows 10 ведь уже есть встроенный ssh-клиент. Вместе с scp, и генератором ключей. И не надо устанавливать для этого никакой cygwin. Я почти перестал пользоваться putty из-за него.
Вроде как OpenSSH client по умолчанию устанавливается. В Pro`шке точно.
Я лишь недавно попробовал добавить OpenSSH на машину с Windows 7 ради серверной функции и столкнулся с тем, что свежая версия OpenSSH перестала поддерживать SCP. Теперь вместо него работает протокол SFTP.
Это не очень удобно мне, учитывая, что ряд администрируемых сетевых устройств, напротив, работают только с SCP вместо SFTP.
Usage of the SCP protocol can be restored using the newly added -O option.
Это я видел. Осталось понять, куда прописать эту опцию на коммутаторе, на который я желаю посредством SCP передать файл, находящийся на хосте с OpenSSH сервером.
In case of incompatibility, the scp(1) client may be instructed to use
the legacy scp/rcp using the -O flag.
Хотя, похоже, именно так они и поступили.
Да, OpenSSH client. Если не установлен из коробки, то ставится через компоненты. Соответственно в виндовой консоли это просто ssh, scp и так далее.
Таки да, работает как обычно и клиет и сервер. Относительно легко прикручивается всякое вроде ключей из gpg / hw токенов даже.
putty удобен тем, что это оконное приложение, со всеми фичами вроде своего значка в панели задач, быстрого доступа к последним сохранённым сессиям через этот же значок; также немаловажно что plink не открывает пустого консольного окна (почему в OpenSSH sshw.exe не сделают?)
Мне, честно говоря, очень не нравится интерфейс putty. Он какой-то програмистский в плохом смысле этого слова. Контринтуитивный, я часто ошибаюсь при работе с ним. Например, там параметры сессии собираешь по всему дереву слева, а потом надо не забыть вернуться в начало и сохранить сессию. Я тут часто прокалываюсь. Тот факт, что putty это не одна утилита, а целый набор, тоже не радует. Когда мне хочется работать с терминалом по-виндовому, я использую MobaXTerm. Вот это прям в стиле винды. Комбайн. С вкладками, файловым менеджером и ещё горой каких-то фич. Даже скринсейвер есть. Иногда мне удобнее с ним, иногда в голой консоли через OpenSSH, а putty осталась не у дел. (Хотя MobaXTerm сам использует putty).
Я одно время сидел на майкрософтовском Terminal-е, табы, настройки богатые, вот это все подкупало сильно. А последнее время открыл для себя Tabby , вот это реально помогает, очень удобная штука. До любимого маковского iterm2 конечно все равно как до луны...
Tabby выглядит прикольно, надо попробовать. Мне нравится фича, когда окно можно нарезать на отдельные терминальчики, как в линуксовом terminator.
После слов "Themes customizable with CSS" и "Extensible via plugins (in JS)" на оффсайте стало страшновато, оно на Электроне? Консоль в отдельном браузере?
Для себя давно открыл ConEmu. Крайне удобно.
Да, оно на электроне. У них даже есть демо, работающее прямо на сайте. Но я попробовал пользоваться и пока мне очень даже нравится. Только пришлось часть хоткеев поотключать в настройках, а то он много чего перехватывает и в результате я не смог работать с nano нормально.
Т.е. вас действительно не смущает тот факт что вы запускаете консоль в отдельной версии браузера??? Вы понимаете что каждая приложуха на электроне это отдельный инстанс хромиума, со всеми "вытекающими"? Извините, но, имхо, это дно. Хуже этого может быть только калькулятор на электроне, зато со скинами на css. :(
О прекрасный 21-й век. Мы выдумали webassembly для веба, чтобы он не томозил от нашего обилия JS, а потом "делаем" примитивные приложения на электроне, c обилием JS...
А что из этого вытекает? Что приложение потребляет много ресурсов? Больше чем могло бы? Так этих ресурсов у меня хватает с избытком. Или вы о каких-то более серьёзных вещах говорите, например о безопасности такого решения?
У меня браузер всё равно постоянно запущен, у него каждая вкладка процесс, плюс плагины. Ну будет у меня ещё один процесс браузера и что? Я посмотрел, в покое табби жрёт 47 МБ памяти и 0% процессора. На фоне запущенного рядом фаерфокса, который сжирает пару гигов его и не видно. Почему я должен об этом переживать?
Посоветуйте мне другой терминал, который умеет работать с сохранёнными сессиями, имеет вкладки и возможность разделять экран на терминальчики поменьше, при этом не является электрон-приложением, я попробую и его тоже. Мне без разницы как он сделан, мне надо, чтобы он мне нравился.
ConEmu (https://conemu.github.io/) умеет всё вами перечисленное и ещё кучу всего, с открытым исходным кодом. Жрёт 5,3 Мб. И не электрон :)
Опция -А позволяет пробрасывать свой ключ по цепочке, если заходить в несколько вложенных сессий. Иногда бывает нужно
Тулза sshuttle позволяет автоматически настраивать роутинг в подсеть через ноду, к которой есть доступ по ссш. Тоже нужна редко, но метко
Вместо шатла я сделал шел скрипт .
WinSCP на самом деле хорош. В него и из него можно перетаскивать мышью файлы из обычного проводника windows. Старый двухпанельный режим можно отключить, и тогда WinSCP выглядит похоже на стандартный проводник.
А почему вы запускаете VS Code из WSL, а не из Windows, хотя Microsoft рекомендует наоборот?
И как теперь в закладках отличать от той самой «Магии SSH»?
Очень не хватает возможности пробрасывать последовательные порты ttySx, ttyUSBx, ttyACMx и т.д.
эээ, а как?
запустить удаленно screen, это пожалуйста
а как сделать так чтобы на локальном компе открывался порты, доступ к которому пробрасывался к удаленному последовательному порту?
Такое нашел https://github.com/b1f6c1c4/ttyssh
Если хочется, чтобы можно было подключиться извне, то нужно на удалённом хосте тоже сделать перенаправление портов.
Можно на сервере в настройках /etc/ssh/sshd_config указать GatewayPorts clientspecified. И тогда не сервере уже не надо будет ничего перенаправлять, а можно сразу делать ssh -fCNR 0.0.0.0:5544:localhost:22 remotehost. И ssh будет слушать на всех интерфейсах сервера.
пробросить порты можно через уже открытую сессию SSH с помощью так называемых control sequences. Чтобы попасть в меню надо нажать Enter, потом ~C - появится контекстная менюшка с выбором режима и настроек форварда
Почему-то не упомянули про возможность подключиться с помощью Filezilla, указав соответствующую настройку. И можно просто и удобно перекидывать файлы туда-сюда. Конечно, ftp мало кто пользуется, и его объявили типа устаревшим, но это просто и удобно.
WinSCP делает то же самое.
ftp ещё и крайне медленный по сравнению, например, с rsync.
ssh -X лучше запускать в виде ssh -C -X — вроде помогает.
Для меня эта программа — эталон удобства, и порой даже думаю поставить её под linux, хотя это и оверкилл.
У неё есть фатальный недостаток — нет ProxyJump.
Использую 'SFTP Drive V3' для монтирования папки Linux как диска Windows. Прямо из VSCode работаю с исходниками (собираю, конечно, на Linux машине). Для абсолютно всех рабочих манипуляций с серверами юзаю либо WSL, либо Git Bash. Получается обходиться без Windows терминалов.
“Здесь я создал файл, затем скопировал его на удалённый хост (в домашнюю папку), и после, проверил его существование. Аналогично можно копировать и в обратном направлении.”
Подскажите, как красиво скопировать файл с удаленной на свою машину, если я уже нахожусь в ssh сессии, без выхода из сессии. У моей машины нет белого IP.
Поясню, иногда нужно скопировать конфиги, которые доступны только руту.Root доступа по ssh нет. Захожу под юзером, там делаю sudo а вот как файл себе утащить красиво не нашел решения.
Пока коряво копирую во временную папку , cставлю более широкие праваи утаскиваю себе.
Думаю, иначе никак, передача файлов и шелл (а также проброс портов и VPN) — это всё разные сессии внутри одного соединения, поэтому эскалация прав в шелле неприменима к передаче файлов. Разве что может сработать с кастомным клиентом и Esc-последовательностями, но это надо велосипедить. Например, в шелле выводим специальный код, распознаваемый клиентом (с указанием длины файла в нём), после чего прямо в шелл дампим содержимое файла. Клиент это всё в терминал не выводит, а показывает диалог выбора файла для сохранения, после чего вычитывает N байт, где N мы передали вместе с эскейп-кодом, сохраняет их в файл и возвращается в обычный режим работы с шеллом.
Если бы можно было монтировать под Windows удалённые папки из Linux-машин, то было бы просто великолепно. Хотя и это тоже возможно сделать без особых проблем.
Логика сломалась.
Под win 10 у меня хорошо работает https://github.com/evsar3/sshfs-win-manager инструкция там же.
Далее необходимо отключить логин пользователя root. Это очень важно, потому что, в конце концов, методом перебора сервер рано или поздно будет взломан.
Да чего же вы так все боитесь рута? Не понимаю, аргументы странные. Да, сидеть под рутом на боевом сервере, полным всякого софта и сервисов нехорошо, можно случайно что-нибудь сломать, но если это машина, на которой один раз в начале развертывается докер, и дальше все работа происходит с ним и машина создается исключительно для него — какой смысл в создании новых пользователей?
А сложность взлома от логина не зависит, разве что рута пытаются перебрать чаще, чем ваше-уникальное-имя-пользователя. Но в чем проблема просто отключить пароли и перейти на авторизацию ключами тогда?
Да, сидеть под рутом на боевом сервере, полным всякого софта и сервисов нехорошо, можно случайно что-нибудь сломать
то есть если на этом же хосте набрать sudo somebadcommand, будет лучше? )
при активном использовании sudo глаз ровно так же замыливается, даже тут на хабре я видел статьи с «просто перед каждой командой пишем sudo» в духе
sudo curl http://xxx | sudo bash
Но в чем проблема просто отключить пароли и перейти на авторизацию ключами тогда?
на самом деле и парольная авторизация достаточно надёжная, но только пока у вас контролируется сложность паролей.
единственное преимущество ключей — защита от дурака, почти невозможно создать ключ с надёжностью как у пароля 123 (хотя и тут случались проблемы, но это была уже не оплошность админа)
В принципах безопасности: каждый пользователь должен использовать свой собственный логин для работы. Таким образом в случае инцидента можно установить чья учётная запись утекла и принять меры по ее блокировке во всей инфраструктуре, например.
Это базовый принцип информационной безопасности.
А засечь утёкшую учётку что, проще чем утёкший ключ?
Нет, я понимаю если это учётка из-под которой ведётся вся работа, тогда и правда одно её название оставит в логах куда больше следов чем ключ. Но что если первой же командой после логина будет какой-нибудь sudo su -?
Вы действительно не понимаете.
Неважно как происходит аутентификация пользователя (пароль или ключ). Важно чтобы каждый имел и использовал только свой персональный аккаунт.
Линукс система содержит все необходимые средства для логирования действий пользователей и FIM. Задача решается сама собой при соблюдении условия раздельного логина.
Я запрещаю удаленный вход для root
Нет, это вы не понимаете.
Вот злоумышленник зашёл на сервер и написал sudo su - или любой аналог. Права на sudo у него есть, иначе и обсуждать нечего. Какое имя пользователя с этого момента будет логировать линукс?
Единственное, что мне в ней не нравится, что если сессия рвётся по таймауту, то приходится заново создавать подключение, а это долго и раздражает.
Обрыв соединения в WinSCP (и в putty с настройками по умолчанию) при длительном бездействии может быть как следствием настроек сервера, так и следствием очистки по таймауту таблицы NAT на маршрутизаторе.
Для решения проблемы необходимо включить посылку keepalive-пакетов в свойствах соединения. В WinSCP это вкладка "Подключение" в окне "Расширенные настройки" пункт "Поддерживать активность" ("Advanced site settings" -> "Connection" -> "Keepalives"). В putty аналогично — пункт "Отправка нулевых пакетов" ("Sending of nul packets to keep session active") на вкладке "Соединение" ("Connection")
Обязательно рекомендую проверить, что вы больше не можете зайти под рутом с тем же паролем, и эти изменения успешно применились.
После чего проверяю успешность подключения от своего аккаунта
dlinyj
Лучше наоборот :)
при вызове графических приложений со стороны серьера по опыту лучше включать сжатие: ssh -XC вместо просто ssh -X, будет заметно отзывчивее.
А насчет путти под линуксом, это идеальная штука когда надо подключиться к старому серверу, например СуСе 6.1 ;) который только SSH1 и умеет и с которого/на который файлы надо передать: pscp -1 ... вместо просто scp ...
Не помню, когда мне надо было в последний раз ssh1, но посмотрел, как минимум в debian есть openssh-client-ssh1
надо подключиться к старому серверу, например СуСе 6.1
Вы что-то путаете, заглянул в википедию, ssh2 был принят в качестве стандарта в 2006 году, к моменту выхода suse 6.1 все про ssh1 забыли.
Подозреваю, вам нужно просто просто разрешить старые алгоритмы в ssh2, например у меня так прописано для тестовой сети в /etc/ssh/ssh_config:
Host 10.89.188.*
UserKnownHostsFile /dev/null
StrictHostKeyChecking no
KexAlgorithms +diffie-hellman-group1-sha1
Магия ssh