SSH является технологией, предназначенной для удаленного исполнения команд, а также для входа через сеть на другой компьютер. Используя SSH можно загружать и копировать файлы между компьютерами, но чаще всего она используется для безопасной передачи файлов сайта между вашим компьютером и сервером хостинг-провайдера.
Secure Shell - так расшифровывается аббревиатура SSH. Благодаря использованию этой технологии достигается надежная авторизация и безопасная передача информации по открытым каналам связи. SSH успешно заменяет такие протоколы, как telnet, rlogin, rcp и rsh. Т.к. применение перечисленных технологий связано с некоторыми проблемами безопасности:
Чтобы более четко понять, как работает SSH, нам поможет наглядный пример. Для этого мы будем использовать аналогию на примере всем известного Штирлица.
Допустим Штирлицу необходимо передать в Центр важные данные, но старый шифр уже известен врагам. Что же предпринять в этой ситуации? Самым оптимальным вариантом может быть организация встречи для передачи Штирлицу нового шифра (то есть создать новый код). Однако если встреча невозможна, то остается только открытый канал связи, который могут прослушивать враги. Но и эту ситуацию можно решить.
В середине 1970-х годов учеными-математиками был разработан алгоритм RSA. Используя его, можно применять в криптографии «публичные ключи». Суть этого алгоритма состоит в том, что существует два криптоключа: один используется для зашифровки, а второй применяется для расшифровки. «Публичным ключом» называется код для зашифровки, так как он не является секретным и его можно свободно передавать. В отличии от ключей для зашифровки, ключи для расшифровки являются секретными, (ещё их называю приватными) и это значит, что расшифровать сообщение сможет только владелец этого ключа.
Действие алгоритма RSA основано на невозможности получения из публичного ключа приватного ключа, который необходим для расшифровки. Поэтому, если бы действие знаменитой киноленты «Семнадцать мгновений весны» происходило сейчас, Центру было бы достаточно отправить Штирлицу новый публичный ключ, а Мюллеру не удалось бы расшифровать их сообщения, сколько бы он не пытался.
Чтобы использовать Secure Shell-доступ достаточно скачать, а затем установить любой SSH-клиент. Специалисты советуют отдать предпочтение популярному и бесплатному клиенту Filezilla . Также существует WinSCP2 , так как это одна из наиболее эффективных программ, которая может работать по протоколу SSH2. Программа визуально похожа на достаточно известный FTP-клиент - CuteFTP , она имеет хороший графический интерфейс, а также предоставляет возможность сравнения контента каталогов. Третей в этом списке идет программа PuTTY (как настроить PuTTY), которая тоже имеет своих поклонников, на нашим экспертам понравилась меньше всего.
Для того чтобы осуществить настройку SSH-клиента, достаточно указать ваше доменное имя (или User ID), IP адрес, пароль и выбрать SHH-протокол. Другие настройки вы можете оставить по умолчанию. После того, как соединение будет установлено, сервер отправит запрос на введение пароля и имени пользователя. вам следует ввести данные, аналогичные тем, что вы используете для получения FTP-доступа (их обычно присылает хостинг-провайдер в первом письме, после создания аккаунта).
Часто бывает такое, что у хостинг-провайдера SSH-доступ является дополнительной платной услугой. Поэтому, если у вас что-то не получается настроить, то обратитесь в поддержку хостера для выяснения причин.
abstract: В статье описаны продвинутые функций OpenSSH, которые позволяют сильно упростить жизнь системным администраторам и программистам, которые не боятся шелла. В отличие от большинства руководств, которые кроме ключей и -L/D/R опций ничего не описывают, я попытался собрать все интересные фичи и удобства, которые с собой несёт ssh.
Предупреждение: пост очень объёмный, но для удобства использования я решил не резать его на части.
Оглавление:
Ключ можно закрыть паролем. Этот пароль (в обычных графических интерфейсах) спрашивается один раз и сохраняется некоторое время. Если пароль указать пустым, он спрашиваться при использовании не будет. Восстановить забытый пароль невозможно.
Сменить пароль на ключ можно с помощью команды ssh-keygen -p .
Если вы знаете пароль пользователя, то процесс можно упростить. Команда ssh-copy-id user@server позволяет скопировать ключ не редактируя файлы вручную.
Замечание: Старые руководства по ssh упоминают про authorized_keys2. Причина: была первая версия ssh, потом стала вторая (текущая), для неё сделали свой набор конфигов, всех это очень утомило, и вторая версия уже давным давно переключилась на версии без всяких «2». То есть всегда authorized_keys и не думать о разных версиях.
Если у вас ssh на нестандартном порту, то ssh-copy-id требует особого ухищрения при работе: ssh-copy-id "-p 443 user@server" (внимание на кавычки).
Если ключ сервера поменялся (например, сервер переустановили), ssh вопит от подделке ключа. Обратите внимание, если сервер не трогали, а ssh вопит, значит вы не на тот сервер ломитесь (например, в сети появился ещё один компьютер с тем же IP, особо этим страдают всякие локальные сети с 192.168.1.1, которых в мире несколько миллионов). Сценарий «злобной man in the middle атаки» маловероятен, чаще просто ошибка с IP, хотя если «всё хорошо», а ключ поменялся - это повод поднять уровень паранойи на пару уровней (а если у вас авторизация по ключу, а сервер вдруг запросил пароль - то паранойю можно включать на 100% и пароль не вводить).
Удалить известный ключ сервера можно командой ssh-keygen -R server . При этом нужно удалить ещё и ключ IP (они хранятся раздельно): ssh-keygen -R 127.0.0.1 .
Ключ сервера хранится в /etc/ssh/ssh_host_rsa_key
и /etc/ssh/ssh_host_rsa_key.pub
. Их можно:
а) скопировать со старого сервера на новый.
б) сгенерировать с помощью ssh-keygen. Пароля при этом задавать не надо (т.е. пустой). Ключ с паролем ssh-сервер использовать не сможет.
Заметим, если вы сервера клонируете (например, в виртуалках), то ssh-ключи сервера нужно обязательно перегенерировать.
Старые ключи из know_hosts при этом лучше убрать, иначе ssh будет ругаться на duplicate key.
Scp path/myfile [email protected]:/full/path/to/new/location/
Обратно тоже можно:
scp [email protected]:/full/path/to/file /path/to/put/here
Fish warning: Не смотря на то, что mc умеет делать соединение по ssh, копировать большие файлы будет очень мучительно, т.к. fish (модуль mc для работы с ssh как с виртуальной fs) работает очень медленно. 100-200кб - предел, дальше начинается испытание терпения. (Я вспомнил свою очень раннюю молодость, когда не зная про scp, я копировал ~5Гб через fish в mc, заняло это чуть больше 12 часов на FastEthernet).
Возможность копировать здорово. Но хочется так, чтобы «сохранить как» - и сразу на сервер. И чтобы в графическом режиме копировать не из специальной программы, а из любой, привычной.
Так тоже можно:
Собственно, исключение: O_DIRECT не поддерживается, увы (это проблема не sshfs, это проблема fuse вообще).
Использование: установить пакет sshfs (сам притащит за собой fuse).
Собственно, пример моего скрипта, который монтирует desunote.ru (размещающийся у меня на домашнем комьютере - с него в этой статье показываются картинки) на мой ноут:
#!/bin/bash sshfs desunote.ru:/var/www/desunote.ru/ /media/desunote.ru -o reconnect
Делаем файл +x, вызываем, идём в любое приложение, говорим сохранить и видим:
Параметры sshfs, которые могут оказаться важными: -o reconnect (говорит пытаться пересоединиться вместо ошибок).
Если вы много работаете с данными от рута, то можно (нужно) сделать idmap:
-o idmap=user . Работает она следующим образом: если мы коннектимся как пользователь pupkin@server, а локально работаем как пользователь vasiliy, то мы говорим «считать, что файлы pupkin, это файлы vasiliy». ну или «root», если мы коннектимся как root.
В моём случае idmap не нужен, так как имена пользователей (локальное и удалённое) совпадают.
Заметим, комфортно работать получается только если у нас есть ssh-ключик (см. начало статьи), если нет - авторизация по паролю выбешивает на 2-3 подключение.
Отключить обратно можно командой fusermount -u /path , однако, если соединение залипло (например, нет сети), то можно/нужно делать это из-под рута: sudo umount -f /path.
Ssh user@server ls /etc/
Выведет нам содержимое /etc/ на server, при этом у нас будет локальная командная строка.
Некоторые приложения хотят иметь управляющий терминал. Их следует запускать с опцией -t:
ssh user@server -t remove_command
Кстати, мы можем сделать что-то такого вида:
ssh user@server cat /some/file|awk "{print $2}" |local_app
Это нас приводит следующей фиче:
Ssh [email protected] command >my_file
Допустим, мы хотим локальный вывод положить удалённо
Mycommand |scp - [email protected]:/path/remote_file
Усложним пример - мы можем прокидывать файлы с сервера на сервер: Делаем цепочку, чтобы положить stdin на 10.1.1.2, который нам не доступен снаружи:
Mycommand | ssh [email protected] «scp - [email protected]:/path/to/file»
Есть и вот такой головоломный приём использования pipe"а (любезно подсказали в комментариях в жж):
Tar -c * | ssh user@server "cd && tar -x"
Tar запаковывает файлы по маске локально, пишет их в stdout, откуда их читает ssh, передаёт в stdin на удалённом сервере, где их cd игнорирует (не читает stdin), а tar - читает и распаковывает. Так сказать, scp для бедных.
В более-менее крупной компании часто оказывается, что имена серверов выглядят так: spb-MX-i3.extrt.int.company.net. И пользователь там не равен локальному. То есть логиниться надо так: ssh [email protected]. Каждый раз печатать - туннельных синдромов не напасёшься. В малых компаниях проблема обратная - никто не думает о DNS, и обращение на сервер выглядит так: ssh [email protected]. Короче, но всё равно напрягает. Ещё большая драма, если у нас есть нестандартный порт, и, например, первая версия ssh (привет цискам). Тогда всё выглядит так: ssh -1 -p 334 [email protected]. Удавиться. Про драму с scp даже рассказывать не хочется.
Можно прописать общесистемные alias"ы на IP (/etc/hosts), но это кривоватый выход (и пользователя и опции всё равно печатать). Есть путь короче.
Файл ~/.ssh/config позволяет задать параметры подключения, в том числе специальные для серверов, что самое важное, для каждого сервера своё. Вот пример конфига:
Host ric Hostname ооо-рога-и-копыта.рф User Администратор ForwardX11 yes Compression yes Host home Hostname myhome.dyndns.org User vasya PasswordAuthentication no
Все доступные для использования опции можно увидеть в man ssh_config (не путать с sshd_config).
Host * User root Compression yes
То же самое можно сделать и в /etc/ssh/ssh_config (не путать с /etc/ssh/sshd _config), но это требует прав рута и распространяется на всех пользователей.
Теория: Графические приложения в юникс обычно используют X-сервер (wayland в пути, но всё ещё не готов). Это означает, что приложение запускается и подключается к X-серверу для рисования. Иными словами, если у вас есть голый сервер без гуя и есть локальный x-сервер (в котором вы работаете), то вы можете дать возможность приложениям с сервера рисовать у вас на рабочем столе. Обычно подключение к удалённом X-серверу - не самая безопасная и тривиальная вещь. SSH позволяет упростить этот процесс и сделать его совсем безопасным. А возможность жать трафик позволяет ещё и обойтись меньшим трафиком (т.е. уменьшить утилизацию канала, то есть уменьшить ping (точнее, latency), то есть уменьшить лаги).
Ключики: -X - проброс X-сервера. -Y проброс авторизации.
Достаточно просто запомнить комбинацию ssh -XYC user@SERVER.
В примере выше (названия компании вымышленные) я подключаюсь к серверу ооо-рога-и-копыта.рф не просто так, а с целью получить доступ к windows-серверу. Безопасность microsoft при работе в сети мы все хорошо знаем , так что выставлять наружу голый RDP неуютно. Вместо этого мы подключаемся к серверу по ssh, а дальше запускаем там команду rdesktop:
ssh ric
rdesktop -k en-us 192.168.1.1 -g 1900x1200
И чудо, окошко логина в windows на нашем рабочем столе. Заметим, тщательно зашифрованное и неотличимое от обычного ssh-трафика.
Особые проблемы доставляют закрытые порты. То джаббер прикроют, то IMAP, то ещё что-нибудь.
Обычный VPN (pptp, l2tp, openvpn) в таких ситуациях не работает - его просто не пропускают. Экспериментально известно, что 443ий порт чаще всего оставляют, причём в режиме CONNECT, то есть пропускают «как есть» (обычный http могут ещё прозрачно на сквид завернуть).
Решением служит socks-proxy режим работы ssh. Его принцип: ssh-клиент подключается к серверу и слушает локально. Получив запрос, он отправляет его (через открытое соединение) на сервер, сервер устанавливает соединение согласно запросу и все данные передаёт обратно ssh-клиенту. А тот отвечает обратившемуся. Для работы нужно сказать приложениям «использовать socks-proxy». И указать IP-адрес прокси. В случае с ssh это чаще всего localhost (так вы не отдадите свой канал чужим людям).
Подключение в режиме sock-proxy выглядит так:
ssh -D 8080 user@server
В силу того, что чужие wifi чаще всего не только фиговые, но и лагливые, то бывает неплохо включить опцию -C (сжимать трафик). Получается почти что opera turbo (только картинки не жмёт). В реальном сёрфинге по http жмёт примерно в 2-3 раза (читай - если вам выпало несчастье в 64кбит, то вы будете мегабайтные страницы открывать не по две минуты, а секунд за 40. Фигово, но всё ж лучше). Но главное: никаких украденных кук и подслушанных сессий.
Я не зря сказал про закрытые порты. 22ой порт закрывают ровно так же, как «не нужный» порт джаббера. Решение - повесить сервер на 443-й порт. Снимать с 22 не стоит, иногда бывают системы с DPI (deep packet inspection), которые ваш «псевдо-ssl» не пустят.
Вот так выглядит мой конфиг:
/etc/ssh/sshd_config:
(фрагмент)
Port 22
Port 443
А вот кусок ~/.ssh/config с ноутбука, который описывает vpn
Host vpn Hostname desunote.ru User vasya Compression yes DynamicForward 127.1:8080 Port 443
(обратите внимание на «ленивую» форму записи localhost - 127.1, это вполне себе законный метод написать 127.0.0.1)
Для понимания ситуации все примеры ниже будут ссылаться на вот эту схему:
Комментарии: Две серые сети. Первая сеть напоминает типичную офисную сеть (NAT), вторая - «гейтвей», то есть сервер с белым интерфейсом и серым, смотрящим в свою собственную приватную сеть. В дальнейших рассуждениях мы полагаем, что «наш» ноутбук - А, а «сервер» - Б.
Задача : у нас локально запущено приложение, нам нужно дать возможность другому пользователю (за пределами нашей сети) посмотреть на него.
Решение: проброс локального порта (127.0.0.1:80) на публично доступный адрес. Допустим, наш «публично доступный» Б занял 80ый порт чем-то полезным, так что пробрасывать мы будем на нестандартный порт (8080).
Итоговая конфигурация: запросы на 8.8.8.8:8080 будут попадать на localhost ноутбука А.
Ssh -R 127.1:80:8.8.8.8:8080 [email protected]
Опция -R
позволяет перенаправлять с удалённого (R
emote) сервера порт на свой (локальный).
Важно: если мы хотим использовать адрес 8.8.8.8, то нам нужно разрешить GatewayPorts в настройках сервера Б.
Задача
. На сервере «Б» слушает некий демон (допустим, sql-сервер). Наше приложение не совместимо с сервером (другая битность, ОС, злой админ, запрещающий и накладывающий лимиты и т.д.). Мы хотим локально получить доступ к удалённому localhost"у.
Итоговая конфигурация: запросы на localhost:3333 на "A" должны обслуживаться демоном на localhost:3128 "Б".
Ssh -L 127.1:3333:127.1:3128 [email protected]
Опция -L позволяет локальные обращения (L ocal) направлять на удалённый сервер.
Задача : На сервере «Б» на сером интерфейсе слушает некий сервис и мы хотим дать возможность коллеге (192.168.0.3) посмотреть на это приложение.
Итоговая конфигурация: запросы на наш серый IP-адрес (192.168.0.2) попадают на серый интерфейс сервера Б.
Ssh -L 192.168.0.2:8080:10.1.1.1:80 [email protected]
Усложним задачу: теперь нам хочется показать коллеге приложение, запущенное на localhost на сервере с адресом 10.1.1.2 (на 80ом порту).
Решение сложно:
ssh -L 192.168.0.2:8080:127.1:9999 [email protected] ssh -L 127.1:9999:127.1:80 [email protected]
Что происходит? Мы говорим ssh перенаправлять локальные запросы с нашего адреса на localhost сервера Б и сразу после подключения запустить ssh (то есть клиента ssh) на сервере Б с опцией слушать на localhost и передавать запросы на сервер 10.1.1.2 (куда клиент и должен подключиться). Порт 9999 выбран произвольно, главное, чтобы совпадал в первом вызове и во втором.
Если предыдущий пример вам показался простым и очевидным, то попробуйте догадаться, что сделает этот пример:
ssh -D 8080 -R 127.1:8080:127.1:8080 [email protected] ssh -R 127.1:8080:127.1:8080 [email protected]
Если вы офицер безопасности, задача которого запретить использование интернета на сервере 10.1.1.2, то можете начинать выдёргивать волосы на попе, ибо эта команда организует доступ в интернет для сервера 10.1.1.2 посредством сокс-прокси, запущенного на компьютере «А». Трафик полностью зашифрован и неотличим от любого другого трафика SSH. А исходящий трафик с компьютера с точки зрения сети «192.168.0/24» не отличим от обычного трафика компьютера А.
(сам я увы, таким не пользовался).
Легко понять, что в таких условиях невозможно никаким DPI (deep packet inspection) отловить подобные туннели - либо ssh разрешён (читай - делай что хочешь), либо ssh запрещён (и можно смело из такой компании идиотов увольняться не ощущая ни малейшего сожаления).
OpenSSH позволяет использовать сервера в качестве плацдарма для подключения к другим серверам, даже если эти сервера недоверенные и могут злоупотреблять чем хотят.
Повторю картинку:
Допустим, мы хотим подключиться к серверу 10.1.1.2, который готов принять наш ключ. Но копировать его на 8.8.8.8 мы не хотим, ибо там проходной двор и половина людей имеет sudo и может шариться по чужим каталогам. Компромиссным вариантом было бы иметь «другой» ssh-ключ, который бы авторизовывал [email protected] на 10.1.1.2, но если мы не хотим пускать кого попало с 8.8.8.8 на 10.1.1.2, то это не вариант (тем паче, что ключ могут не только поюзать, но и скопировать себе «на чёрный день»).
Ssh предлагает возможность форварда ssh-агента (это такой сервис, который запрашивает пароль к ключу). Опция ssh -A пробрасывает авторизацию на удалённый сервер.
Вызов выглядит так:
Ssh -A [email protected] ssh [email protected]
Удалённый ssh-клиент (на 8.8.8.8) может доказать 10.1.1.2, что мы это мы только если мы к этому серверу подключены и дали ssh-клиенту доступ к своему агенту авторизации (но не ключу!).
В большинстве случаев это прокатывает.
Однако, если сервер совсем дурной, то root сервера может использовать сокет для имперсонализации, когда мы подключены.
Есть ещё более могучий метод - он превращает ssh в простой pipe (в смысле, «трубу») через которую насквозь мы осуществляем работу с удалённым сервером.
Главным достоинством этого метода является полная независимость от доверенности промежуточного сервера. Он может использовать поддельный ssh-сервер, логгировать все байты и все действия, перехватывать любые данные и подделывать их как хочет - взаимодействие идёт между «итоговым» сервером и клиентом. Если данные оконечного сервера подделаны, то подпись не сойдётся. Если данные не подделаны, то сессия устанавливается в защищённом режиме, так что перехватывать нечего.
Эту клёвую настройку я не знал, и раскопал её redrampage .
Настройка завязана на две возможности ssh: опцию -W (превращающую ssh в «трубу») и опцию конфига ProxyCommand (опции командной строки, вроде бы нет), которая говорит «запустить программу и присосаться к её stdin/out». Опции эти появились недавно, так что пользователи centos в пролёте.
Выглядит это так (циферки для картинки выше):
Ssh/config:
Host raep
HostName 10.1.1.2
User user2
ProxyCommand ssh -W %h:%p [email protected]
Ну а подключение тривиально: ssh raep .
Повторю важную мысль: сервер 8.8.8.8 не может перехватить или подделать трафик, воспользоваться агентом авторизации пользователя или иным образом изменить трафик. Запретить - да, может. Но если разрешил - пропустит через себя без расшифровки или модификации. Для работы конфигурации нужно иметь свой открытый ключ в authorized_keys как для [email protected], так и в [email protected]
Разумеется, подключение можно оснащать всеми прочими фенечками - прокидыванием портов, копированием файлов, сокс-прокси, L2-туннелями, туннелированием X-сервера и т.д.
туннелирование ssh
Добавить метки
1. Общая информация
SSH (Secure SHell) — сетевой протокол, позволяющий соединяться с удалённым сервером и выполнять на нём команды, загружать файлы и создавать туннелирование TCP-соединений. Ключевой особенностью является шифрование передаваемой информации. По умолчанию на хостинге используется командный интерпретатор bash .
2. Информация для подключения
Информацию для подключения к серверу по SSH и SFTP вы можете получить в разделе «Веб-сервер»
— «Управление доступом»
— «SSH»
панели управления (https://www.r01.ru , раздел «Для клиентов»).
Чтобы соединиться по SSH с сервером хостинга, установите на компьютер ssh-клиент.
Для загрузки файлов на хостинг используйте SFTP-клиент.
3. Работа с хостингом с помощью Midnight Commander.
Midnight Commander — двухпанельный файловый менеджер. Имеет встроенный текстовый редактор.
Для запуска Midnight Commander подключитесь к хостингу по SSH и введите команду
Основные горячие клавиши:
4. Работа с хостингом из командной строки
4.1. Получение справочной информации
Для получения справочной информации по интересующей команде command наберите в командной строке:
для завершения работы со справкой нажмите «q».
Краткую справку по команде обычно можно получить, запустив ее с параметром --help или -h:
4.2. Перемещение по файловой системе
Вывести текущий каталог:
Перейти в домашний каталог пользователя:
Перейти в каталог tmp, размещенный в текущем каталоге:
Перейти в каталог по полному пути /home/login/sitename.ru/docs (корневой каталог сайта sitename.ru):
cd /home/login/sitename.ru/docs
Перейти в родительский каталог (на уровень выше):
Перейти в предыдущий каталог:
4.3. Просмотр содержимого каталога
Вывести содержимое текущего каталога (кроме скрытых файлов):
Вывести все содержимое текущего каталога с подробной информацией:
Вывести все содержимое каталога tmp с подробной информацией:
Вывести размер каталога tmp:
4.4. Создание и удаление файлов и каталогов
Создать новый каталог foo в текущем каталоге:
Создать структуру каталогов foo/bar/baz в текущем каталоге:
mkdir -p foo/bar/baz
Удалить каталог foo в текущем каталоге. Каталог должен быть пуст:
Удалить каталог foo со всеми файлами и подкаталогами:
Создать пустой файл foo:
Удалить файл foo:
4.5. Просмотр и редактирование содержимого файлов
Просмотреть содержимое текстового файла (лог-файла сайта) (Для выхода нажмите «q»):
less sitename.ru/logs/access_log
Открыть файл foo в текстовом редакторе:
4.6. Копирование и перемещение файлов
Копировать файл foo в файл bar:
Скопировать содержимое каталога old в каталог new:
Переименовать файл foo в файл bar:
Переместить файл foo в существующий каталог bar под именем baz:
4.7. Изменение прав доступа
Сделать файл foo исполняемым:
Сделать файл foo доступным только для чтения:
Изменение прав доступа для всех каталогов, вложенных в каталог foo на 755:
find foo -type d -exec chmod 755 {} \;
Изменение прав доступа для всех вложенных в каталог foo файлов на 644:
find foo -type f -exec chmod 644 {} \;
4.8. Управление процессами
Показать информацию о процессах в реальном времени (Для выхода нажмите «q»):
Показать подробную информацию о всех выполняющихся процессах:
Завершить работу процесса по его идентификатору процесса (PID) 1234:
Завершить работу процесса по его имени:
Перезапустить веб-сервер Apache:
~/etc/rc.d/httpd restart
Перезапустить веб-сервер Nginx:
~/etc/rc.d/nginx restart
4.9. Работа с архивами
Создать архив каталога docs:
tar -czf archive.tar.gz docs
Распаковать архив archive.tar.gz:
tar -xzf archive.tgz
Распаковать архив archive.zip:
unzip archive.zip
Распаковать архив archive.rar:
unrar x archive.rar
Распаковать архив archive.gz:
gunzip archive.gz
4.10. Поиск файлов
Найти среди файлов сайта содержащие текст «login.mysql» (адрес сервера для доступа к базе данных):
grep -R "login.mysql" sitename.ru/docs
Найти в текущем каталоге и подкаталогах файлы с именем index.php.
abstract: В статье описаны продвинутые функций OpenSSH, которые позволяют сильно упростить жизнь системным администраторам и программистам, которые не боятся шелла. В отличие от большинства руководств, которые кроме ключей и -L/D/R опций ничего не описывают, я попытался собрать все интересные фичи и удобства, которые с собой несёт ssh.
Предупреждение: пост очень объёмный, но для удобства использования я решил не резать его на части.
Оглавление:
Ключ можно закрыть паролем. Этот пароль (в обычных графических интерфейсах) спрашивается один раз и сохраняется некоторое время. Если пароль указать пустым, он спрашиваться при использовании не будет. Восстановить забытый пароль невозможно.
Сменить пароль на ключ можно с помощью команды ssh-keygen -p .
Если вы знаете пароль пользователя, то процесс можно упростить. Команда ssh-copy-id user@server позволяет скопировать ключ не редактируя файлы вручную.
Замечание: Старые руководства по ssh упоминают про authorized_keys2. Причина: была первая версия ssh, потом стала вторая (текущая), для неё сделали свой набор конфигов, всех это очень утомило, и вторая версия уже давным давно переключилась на версии без всяких «2». То есть всегда authorized_keys и не думать о разных версиях.
Если у вас ssh на нестандартном порту, то ssh-copy-id требует особого ухищрения при работе: ssh-copy-id "-p 443 user@server" (внимание на кавычки).
Если ключ сервера поменялся (например, сервер переустановили), ssh вопит от подделке ключа. Обратите внимание, если сервер не трогали, а ssh вопит, значит вы не на тот сервер ломитесь (например, в сети появился ещё один компьютер с тем же IP, особо этим страдают всякие локальные сети с 192.168.1.1, которых в мире несколько миллионов). Сценарий «злобной man in the middle атаки» маловероятен, чаще просто ошибка с IP, хотя если «всё хорошо», а ключ поменялся - это повод поднять уровень паранойи на пару уровней (а если у вас авторизация по ключу, а сервер вдруг запросил пароль - то паранойю можно включать на 100% и пароль не вводить).
Удалить известный ключ сервера можно командой ssh-keygen -R server . При этом нужно удалить ещё и ключ IP (они хранятся раздельно): ssh-keygen -R 127.0.0.1 .
Ключ сервера хранится в /etc/ssh/ssh_host_rsa_key
и /etc/ssh/ssh_host_rsa_key.pub
. Их можно:
а) скопировать со старого сервера на новый.
б) сгенерировать с помощью ssh-keygen. Пароля при этом задавать не надо (т.е. пустой). Ключ с паролем ssh-сервер использовать не сможет.
Заметим, если вы сервера клонируете (например, в виртуалках), то ssh-ключи сервера нужно обязательно перегенерировать.
Старые ключи из know_hosts при этом лучше убрать, иначе ssh будет ругаться на duplicate key.
Scp path/myfile [email protected]:/full/path/to/new/location/
Обратно тоже можно:
scp [email protected]:/full/path/to/file /path/to/put/here
Fish warning: Не смотря на то, что mc умеет делать соединение по ssh, копировать большие файлы будет очень мучительно, т.к. fish (модуль mc для работы с ssh как с виртуальной fs) работает очень медленно. 100-200кб - предел, дальше начинается испытание терпения. (Я вспомнил свою очень раннюю молодость, когда не зная про scp, я копировал ~5Гб через fish в mc, заняло это чуть больше 12 часов на FastEthernet).
Возможность копировать здорово. Но хочется так, чтобы «сохранить как» - и сразу на сервер. И чтобы в графическом режиме копировать не из специальной программы, а из любой, привычной.
Так тоже можно:
Собственно, исключение: O_DIRECT не поддерживается, увы (это проблема не sshfs, это проблема fuse вообще).
Использование: установить пакет sshfs (сам притащит за собой fuse).
Собственно, пример моего скрипта, который монтирует desunote.ru (размещающийся у меня на домашнем комьютере - с него в этой статье показываются картинки) на мой ноут:
#!/bin/bash sshfs desunote.ru:/var/www/desunote.ru/ /media/desunote.ru -o reconnect
Делаем файл +x, вызываем, идём в любое приложение, говорим сохранить и видим:
Параметры sshfs, которые могут оказаться важными: -o reconnect (говорит пытаться пересоединиться вместо ошибок).
Если вы много работаете с данными от рута, то можно (нужно) сделать idmap:
-o idmap=user . Работает она следующим образом: если мы коннектимся как пользователь pupkin@server, а локально работаем как пользователь vasiliy, то мы говорим «считать, что файлы pupkin, это файлы vasiliy». ну или «root», если мы коннектимся как root.
В моём случае idmap не нужен, так как имена пользователей (локальное и удалённое) совпадают.
Заметим, комфортно работать получается только если у нас есть ssh-ключик (см. начало статьи), если нет - авторизация по паролю выбешивает на 2-3 подключение.
Отключить обратно можно командой fusermount -u /path , однако, если соединение залипло (например, нет сети), то можно/нужно делать это из-под рута: sudo umount -f /path.
Ssh user@server ls /etc/
Выведет нам содержимое /etc/ на server, при этом у нас будет локальная командная строка.
Некоторые приложения хотят иметь управляющий терминал. Их следует запускать с опцией -t:
ssh user@server -t remove_command
Кстати, мы можем сделать что-то такого вида:
ssh user@server cat /some/file|awk "{print $2}" |local_app
Это нас приводит следующей фиче:
Ssh [email protected] command >my_file
Допустим, мы хотим локальный вывод положить удалённо
Mycommand |scp - [email protected]:/path/remote_file
Усложним пример - мы можем прокидывать файлы с сервера на сервер: Делаем цепочку, чтобы положить stdin на 10.1.1.2, который нам не доступен снаружи:
Mycommand | ssh [email protected] «scp - [email protected]:/path/to/file»
Есть и вот такой головоломный приём использования pipe"а (любезно подсказали в комментариях в жж):
Tar -c * | ssh user@server "cd && tar -x"
Tar запаковывает файлы по маске локально, пишет их в stdout, откуда их читает ssh, передаёт в stdin на удалённом сервере, где их cd игнорирует (не читает stdin), а tar - читает и распаковывает. Так сказать, scp для бедных.
В более-менее крупной компании часто оказывается, что имена серверов выглядят так: spb-MX-i3.extrt.int.company.net. И пользователь там не равен локальному. То есть логиниться надо так: ssh [email protected]. Каждый раз печатать - туннельных синдромов не напасёшься. В малых компаниях проблема обратная - никто не думает о DNS, и обращение на сервер выглядит так: ssh [email protected]. Короче, но всё равно напрягает. Ещё большая драма, если у нас есть нестандартный порт, и, например, первая версия ssh (привет цискам). Тогда всё выглядит так: ssh -1 -p 334 [email protected]. Удавиться. Про драму с scp даже рассказывать не хочется.
Можно прописать общесистемные alias"ы на IP (/etc/hosts), но это кривоватый выход (и пользователя и опции всё равно печатать). Есть путь короче.
Файл ~/.ssh/config позволяет задать параметры подключения, в том числе специальные для серверов, что самое важное, для каждого сервера своё. Вот пример конфига:
Host ric Hostname ооо-рога-и-копыта.рф User Администратор ForwardX11 yes Compression yes Host home Hostname myhome.dyndns.org User vasya PasswordAuthentication no
Все доступные для использования опции можно увидеть в man ssh_config (не путать с sshd_config).
Host * User root Compression yes
То же самое можно сделать и в /etc/ssh/ssh_config (не путать с /etc/ssh/sshd _config), но это требует прав рута и распространяется на всех пользователей.
Теория: Графические приложения в юникс обычно используют X-сервер (wayland в пути, но всё ещё не готов). Это означает, что приложение запускается и подключается к X-серверу для рисования. Иными словами, если у вас есть голый сервер без гуя и есть локальный x-сервер (в котором вы работаете), то вы можете дать возможность приложениям с сервера рисовать у вас на рабочем столе. Обычно подключение к удалённом X-серверу - не самая безопасная и тривиальная вещь. SSH позволяет упростить этот процесс и сделать его совсем безопасным. А возможность жать трафик позволяет ещё и обойтись меньшим трафиком (т.е. уменьшить утилизацию канала, то есть уменьшить ping (точнее, latency), то есть уменьшить лаги).
Ключики: -X - проброс X-сервера. -Y проброс авторизации.
Достаточно просто запомнить комбинацию ssh -XYC user@SERVER.
В примере выше (названия компании вымышленные) я подключаюсь к серверу ооо-рога-и-копыта.рф не просто так, а с целью получить доступ к windows-серверу. Безопасность microsoft при работе в сети мы все хорошо знаем , так что выставлять наружу голый RDP неуютно. Вместо этого мы подключаемся к серверу по ssh, а дальше запускаем там команду rdesktop:
ssh ric
rdesktop -k en-us 192.168.1.1 -g 1900x1200
И чудо, окошко логина в windows на нашем рабочем столе. Заметим, тщательно зашифрованное и неотличимое от обычного ssh-трафика.
Особые проблемы доставляют закрытые порты. То джаббер прикроют, то IMAP, то ещё что-нибудь.
Обычный VPN (pptp, l2tp, openvpn) в таких ситуациях не работает - его просто не пропускают. Экспериментально известно, что 443ий порт чаще всего оставляют, причём в режиме CONNECT, то есть пропускают «как есть» (обычный http могут ещё прозрачно на сквид завернуть).
Решением служит socks-proxy режим работы ssh. Его принцип: ssh-клиент подключается к серверу и слушает локально. Получив запрос, он отправляет его (через открытое соединение) на сервер, сервер устанавливает соединение согласно запросу и все данные передаёт обратно ssh-клиенту. А тот отвечает обратившемуся. Для работы нужно сказать приложениям «использовать socks-proxy». И указать IP-адрес прокси. В случае с ssh это чаще всего localhost (так вы не отдадите свой канал чужим людям).
Подключение в режиме sock-proxy выглядит так:
ssh -D 8080 user@server
В силу того, что чужие wifi чаще всего не только фиговые, но и лагливые, то бывает неплохо включить опцию -C (сжимать трафик). Получается почти что opera turbo (только картинки не жмёт). В реальном сёрфинге по http жмёт примерно в 2-3 раза (читай - если вам выпало несчастье в 64кбит, то вы будете мегабайтные страницы открывать не по две минуты, а секунд за 40. Фигово, но всё ж лучше). Но главное: никаких украденных кук и подслушанных сессий.
Я не зря сказал про закрытые порты. 22ой порт закрывают ровно так же, как «не нужный» порт джаббера. Решение - повесить сервер на 443-й порт. Снимать с 22 не стоит, иногда бывают системы с DPI (deep packet inspection), которые ваш «псевдо-ssl» не пустят.
Вот так выглядит мой конфиг:
/etc/ssh/sshd_config:
(фрагмент)
Port 22
Port 443
А вот кусок ~/.ssh/config с ноутбука, который описывает vpn
Host vpn Hostname desunote.ru User vasya Compression yes DynamicForward 127.1:8080 Port 443
(обратите внимание на «ленивую» форму записи localhost - 127.1, это вполне себе законный метод написать 127.0.0.1)
Для понимания ситуации все примеры ниже будут ссылаться на вот эту схему:
Комментарии: Две серые сети. Первая сеть напоминает типичную офисную сеть (NAT), вторая - «гейтвей», то есть сервер с белым интерфейсом и серым, смотрящим в свою собственную приватную сеть. В дальнейших рассуждениях мы полагаем, что «наш» ноутбук - А, а «сервер» - Б.
Задача : у нас локально запущено приложение, нам нужно дать возможность другому пользователю (за пределами нашей сети) посмотреть на него.
Решение: проброс локального порта (127.0.0.1:80) на публично доступный адрес. Допустим, наш «публично доступный» Б занял 80ый порт чем-то полезным, так что пробрасывать мы будем на нестандартный порт (8080).
Итоговая конфигурация: запросы на 8.8.8.8:8080 будут попадать на localhost ноутбука А.
Ssh -R 127.1:80:8.8.8.8:8080 [email protected]
Опция -R
позволяет перенаправлять с удалённого (R
emote) сервера порт на свой (локальный).
Важно: если мы хотим использовать адрес 8.8.8.8, то нам нужно разрешить GatewayPorts в настройках сервера Б.
Задача
. На сервере «Б» слушает некий демон (допустим, sql-сервер). Наше приложение не совместимо с сервером (другая битность, ОС, злой админ, запрещающий и накладывающий лимиты и т.д.). Мы хотим локально получить доступ к удалённому localhost"у.
Итоговая конфигурация: запросы на localhost:3333 на "A" должны обслуживаться демоном на localhost:3128 "Б".
Ssh -L 127.1:3333:127.1:3128 [email protected]
Опция -L позволяет локальные обращения (L ocal) направлять на удалённый сервер.
Задача : На сервере «Б» на сером интерфейсе слушает некий сервис и мы хотим дать возможность коллеге (192.168.0.3) посмотреть на это приложение.
Итоговая конфигурация: запросы на наш серый IP-адрес (192.168.0.2) попадают на серый интерфейс сервера Б.
Ssh -L 192.168.0.2:8080:10.1.1.1:80 [email protected]
Усложним задачу: теперь нам хочется показать коллеге приложение, запущенное на localhost на сервере с адресом 10.1.1.2 (на 80ом порту).
Решение сложно:
ssh -L 192.168.0.2:8080:127.1:9999 [email protected] ssh -L 127.1:9999:127.1:80 [email protected]
Что происходит? Мы говорим ssh перенаправлять локальные запросы с нашего адреса на localhost сервера Б и сразу после подключения запустить ssh (то есть клиента ssh) на сервере Б с опцией слушать на localhost и передавать запросы на сервер 10.1.1.2 (куда клиент и должен подключиться). Порт 9999 выбран произвольно, главное, чтобы совпадал в первом вызове и во втором.
Если предыдущий пример вам показался простым и очевидным, то попробуйте догадаться, что сделает этот пример:
ssh -D 8080 -R 127.1:8080:127.1:8080 [email protected] ssh -R 127.1:8080:127.1:8080 [email protected]
Если вы офицер безопасности, задача которого запретить использование интернета на сервере 10.1.1.2, то можете начинать выдёргивать волосы на попе, ибо эта команда организует доступ в интернет для сервера 10.1.1.2 посредством сокс-прокси, запущенного на компьютере «А». Трафик полностью зашифрован и неотличим от любого другого трафика SSH. А исходящий трафик с компьютера с точки зрения сети «192.168.0/24» не отличим от обычного трафика компьютера А.
(сам я увы, таким не пользовался).
Легко понять, что в таких условиях невозможно никаким DPI (deep packet inspection) отловить подобные туннели - либо ssh разрешён (читай - делай что хочешь), либо ssh запрещён (и можно смело из такой компании идиотов увольняться не ощущая ни малейшего сожаления).
OpenSSH позволяет использовать сервера в качестве плацдарма для подключения к другим серверам, даже если эти сервера недоверенные и могут злоупотреблять чем хотят.
Повторю картинку:
Допустим, мы хотим подключиться к серверу 10.1.1.2, который готов принять наш ключ. Но копировать его на 8.8.8.8 мы не хотим, ибо там проходной двор и половина людей имеет sudo и может шариться по чужим каталогам. Компромиссным вариантом было бы иметь «другой» ssh-ключ, который бы авторизовывал [email protected] на 10.1.1.2, но если мы не хотим пускать кого попало с 8.8.8.8 на 10.1.1.2, то это не вариант (тем паче, что ключ могут не только поюзать, но и скопировать себе «на чёрный день»).
Ssh предлагает возможность форварда ssh-агента (это такой сервис, который запрашивает пароль к ключу). Опция ssh -A пробрасывает авторизацию на удалённый сервер.
Вызов выглядит так:
Ssh -A [email protected] ssh [email protected]
Удалённый ssh-клиент (на 8.8.8.8) может доказать 10.1.1.2, что мы это мы только если мы к этому серверу подключены и дали ssh-клиенту доступ к своему агенту авторизации (но не ключу!).
В большинстве случаев это прокатывает.
Однако, если сервер совсем дурной, то root сервера может использовать сокет для имперсонализации, когда мы подключены.
Есть ещё более могучий метод - он превращает ssh в простой pipe (в смысле, «трубу») через которую насквозь мы осуществляем работу с удалённым сервером.
Главным достоинством этого метода является полная независимость от доверенности промежуточного сервера. Он может использовать поддельный ssh-сервер, логгировать все байты и все действия, перехватывать любые данные и подделывать их как хочет - взаимодействие идёт между «итоговым» сервером и клиентом. Если данные оконечного сервера подделаны, то подпись не сойдётся. Если данные не подделаны, то сессия устанавливается в защищённом режиме, так что перехватывать нечего.
Эту клёвую настройку я не знал, и раскопал её .
Настройка завязана на две возможности ssh: опцию -W (превращающую ssh в «трубу») и опцию конфига ProxyCommand (опции командной строки, вроде бы нет), которая говорит «запустить программу и присосаться к её stdin/out». Опции эти появились недавно, так что пользователи centos в пролёте.
Выглядит это так (циферки для картинки выше):
Ssh/config:
Host raep
HostName 10.1.1.2
User user2
ProxyCommand ssh -W %h:%p [email protected]
Ну а подключение тривиально: ssh raep .
Повторю важную мысль: сервер 8.8.8.8 не может перехватить или подделать трафик, воспользоваться агентом авторизации пользователя или иным образом изменить трафик. Запретить - да, может. Но если разрешил - пропустит через себя без расшифровки или модификации. Для работы конфигурации нужно иметь свой открытый ключ в authorized_keys как для [email protected], так и в [email protected]
Разумеется, подключение можно оснащать всеми прочими фенечками - прокидыванием портов, копированием файлов, сокс-прокси, L2-туннелями, туннелированием X-сервера и т.д.
туннелирование ssh
Добавить метки
