Пользователь
18,8
рейтинг
30 июля 2012 в 19:55

Администрирование → Памятка пользователям ssh

abstract: В статье описаны продвинутые функций OpenSSH, которые позволяют сильно упростить жизнь системным администраторам и программистам, которые не боятся шелла. В отличие от большинства руководств, которые кроме ключей и -L/D/R опций ничего не описывают, я попытался собрать все интересные фичи и удобства, которые с собой несёт ssh.

Предупреждение: пост очень объёмный, но для удобства использования я решил не резать его на части.

Оглавление:
  • управление ключами
  • копирование файлов через ssh
  • Проброс потоков ввода/вывода
  • Монтирование удалённой FS через ssh
  • Удалённое исполнение кода
  • Алиасы и опции для подключений в .ssh/config
  • Опции по-умолчанию
  • Проброс X-сервера
  • ssh в качестве socks-proxy
  • Проброс портов — прямой и обратный
  • Реверс-сокс-прокси
  • туннелирование L2/L3 трафика
  • Проброс агента авторизации
  • Туннелирование ssh через ssh сквозь недоверенный сервер (с большой вероятностью вы этого не знаете)

Управление ключами


Теория в нескольких словах: ssh может авторизоваться не по паролю, а по ключу. Ключ состоит из открытой и закрытой части. Открытая кладётся в домашний каталог пользователя, «которым» заходят на сервер, закрытая — в домашний каталог пользователя, который идёт на удалённый сервер. Половинки сравниваются (я утрирую) и если всё ок — пускают. Важно: авторизуется не только клиент на сервере, но и сервер по отношению к клиенту (то есть у сервера есть свой собственный ключ). Главной особенностью ключа по сравнению с паролем является то, что его нельзя «украсть», взломав сервер — ключ не передаётся с клиента на сервер, а во время авторизации клиент доказывает серверу, что владеет ключом (та самая криптографическая магия).

Генерация ключа


Свой ключ можно сгенерировать с помощью команды ssh-keygen. Если не задать параметры, то он сохранит всё так, как надо.

Ключ можно закрыть паролем. Этот пароль (в обычных графических интерфейсах) спрашивается один раз и сохраняется некоторое время. Если пароль указать пустым, он спрашиваться при использовании не будет. Восстановить забытый пароль невозможно.

Сменить пароль на ключ можно с помощью команды ssh-keygen -p.

Структура ключа


(если на вопрос про расположение ответили по-умолчанию).
~/.ssh/id_rsa.pub — открытый ключ. Его копируют на сервера, куда нужно получить доступ.
~/.ssh/id_rsa — закрытый ключ. Его нельзя никому показывать. Если вы в письмо/чат скопипастите его вместо pub, то нужно генерировать новый ключ. (Я не шучу, примерно 10% людей, которых просишь дать ssh-ключ постят id_rsa, причём из этих десяти процентов мужского пола 100%).

Копирование ключа на сервер


В каталоге пользователя, под которым вы хотите зайти, если создать файл ~/.ssh/authorized_keys и положить туда открытый ключ, то можно будет заходить без пароля. Обратите внимание, права на файл не должны давать возможность писать в этот файл посторонним пользователям, иначе ssh его не примет. В ключе последнее поле — user@machine. Оно не имеет никакого отношения к авторизации и служит только для удобства определения где чей ключ. Заметим, это поле может быть поменяно (или даже удалено) без нарушения структуры ключа.

Если вы знаете пароль пользователя, то процесс можно упростить. Команда 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/known_hosts. Узнать, где какой ключ нельзя (ибо несекьюрно).

Если ключ сервера поменялся (например, сервер переустановили), 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.


Копирование файлов


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

scp path/myfile user@8.8.8.8:/full/path/to/new/location/


Обратно тоже можно:
scp user@8.8.8.8:/full/path/to/file /path/to/put/here


Fish warning: Не смотря на то, что mc умеет делать соединение по ssh, копировать большие файлы будет очень мучительно, т.к. fish (модуль mc для работы с ssh как с виртуальной fs) работает очень медленно. 100-200кб — предел, дальше начинается испытание терпения. (Я вспомнил свою очень раннюю молодость, когда не зная про scp, я копировал ~5Гб через fish в mc, заняло это чуть больше 12 часов на FastEthernet).

Возможность копировать здорово. Но хочется так, чтобы «сохранить как» — и сразу на сервер. И чтобы в графическом режиме копировать не из специальной программы, а из любой, привычной.

Так тоже можно:

sshfs


Теория: модуль fuse позволяет «экспортировать» запросы к файловой системе из ядра обратно в userspace к соответствующей программе. Это позволяет легко реализовывать «псевдофайловые системы». Например, мы можем предоставить доступ к удалённой файловой системе через ssh так, что все локальные приложения (за малым исключением) не будут ничего подозревать.

Собственно, исключение: 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 может выполнить команду на удалённом сервере и тут же закрыть соединение. Простейший пример:

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


Это нас приводит следующей фиче:

Проброс stdin/out


Допустим, мы хотим сделать запрос к программе удалённо, а потом её вывод поместить в локальный файл

ssh user@8.8.8.8 command >my_file

Допустим, мы хотим локальный вывод положить удалённо

mycommand |scp — user@8.8.8.8:/path/remote_file

Усложним пример — мы можем прокидывать файлы с сервера на сервер: Делаем цепочку, чтобы положить stdin на 10.1.1.2, который нам не доступен снаружи:

mycommand | ssh user@8.8.8.8 «scp — user@10.1.1.2:/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 ivanov_i@spb-MX-i3.extrt.int.company.net. Каждый раз печатать — туннельных синдромов не напасёшься. В малых компаниях проблема обратная — никто не думает о DNS, и обращение на сервер выглядит так: ssh root@192.168.1.4. Короче, но всё равно напрягает. Ещё большая драма, если у нас есть нестандартный порт, и, например, первая версия ssh (привет цискам). Тогда всё выглядит так: ssh -1 -p 334 vv_pupkin@spb-MX-i4.extrt.int.company.net. Удавиться. Про драму с 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).


Опции по умолчанию


По подсказке UUSER: вы можете указать настройки соединения по умолчанию с помощью конструкции Host *, т.е., например:

Host *
User root
Compression yes


То же самое можно сделать и в /etc/ssh/ssh_config (не путать с /etc/ssh/sshd_config), но это требует прав рута и распространяется на всех пользователей.




Проброс X-сервера


Собственно, немножко я проспойлерил эту часть в примере конфига выше. ForwardX11 — это как раз оно.

Теория: Графические приложения в юникс обычно используют 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-трафика.




Socks-proxy


Когда я оказываюсь в очередной гостинице (кафе, конференции), то местный wifi чаще всего оказывается ужасным — закрытые порты, неизвестно какой уровень безопасности. Да и доверия к чужим точкам доступа не особо много (это не паранойя, я вполне наблюдал как уводят пароли и куки с помощью банального ноутбука, раздающего 3G всем желающим с названием близлежащей кафешки (и пишущего интересное в процессе)).

Особые проблемы доставляют закрытые порты. То джаббер прикроют, то 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)



Проброс портов


Мы переходим к крайне сложной для понимания части функционала SSH, позволяющей осуществлять головоломные операции по туннелированию TCP «из сервера» и «на сервер».

Для понимания ситуации все примеры ниже будут ссылаться на вот эту схему:



Комментарии: Две серые сети. Первая сеть напоминает типичную офисную сеть (NAT), вторая — «гейтвей», то есть сервер с белым интерфейсом и серым, смотрящим в свою собственную приватную сеть. В дальнейших рассуждениях мы полагаем, что «наш» ноутбук — А, а «сервер» — Б.

Задача: у нас локально запущено приложение, нам нужно дать возможность другому пользователю (за пределами нашей сети) посмотреть на него.

Решение: проброс локального порта (127.0.0.1:80) на публично доступный адрес. Допустим, наш «публично доступный» Б занял 80ый порт чем-то полезным, так что пробрасывать мы будем на нестандартный порт (8080).

Итоговая конфигурация: запросы на 8.8.8.8:8080 будут попадать на localhost ноутбука А.

ssh -R 127.1:80:8.8.8.8:8080 user@8.8.8.8


Опция -R позволяет перенаправлять с удалённого (Remote) сервера порт на свой (локальный).
Важно: если мы хотим использовать адрес 8.8.8.8, то нам нужно разрешить GatewayPorts в настройках сервера Б.
Задача. На сервере «Б» слушает некий демон (допустим, sql-сервер). Наше приложение не совместимо с сервером (другая битность, ОС, злой админ, запрещающий и накладывающий лимиты и т.д.). Мы хотим локально получить доступ к удалённому localhost'у.

Итоговая конфигурация: запросы на localhost:3333 на 'A' должны обслуживаться демоном на localhost:3128 'Б'.

ssh -L 127.1:3333:127.1:3128 user@8.8.8.8


Опция -L позволяет локальные обращения (Local) направлять на удалённый сервер.

Задача: На сервере «Б» на сером интерфейсе слушает некий сервис и мы хотим дать возможность коллеге (192.168.0.3) посмотреть на это приложение.

Итоговая конфигурация: запросы на наш серый IP-адрес (192.168.0.2) попадают на серый интерфейс сервера Б.

ssh -L 192.168.0.2:8080:10.1.1.1:80 user@8.8.8.8


Вложенные туннели


Разумеется, туннели можно перенаправлять.

Усложним задачу: теперь нам хочется показать коллеге приложение, запущенное на localhost на сервере с адресом 10.1.1.2 (на 80ом порту).

Решение сложно:
ssh -L 192.168.0.2:8080:127.1:9999 user@8.8.8.8 ssh -L 127.1:9999:127.1:80 user2@10.1.1.2


Что происходит? Мы говорим ssh перенаправлять локальные запросы с нашего адреса на localhost сервера Б и сразу после подключения запустить ssh (то есть клиента ssh) на сервере Б с опцией слушать на localhost и передавать запросы на сервер 10.1.1.2 (куда клиент и должен подключиться). Порт 9999 выбран произвольно, главное, чтобы совпадал в первом вызове и во втором.

Реверс-сокс-прокси



Если предыдущий пример вам показался простым и очевидным, то попробуйте догадаться, что сделает этот пример:
ssh -D 8080 -R 127.1:8080:127.1:8080 user@8.8.8.8 ssh -R 127.1:8080:127.1:8080 user@10.1.1.2

Если вы офицер безопасности, задача которого запретить использование интернета на сервере 10.1.1.2, то можете начинать выдёргивать волосы на попе, ибо эта команда организует доступ в интернет для сервера 10.1.1.2 посредством сокс-прокси, запущенного на компьютере «А». Трафик полностью зашифрован и неотличим от любого другого трафика SSH. А исходящий трафик с компьютера с точки зрения сети «192.168.0/24» не отличим от обычного трафика компьютера А.


Туннелирование


Если к этому моменту попа отдела безопасности не сияет лысиной, а ssh всё ещё не внесён в список врагов безопасности номер один, вот вам окончательный убийца всего и вся: туннелирование IP или даже ethernet. В самых радикальных случаях это позволяет туннелировать dhcp, заниматься удалённым arp-спуфингом, делать wake up on lan и прочие безобразия второго уровня.

Подробнее описано тут: www.khanh.net/blog/archives/51-using-openSSH-as-a-layer-2-ethernet-bridge-VPN.html

(сам я увы, таким не пользовался).

Легко понять, что в таких условиях невозможно никаким DPI (deep packet inspection) отловить подобные туннели — либо ssh разрешён (читай — делай что хочешь), либо ssh запрещён (и можно смело из такой компании идиотов увольняться не ощущая ни малейшего сожаления).

Проброс авторизации


Если вы думаете, что на этом всё, то…… впрочем, в отличие от автора, у которого «снизу» ещё не написано, читатель заранее видит, что там снизу много букв и интриги не получается.

OpenSSH позволяет использовать сервера в качестве плацдарма для подключения к другим серверам, даже если эти сервера недоверенные и могут злоупотреблять чем хотят.

Для начала о простом пробросе авторизации.

Повторю картинку:



Допустим, мы хотим подключиться к серверу 10.1.1.2, который готов принять наш ключ. Но копировать его на 8.8.8.8 мы не хотим, ибо там проходной двор и половина людей имеет sudo и может шариться по чужим каталогам. Компромиссным вариантом было бы иметь «другой» ssh-ключ, который бы авторизовывал user@8.8.8.8 на 10.1.1.2, но если мы не хотим пускать кого попало с 8.8.8.8 на 10.1.1.2, то это не вариант (тем паче, что ключ могут не только поюзать, но и скопировать себе «на чёрный день»).

ssh предлагает возможность форварда ssh-агента (это такой сервис, который запрашивает пароль к ключу). Опция ssh -A пробрасывает авторизацию на удалённый сервер.

Вызов выглядит так:

ssh -A user@8.8.8.8 ssh user2@10.1.1.2


Удалённый 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 user@8.8.8.8


Ну а подключение тривиально: ssh raep.

Повторю важную мысль: сервер 8.8.8.8 не может перехватить или подделать трафик, воспользоваться агентом авторизации пользователя или иным образом изменить трафик. Запретить — да, может. Но если разрешил — пропустит через себя без расшифровки или модификации. Для работы конфигурации нужно иметь свой открытый ключ в authorized_keys как для user@8.8.8.8, так и в user2@10.1.1.2

Разумеется, подключение можно оснащать всеми прочими фенечками — прокидыванием портов, копированием файлов, сокс-прокси, L2-туннелями, туннелированием X-сервера и т.д.

Финал


Разумеется, в посте про туннели должен быть туннель, а в любой успешной статье — секретный ингредиент всеобщей популярности. Держите:
Георгий Шуклин @amarao
карма
271,0
рейтинг 18,8
Пользователь
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Администрирование

Комментарии (129)

  • +8
    Спасибо. Очень полезная статья.

    По содержанию похожа на эту, только текст другой.
    • +7
      Это то самое типовое руководство, которое заканчивается на -L/-R/-D.
  • +1
    Некоторые вещи реально очень круто, спасибо! Алиасы уже завтра начну применять.
    • +6
      Когда я первый раз напечатал ssh ns1 вместо ssh -C family_n@lkt-srv-ns1.spb.companyname.ru, я понял, что ssh — это здорово.
      • +2
        а почему не alias ns1='ssh -C family_n@lkt-srv-ns1.spb.companyname.ru' и потом просто ns1?

        По крайней мере я у себя прописал так. Правда я не знал про алиасы на уровне ssh
        • +2
          alias не нормальная команда. Автокомплиты не работают, редиректы «в» тоже не очень.
          • +2
            scp не работает, rsync-over-ssh не работает, любой version control over ssh не работает и т.д.

            Да, всё вышеперечисленное можно с помощью совершенно диких опций командной строки заставить жить без ~/.ssh/config, но зачем?
        • +1
          точно так же прописал кучу хостов и вызываю их по имени алиаса
      • +2
        А вы пробовали автокомплит в ssh? Набираю ssh re дополняет до redmine.host.com.
        • 0
          А если настроена авторизация по сертификату, то scp добивает табом путь на выбранном сервере =)
  • +1
    Спасибо за контент. По поводу 443 немного оффтопика.
    Имхо VPN лучше чем socks, и openvpn эту проблему решает отлично с port-share. Так что лично у меня для браузера 443 порт отдает страничку, а для openvpn туннель )
    • 0
      ssh может обеспечивать и туннель. Честно говоря, я сам не пробовал, но в теории должно быть. Почему ssh лучше, чем openvpn? Ну, в первую очередь потому, что dpi с большой вероятностью его таки пропустит (иначе все админы порвут все возможные места за поломанный ssh).

      Главным же аргументом является минимализм. ssh есть и так и так, зачем лишний софт ставить? (И на сервер, и на рабочую станцию/ноутбук).
      • 0
        Ну, как минимум тем, что не нужно вносить изменения в конфигурацию всего софта. Например — прописывать/убирать прокси. По идее с т.з. dip разницы между любым-другим-TLS быть не должно, надо будет посмотреть кстати. Ну и порт шаринг из коробки. Вроде ssh не умеет
      • 0
        Порт шаринг — ssh не умеет. На 443 порту может жить апач и openvpn. С точки зрения DPI возможно разницы и нет, а может и есть.
  • +6
    >> примерно 10% людей, которых просишь дать ssh-ключ постят id_rsa, причём из этих десяти
    >> процентов 100% — мужского пола

    Это можно и жирным выделить )) Спасибо, хорошо написано.
  • +3
    Спасибо за статью, туннели очень внятно и приятно освещены, большой труд.

    … вопрос про CompressionLevel. Он же, по man-у, только для ssh v1, который нынче принудительно включать надо.
    Или есть подводные камни?
    • +3
      Уели. Не прочитал внимательно. Да, убираю из примеров.
  • +1
    Автор постарался, работу — плюсую, и добавляю в избранное. Побольше бы таких памяток!
  • +1
    scp, кстати может в маски всякие и автодополнение пути на удаленной машине — очень классная фича.
    • +3
      Автодополнение может не scp, признаемся, а автокомплит. Он, кстати, иногда умнее ssh и умудряется правильно прокидывать имя пользователя (отличное от текущего).
      • 0
        Более того, если доступ по ключу без пароля, то автокомплит может дополнять пути на удаленной машине (то есть в его скриптах написано попытаться пойти на ту машину по ssh). Правда, такое поведение не всегда приемлемо из-за дополнительных тормозов.
        • 0
          Вот ээто я и имел в виду.
  • 0
    Спасибо большое. Я тут как раз настраивал удалённые фс
  • 0
    Скажите, а возможен проброс x-сервера используя Putty с linux на windows если порты на подключаемом компе закрыты. У меня только в локальной сети получалось
    • 0
      Возможен. Только вы, наверное, хотели сказать наоборот — с windows на linux. X-сервер там, где рисуется картинка.

      Я как-то на windows прокидывал X'ы (установил для этого putty и x-server для windows) и показывал java-приложение с headless-сервера под linux'ом. Было мерзко, рабоче.
      • 0
        Подключаюсь с винды к линуксу. Иксы на винде, все входящие соединения блокируются. А в Putty нужно IP X сервера указать
        • +1
          127.0.0.1
          • 0
            Спасибо, попробую
  • +1
    Спасибо! ssh пользуюсь очень часто, а знал всего пару фич.
    Файлы передавал вообще через onedayfiles.com + wget.
  • +2
    Всё знал, единственное, дополню, что ssh_config может понимать и такую конструкцию как Host * для всех остальных хостов, чтобы не вписывать все хосты, где имя пользователя отлично от локального.
    • 0
      Оки, спасибо, сейчас допишу.
      • 0
        На самом деле формат файла предусматривает указание глобальных переменных, равно как и относящися к конкретному хосту, примерно так
        User root
        PasswordAuthentication yes
        
        Host home
                Hostname myhome.dyndns.org
                User vasya
                PasswordAuthentication no
        

  • 0
    Подсказка всем, кто будет редактировать ssh_config и использовать IdentityFile: ssh-agent может (и часто так и поступает) перегружать тот ключ, что указан в ssh_config. Чтобы этого не случилось, используйте IdentitiesOnly. Пару часов однажды убил пытаясь настроить подключение к двум хостам с разными ключами.
    • +1
      Это, кстати, очень философский вопрос, о том, какие ключи где и как использовать.

      Я придерживаюсь модели: один терминал — один ключ. На каждом ноуте/десктопе свой ключ. Один. Используется для работы с устройства.

      Мотивация: спиз… т ноутбук (хоть у меня там ключ и под паролем), я буду точно знать, какой ключ отзывать (и он грепается по hostname в конце ключа).
      • +1
        Прекрасно вас понимаю. Но тем не менее, случаи бывают разные. Вот к примеру, на команду разработчиков ключ к GitHub-у клиента был один. Получить доступ к аккаунту, чтобы добавить другой ключ не представлялось возможным. Пришлось этот ключ использовать и остальным членам команды.
        • +8
          буэ

          Я не фанат всякой секьюрной хрени, но употребление общих ключей напоминает использование общей зубной щётки.
          • 0
            ИМХО, в данном случае это было вполне оправдано и достаточно секьюрно. По окончании работ заказчик просто удалит ключ, выданный команде для работы и никто больше не получит туда доступа. В конце концов, открытые/закрытые ключи и прочие механизмы аутентификации — всего лишь способ установления доверия между участниками.
            • 0
              Правильным вариантом было бы просто добавить людей/ключи людей к репозиторию.
              • 0
                Конечно. Но именно это и не представлялось возможным, о чём я написал в комменте выше.
  • +1
    Ещё есть MasterMode, который позволяет использовать уже установленное соединение для подключения ещё одной консоли, или использовании scp без авторизации. Активируется параметром -M. Или через config:
    ControlPath /home/username/ssh-mastermode-%h-%p-%r
    ControlMaster auto
    • 0
      Ну зачем вы прямо в ~ гадите?
      ~/tmp используйте или там ~/.ssh/socket какой-нить
      а вот прямо ~/ это неприлично же, это все равно что справлять малую нужду на кухне.
      • –1
        Вы бредите. Это всего-лишь временный файл, который автоматически удалится при закрытии подключения.
        • 0
          временным файлам место в ~/tmp(или в /tmp зависит от вашей паранойи)
          • 0
            Ну, технически — это не совсем временный файл. Это то, что в /var/run помещается для системных сервисов (ну, или /run в новых системах). По аналогии — per user такое, наверное, должно бы в ~/run создаваться.
            • 0
              да, это сокет, но в принципе же всякие php-fpm создают свои сокеты в /tmp, потому я и предложил ~/tmp.
              вообще у меня в системе оно в ~/.ssh/socket/ создает свои файлы, там оно мне совсем не мешает :)
  • 0
    Спасибо, теперь буду просто давать ссылку на эту статью, вместо рассказов.
    • 0
      Аналогично. Только еще сопру в pdf, чтобы уж в совсем сложных случаях можно было пользоваться.
  • +1
    Там с таром-то, не будет работать — хостнэйм пропущен.
    • +1
      Поправил.
  • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      Которым а не который. Хотя да, не сразу ясно если не знаешь
      • НЛО прилетело и опубликовало эту надпись здесь
        • 0
          Жаргонизм. Заходят пользователем на сервер. Ну или заходят «из-под пользователя на сервер». Имеется в виду тот username, который передаётся.
          • 0
            угу. это фрагмент, который будет требовать разъяснений у многих

            если бы не знал, о чем речь — я бы точно не понял
            чем, тот который ходит отличается от того, которым ходят — и кто из них где

            • 0
              Да, это недостаточно ясно. Можно сказать так: локальный пользователь (локальной машины), удаленный пользователь (определенного сервера).
  • +1
    А вот еще ценная фича: ssh может своими силами делать chroot для пользователя sftp. Или такой хак: в список ключей можно вписать команду которая будет выполнятся на сервере вместо шэла при использовании ключа
    • 0
      Кстати, вы умеете настраивать chroot на sftp для отдельных ssh-учёток?
      • 0
        как-то так:
        Match group sftponly
                 ChrootDirectory %h
                 X11Forwarding no
                 AllowTcpForwarding no
                 ForceCommand internal-sftp
        
        • 0
          Проблема в том, что «как-то так» не работает, например, в свежем селектеловском дебиане — в зависимости от параметров либо вообще не логинит, либо не chroot'ит.
          • 0
            как-то так у меня работает. Есть подводные камни: весь путь должен владеться root-ом, шэл — баш либо подобный
          • +1
            Простите, дебиан не «селектеловский», а просто дебиан. Мы не зря используем preseed для установки, а не клонируем готовое.
            • +2
              Да, проверил, вы правы — дебиан Скалакси. Премного извиняюсь!
  • 0
    Если да — ключ сохраняется в файл ~/.ssh/known_hosts. Узнать, где какой ключ нельзя (ибо несекьюрно).
    Разве?
    Находим в ~/.ssh/known_hosts строчку с искомым доменным именем/ip-адресом, у удаляем её. Всё, наш клиент забыл «отпечаток» того сервера.
    • 0
      Это от версии зависит — в дэбьяне там только номера
      • +1
        HashKnownHosts no в /etc/ssh/ssh_config спасает.
        На счёт ~/.ssh/config не уверен
    • 0
      Как ответили ниже, это зависит от опции HashKnownHosts. У меня другой вопрос — почему без нее считается несекьюрно? Это же публичные ключи. Я ее обычно отключаю, поскольку с ней автокомплит по имени хоста перестает работать.
  • +2
    scp годится только для очень больших файлов, если нужно передать много мелких файлов, то лучше делать как-то так:

    cd /storage; tar cf — .snapshots | ssh root@192.168.0.1 tar xf — -C /storage

    A sshfs можно подключать через fstab.
    • 0
      %s/—/-/g
    • 0
      Чем не угодил scp -r?
    • 0
      А я просто в запускаемых приложениях (Linux Mint) дабавил команду монтирования (sshfs user@host:path path -o reconnect)
  • –1
    С нормальным каналом нормальный способ, зато не надо в консолях выкручивать руки.
    • 0
      Пардон, промахнулся, это был ответ товарищу ksevelyar.
      • +1
        А чем не угодил rsync -r?
  • 0
    >с него в этой статье показываются картинки
    Решили проверить, выдержите ли хабраэффект?
    • +1
      хабраэффект сильно переоценен, %username%
    • +4
      чё? Какой хабраэффект? У меня раздача торрента даёт большую нагрузку, чем отдача статики. За 5 часов 75к хитов.

      Вообще ни о чём.
  • 0
    Есть ещё замечательная статья про авторизацию по ключам, там тоже туннель в туннеле… www.unixwiz.net/techtips/ssh-agent-forwarding.html

    Ну и про
    Безопасность microsoft при работе в сети мы все хорошо знаем

    Знаем, знаем
  • 0
    Не увидел описания типовой конструкции «VPN для бедных» вида:

    Host	shellbox.company
    	HostKeyAlias shellbox
    	Hostname public.address.for.shellbox.company.com
    	LocalForward 22001 server1.company.private.zone:22
    	LocalForward 22002 server2.company.private.zone:22
    	LocalForward 22003 server3.company.private.zone:22
    ...
    
    Host	r_server1.company.private.zone
    	HostKeyAlias server1.company.private.zone
    	Hostname 127.0.0.1
    	Port 22001
    
    Host	r_server2.company.private.zone
    	HostKeyAlias server2.company.private.zone
    	Hostname 127.0.0.1
    	Port 22002
    ...
    
    


    После чего типовая схема работы с помощью такого VPN:

    1. «Активировать» VPN, выполнив один раз «ssh shellbox.company» и оставив висеть это соединение
    2. После этого просто дописывать некий префикс — например, как в примере — «r_» к имени серверов, на которые хочешь ходить — т.е. ходить на «r_server1.company.private.zone», когда хочешь оказаться на «server1.company.private.zone».
    • 0
      Мне кажется, последний вариант с ProxyCommand именно эту задачу и решает, причём его не надо «активировать», т.е. проходит нормальный ssh сквозь другой сервер.
      • 0
        Вариант с ProxyCommand плох несколькими вещами:

        1. Появился недавно _и_ должен поддерживаться ssh-сервером на той стороне. Даже далеко не все современные (ну, плюс-минус современные) большие Linux его поддерживают, что уж говорить об инсталляциях на всяких Cisco и/или минималистичных вариантах вроде OpenWRT

        2. Плохо себя ведет с ControlMaster — в зависимости от конфигурации ControlPath мы получаем либо создание отдельного ssh-соединения до публичной машины на каждый конечный хост, либо вообще невозможность работать более, чем с одной разной приватной машиной одновременно (зато с одной можно, да, поднимать сессии пачками и все будет ок).

        Кстати, да, про ControlMaster тоже ничего не увидел в статье, а это, субъективно, одна из самых важных, если не самая важная, настройка в ssh.
        • 0
          Почему ControlMaster так важен? Просто чтобы scp -r делать более свободно? Или для медленных каналов?
          • 0
            Экономит приличное количество нервов и резко повышает интерактивность использования ssh при некоторых сценариях. Даже на современных машинах (с двух сторон) и приличных каналах (полноценный гигабит, например) пользоваться, скажем, комплишеном для выбора файла на той стороне при написании строчки для scp или rsync-over-ssh, крайне некомфортно, когда на каждое нажатие Tab будет происходить реконнект с удаленной стороной, все эти хендшейки, логины, создания терминалов и т.д. Да и нажимать подтверждение того, что «да, использовать ключ» — тоже замучивает.
            • 0
              Простите, не понимаю о чём вы.

              У меня до работы канал сильно меньший (от 50 до 100 мегабит), но я не вижу никаких запросов «да, использовать ключ» или тормозов в работе автокомплита.
              • 0
                Типовая ситуация: хочу скопировать какой-то файл из DocumentRoot http-сервера, помню, что он на машине server3, где-то то ли в /var/www, то ли в /var/www/html, то ли в /srv/www, то ли в /usr/local/htdocs. Лет N-дцать назад для этого нужно было открыть отдельную консоль, зайти оттуда через telnet/rsh/ssh на server3, полазать там по каталогам, пописать команды типа «ls /var/www», «ls /var/www/html» и т.д.

                Но вернемся в наше время. У меня есть все хорошо, на сервер я хожу по ключам, использование ключей подтверждается, есть комплишен, сейчас, думаю, как белый человек, воспользуюсь.

                Вариант «без ControlMaster»:
                1. Пишу «scp s», нажимаю Tab.
                2. Мне предлагают на выбор «server1», «server2», «server3» и т.д. Выбираю «server3». Дописываю ":/", нажимаю Tab еще раз.
                3. Комплишен устанавливает новое соединение с server3. Обмен ключами практически в любом случае занимает минимум полсекунды. Затем выскакивает окошко «Allow use of key такой-то?». Поднимаю глаза на окошко, жму дополнительный Enter. Аутентификация, повторный обмен ключами, логин, открытие сессии и выполнение ls или echo * на стороне сервера занимают еще с полсекунды. Получаю наконец-таки желанный список из "/bin", "/boot", "/cgroup", "/dev" и т.д.
                4. Желаю посмотреть "/var", пишу букву «v» и чтобы не допечатывать «ar» по привычке нажимаю Tab. Внезапно, для выполнения этого комплишен еще раз переподключается к серверу и я трачу еще минимум секунду и еще одно лишнее чтение окошка и нажатие Enter.
                5. Шаг 4 еще, собственно, ничего даже не начал прояснять по поводу содержимого "/var". Дописываю "/", уже ругаясь, нажимаю Tab еще раз. Еще секунда и еще один Enter, наконец-то выведено содержимое "/var".
                6. Если забыться и не написать «www» полностью руками или не выбрать его из списка (если используется zsh), то следующее «w» + Tab приведет еще раз к секунде ожидания и окошку.

                n. Наконец-таки сделав свою задачу, через некоторое время обнаружить, что логи server3 загажены тоннами бессмысленных сообщений о подключениях вида:

                Aug  1 00:00:03 server3 sshd[443955]: Accepted publickey for greycat from 11.22.33.44 port 43506 ssh2
                Aug  1 00:00:04 server3 sshd[443962]: Received disconnect from 11.22.33.44: 11: disconnected by user
                Aug  1 00:00:06 server3 sshd[443967]: Accepted publickey for greycat from 11.22.33.44 port 43507 ssh2
                Aug  1 00:00:06 server3 sshd[443971]: Received disconnect from 11.22.33.44: 11: disconnected by user
                


                Вариант «с ControlMaster»:
                1. То же
                2. То же
                3. Если соединения с server3 нет, то то же. Если есть, то мгновенно делается _один_ вызов на уже установленном соединении и тут же появляется на экране результат. Один пакет туда, один-два с результатом обратно.
                4..(n-1). Даже если окошко выпрыгивало для первого коннекта, то для всех последующих уже точно все будет быстро, как на локальной ФС, и без всяких дозапросов.
                n. В логах ровно одно подключение, как и должно быть с точки зрения аккаунтинга: человек подключился, человек поработал, человек отключился.

                По-моему, вариант «с ControlMaster» имеет некоторые преимущества?
                • 0
                  Ну, у меня один ssh-ключ, так что никаких запросов нет.

                  А автокомплит занимает неощутимое время.

                  Засирание логов — может быть, но кого это реально волнует?
                  • 0
                    Какая разница, сколько ключей? Как раз напротив — если уж ключ везде один, то добавлять ключ без ssh-add -c можно фактически в двух случаях:

                    1. Либо совсем не пользоваться agent forwarding (-A)
                    2. Либо когда есть тотальная уверенность в том, что люди, которые могут получить доступ к auth-сокету агента, не воспользуются ключом не по назначению

                    Во всех других случаях, когда есть хоть какая-то толика недоверия к людям, имеющим root на удаленном сервере, я не вижу причин не использовать ssh-add -c — это хотя и надоедливая защита, но действенная.

                    Про время — сейчас вот специально замерил, сколько у меня занимает установление соединения, хендшейки и выполнение 1 минимальной команды на соединении. Лучший получившийся результат (с одного относительно мощного сервера на другой аналогичный по линку в одном гигабитном свиче) — 680 мс при отключенном окошке подтверждения; типичный результат, к сожалению, в районе минуты — по нелокальным линкам, когда один из компьютеров медленнее другого и т.д. Для сравнение, худший результат с ControlMaster — 15 мс. В хороших случаях — 3-4 мс.

                    При более-менее быстрой скорости печати внезапная пауза в секунду (ну или даже в 0.7 с) при наборе, субъективно, малоприятна.

                    Засирание логов волнует, например, примерно каждую вторую IDS. Пару раз сталкивался с весьма жизненными ситуациями, когда человек вот так вот поконнектившись ~20 раз в минуту к серверу получал reject по IP-адресу, взведенный алерт в IDS типа «подозрительная активность на сервере N» и визит службы безопасности с разбирательством «у вас на компьютере вирус, который ломает сервер N».
                  • 0
                    Дайте угадаю — у вас rtt до сервера в районе нескольких секунд? А теперь представьте, что сервер в Америке? Опять же ждать пока разгонится slow-start на LFP при передаче файлов не очень хочется.

                    Засирание логов действительно не важно, пока «безопасники» не начинают жаловаться (у некоторых компаний так вообще IDS лицензируются по кол-ву обрабатываемых сообщений). Да и самому приятнее потом в чистых логах разбираться, если нужно будет.
  • +2
    А еще:
    либо ssh разрешён (читай — делай что хочешь)

    На самом деле для «делай что хочешь» достаточно хоть какой-то связи с внешним миром. Вполне себе есть работающие прокси и туннели на базе ICMP, на базе DNS, на базе побитовой передачи результатов единичных легитимных DNS-запросов и т.д.
    • +1
      ICMP можно смело фильтровать по rate, доводя до нефункциональности туннель (но сохраняя пинги), DNS-запросы аналогично.

      Вся ж фича не в том, что это «в принципе возможно», а в том, что это комфортно и стандартно. И трафик никак не выделяется «нехарактерными» признаками.
      • 0
        Так и ssh, пардон, что на 22, что на 443 — где угодно можно зашейпить, как и в целом трафик по любым портам, по которым нет L7-проксирования. Ну и, по сути, да — шейпинг и делание «некомфортно» — это чуть ли не единственный действующий способ претворения таких ограничений в жизнь.
    • 0
      А бывают такие туннели, которые прикидываются валидным http? А то я был в таком месте, где был только выход по 80-му и, насколько я понял, DPI. Здесь могут быть сложности с тем, что в дополнение ко всему содержимое http может фильтроваться и модифицироваться, что для веб-серфинга несущественно, а для обернутого ssh фатально.
      • +2
        Смотря что подразумевается под «валидным http» — метод CONNECT — тоже вполне себе http.

        Туннелировать хитрым образом через особенный внешний туннельный http-сервер умеют многие, например вот есть проект с незамысловатым названием HTTPTunnel (серверная часть на php, клиентская — на perl или в виде бинарника под Windows) или там Proxytunnel — примерно то же самое, но еще банальнее, работает прямо со stdin/stdout, очень легко подключается к ssh через ProxyCommand.
        • 0
          Да, похоже, httptunnel — то что нужно.
          • 0
            Вот ещё инструкция хоть и на английском, но по ней все делал. И выбрался наружу в закрытом учреждении. Тоже про HTTPTunnel.
            dag.wieers.com/howto/ssh-http-tunneling/
  • +2
    У fusermount есть полезная опция -z (lazy unmount), которая позволяет отключить даже занятый каталог.
  • 0
    На заметку, в ssh_config(~/.ssh/config) можно прописать ForwardAgent Yes, что бы не передавать ключ -A каждый раз. Можно и для Host *, можно для конкретных хостов.
  • 0
    годный ликбез
    хочется подробностей про L2 over ssh и рецепт wake-up-on-lan через ssh
  • +1
    скорость по SSH (scp) хорошо поднимается, если выбрать шифрование «по легче».
    в своё время вперёд выставлял Blowfish и скорость существенно возрастала.

    по умолчанию установлено что-то типа
    Cipher 3des Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc
    • 0
      Некоторые считают, что arcfour ( RC4 ) чуть быстрее blowfish, и главное, потребляет меньше ресурсов. А при передаче файлов криптостойкость обычно не так уж важна (за это arcfour и не в фаворе, хотя и незаслуженно).
  • 0
    Небольшое дополнение насчет fuse. Бывает, что сетевое соединение отвалилось, тогда при попытке доступа к точке монтирования консоль намертво зависает (так что ^Z не помогает). В этом случае при отмонтировании нужно проявить выдержку, чтобы не нажать таб, вызвав тем самым зависание консоли из-за того, что автокомплит пытается читать подмонтированную директорию.
  • 0
    Дополню своей заметкой там про удобный ввод парольной фразы и полезняшки в коментах
  • 0
    Есть и вот такой головоломный приём использования pipe'а (любезно подсказали в комментариях в жж):

    tar -c * | ssh user@server cd && tar -x


    Блин. Классно. А то я делал как-то так:

    tar -cvf — -C upload. | ssh user@server tar -xpvf — -C /var/spool/www/upload/
  • 0
    у меня с ssh-copy-id возникла проблема — оно не умеет (или не умело?) работать с нестандартным портом. Решил проблему такой простой функцией: pastebin.com/Xb3A6Prq
    • +1
      Всегда умело. Надо просто порт указывать правильно (кстати, спасибо, ща допишу в статью):

      ssh-copy-id '-p443 user@example.com'

      (внимание на кавычки).
      • 0
        можно и с двойными кавычками, типа ssh-copy-id "-p 2345 user@host"
  • 0
    Извините, что не в QA. Как можно выполнить несколько команд. Что-то типо этого:
    ssh example.com -t "cd /www/example.com && git status -sb | head -1"
    
    • 0
      ``
    • 0
      всё правильно написали, так что не понятно что вас смущает
      ssh server «command1;command2;command3» или ssh server 'command1;command2;command3'
  • 0
    Крепко жму руку! Спасибо.
  • 0
    Мы когда-то написали для своей команды клиента, который умеет делать магию. Сейчас под GPL и лежит на гитхабе. Надо про него статейку сбацать наверное. Он сильно упрощает такие действа, как «хождение за три хопа в веб приложение».
  • 0
    Круто!
  • 0
    Спасибо, пригодится!
  • 0
    Статья хорошая, спасибо.
    P.S.
    Ещё большая драма, если у нас есть нестандартный порт, и, например, первая версия ssh (привет цискам).

    Привет от цисок: ip ssh version 2
    • +1
      Есть старые циски (которых еще полно, и которые справляются со своими обязанностями) и они не умеют v2.
  • 0
    спасибо за статью! не очень понял про проброс Х-сервера, ssh ric rdesktop -k en-us 192.168.1.1 -g 1900x1200, тут ric — это имя хоста в локальной сети?
    • 0
      Скорее, ric это алиас, описанный в ~/.ssh/config.
      • 0
        а да, вчитался — в предыдущем пункте конфиг
        Host ric
        Hostname ооо-рога-и-копыта.рф
        User Администратор
        ForwardX11 yes
        Compression yes
        т.е по сути это ssh -XYC user@SERVER rdesktop -k en-us 192.168.1.1 -g 1900x1200
  • 0
    Замечу, что со временем постоянная смена ключей хостов из-за переналивки задалбывает, и спасает только
    HashKnownHosts no StrictHostKeyChecking no
    в конфиге. После этого выключаются дурацкие вопросы про добавление в known hosts (yes/no), равно как и параноя про man-in-the-middle.
  • 0
    Чудесно! Давно искал многое из этого в доступной форме с примерами. Спасибо большое!
  • +1
    Еще одна полезная «фича» ssh — это Multiplexing. Если нужен шустрый автокомплит для scp, то можно запустить один терминал с ssh-сессией, а во втором работать с scp — он будет реюзать существующее подключение.
  • +1
    Но копировать его на 8.8.8.8 мы не хотим, ибо там проходной двор и половина людей имеет sudo и может шариться по чужим каталогам.

    Стало быть, многие имеют рутовый доступ к DNS серверу гугла? Странно, что никто не обратил внимание на сей факт в статье
    • 0
      Капитан очевидность докладывает, что это всего лишь пример.
      • 0
        Да это ясно. Я просто хотел сказать, что не очень удачно подобранный, так как пересекается с действительностью. Так, повод улыбнуться получившемуся в итоге выражению: «Но копировать его на 8.8.8.8 мы не хотим, ибо там проходной двор и половина людей имеет sudo и может шариться по чужим каталогам.»
        Добавление смайликов к моему предыдущему сообщению подсказало бы, что оно носило саркастический характер. Но смайлы на хабре не котируются.Но копировать его на 8.8.8.8 мы не хотим, ибо там проходной двор и половина людей имеет sudo и может шариться по чужим каталогам.
  • 0
    Кстати с socks-proxy можно несколько упростить задачу, когда находишься «Фиг знает где». Дело в том, что приходится каждой программе прописывать настройки socks5, а это утомительно.

    Есть такая софтина redsocks — умеет заворачивать весь исходящий траф на определенный порт, а на этом порту мы и запускаем ssh -fNL…
    К софтине правда еще прилагаются несколько правил iptables.
  • +1
    Хорошая статья, тут можно разве, что пропиарить книжку: SSH Mastery: OpenSSH, PuTTY, Tunnels and Keys

    Ну и пара «интересностей» ещё:
    1. ControlMaster — уже упомянули пару раз в комментах.
    2. Извлечение public ключа из private: ssh-keygen -y -f id_rsa > id_rsa.pub
    3. pam-ssh-agent-auth тоже интересная штука, особенно в комбинации с вышеописанным authorized_keys2
    4. ssh-keyscan бывает полезна, впрочем любители chef/puppet/cfengine могут собирать ключики с машин более эффективным образом.
    5. В последних версиях OpenSSH начали использовать Elliptic Curve DSA
  • 0
    либо ssh разрешён (читай — делай что хочешь), либо ssh запрещён

    Либо ssh разрешён строго на определённые адреса, необходимые для работы.
  • 0
    Отличная статья, спасибо!

    В качестве дополнения — есть ещё замечательня утилита corkscrew (доступна в т. ч. и на Cygwin), позволяющая для установления SSH-соединения использовать HTTP-прокси. Необходимо соблюдение двух условий:

    • прокси-сервер должен разрешать HTTPS CONNECT;
    • SSH-сервер должен «слушать» на порту 443 (в мире сурового ынтырпрайза HTTPS CONNECT на порт, отличный от 443, обычно запрещают).

    Ремарка: PuTTY умеет использовать HTTP прокси своими силами, обходясь без corkscrew.

    В результате фрагмент конфигурации будет выглядеть так:

    Host home
            Hostname ...
            User ...
            Compression yes
            Port 443
            ProxyCommand corkscrew webcache.mycompany.com 8080 %h %p
    

    После этого «хождение» на все остальные SSH-сервера достигается тривиальным образом:

    Host ...
            Hostname ...
            User ...
            Compression yes
            Port ...
            ProxyCommand ssh -W %h:%p home
    

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.