Переводы — Вы должны были узнать это от мамы: шесть вещей про SSH.
Если вы когда-нибудь серьезно пользовались Linux, то скорее всего уже хоть немного знакомы с основами SSH. Но вы хотите узнать больше. В этой статье мы дадим вам шесть советов по SSH для пополнения знаний . (А еще это отличная тема для коктейльной вечеринки)
Все знают, что SSH используется для доступа к удаленному шелу, но знаете ли вы, что его можно использовать для запуска команд на них? Вы можете просто добавить команду после имени хоста! Например:
В сочетании с беспарольным входом по SSH, вы сможете расширить возможности своих скриптов. Хотите узнать, какая версия Python установлена на каждой из ваших систем? Просто сложите ssh hostname python -V в цикле и все готово!
Но это работает не со всеми командами:
Почему? Некоторые программы требуют псевдо-терминал и не знают что делать, когда его нет (все, что хочет рисовать в любой части экран, а скорее всего попадает в эту категорию). Но ssh может обработать это с помощью опции -t. Ssh выделит вам псевдо-терминал, и тогда программа заработает.
Подождите, вот еще! Возможности ssh для проброса порта огромны. Допустим, у вас на работе есть веб-панель на 80 порту сервера для аналитики и доступна только внутри корпоративной сети, а сейчас 2 часа ночи, и вам срочно нужен к ней доступ из дома, а ваш пейджер выключился.
К счастью, у вас есть ssh-доступ к вашей рабочей машине, которая находится в той же сети, что и сервер аналитики. Если вы можете подключится к рабочей машине, а она может подключится к серверу аналитики, значит мы можем сделать это, не так ли?
Правильно. Мы пойдем кружным путем:
Итак, с ssh desktop все ясно. Опция -L port:hostname:hostport говорит "Установить проброс с port (в этом случае 8080) к hostname:hostport (тут desktop:80)."
Теперь, если вы откроете http://localhost:8080/ в веб-браузере у себя дома, то будете подключены к 80-му порту рабочего компьютера. Близко, но не совсем! Помните, мы хотели подключится к веб-панеле, запущенной на 80-м порту сервера аналитики, а не рабочей машине.
Все, что нам осталось, это выполнить команду:
Теперь, удаленный конец проброшенного порта это analytics:80, который находится именно там, где запущена веб-панель. Но подождите, разве сервер аналитики не за фаерволом? Как мы можем добраться до него? Помните: это соединение установлено на удаленной системе (рабочем компьютере), и только из-за этого оно работает.
Если вам необходимо создавать много таких пробросов, то, возможно, больше подойдет что-то подобное:
Эта команда установит SOCKS-прокси на localhost:8080. Если вы настроите свой браузер использовать ее, то весь трафик браузера пойдет по SSH через вашу удаленную систему. Это значит что вы сможете прямо с браузера перейти на http://analytics/.
Загадка: подключитесь через ssh к системе, нажмите пару раз Enter, а потом наберите тильду. Ничего не появилось. Почему?
Потому что тильда в ssh является экранирующим символом. Прямо сначала строки вы можете нажать ~ и еще какую-то клавишу, чтоб выполнить интересные вещи с вашим ssh-соединением (таких как добавить 30 бонусных жизней после каждого проигрыша). ~? - покажет полный список управляющих последовательностей, но две самые удобные это ~. и ~^Z.
~. (тильда с точкой) оборвет ваше ssh-соединение, что удобно, когда оборвалось сетевое соединение, а вы не хотите ждать пока ssh-сессия оборвется.
~^Z (тильда с Ctrl+Z) отправит соединение в фоновый режим, если вы в это же время хотите еще что-то сделать. Вот пример в действии:
Я уверен, что вы видели это миллион раз и просто нажимали "yes", не думая:
Что тут происходит? Если это ваше первое подключение к bebop, то вы не можете точно сказать что это действительно bebop, или же какой-то самозванец, который выдает себя за bebop. Все что вы знаете, это "отпечаток пальцев" (ключ) системы, к которой вы обращаетесь. В принципе, вы должны проверить это вручную (тоесть позвонить туда, где находится удаленный хост, и попросить их прочитать ключ).
Допустим вы и ваш помешанный на безопасности друг действительно хотите это сделать. Как вы можете узнать этот ключ? На удаленном хосте ваш друг должен выполнить:
Парам! Они совпадают, и это означает что можно спокойно продолжать. С этого момента ключ сохранен в вашем списке известных хостов (в ~/.ssh/known_hosts), так что вам не придется подтверждать каждый раз. И если когда-то на другом конце изменится ключ, вы увидите предупреждение, что кто-то пытается читать ваш трафик! (Или ваш друг переустановил систему и не сохранил ключ.)
К сожалению, спустя некоторое время, вы и ваш друг должны расстаться (что-то о Kirk vs. Picard) (имеются ввиду знаменитые герои Star Trek Джеймс Тибий Кирк и Жан-Люк Пикард - прим.переводчика), и вы хотите удалить его ключ из своего списка известных хостов. "Без проблем," думаете вы, "Я просто удалю его из своего списка известных хостов.". Вы открываете файл и будете неприятно удивлены: перемешанный файл, с кучей непонятных символов. На самом деле это хеши имен хостов (или IP-адресов), к которым вы подключались раньше, и соответствующие им ключи.
Перед тем как продолжить, вы, конечно, спросите себя: "К чему все усложнять? Почему нельзя просто перечислить имена хостов простым текстом, чтоб люди могли легко редактировать файл?". На самом деле все так и было до недавнего времени. Но оказывается оставлять их в таком виде - это потенциальная дыра в безопасности, так как предоставляет злоумышленнику удобный список других мест, к которым вы подключались (мест где, к примеру, пользователь может невольно использовать те же пароли).
К счастью, ssh-keygen -R делает трюк:
Как я сказал, все еще нет простого способа удалить ставшие горькими воспоминания о вашей бывшей дружбе.
Если вы дочитали до этого места, то вы уже профессионал в ssh. Как и другие профессионалы, вы логинитесь в кучу систем, в каждой свое имя пользователя, порты и длинные хостнеймы. Такие как ваши акаунты в AWS, Rackspace Cloud, ваш выделенный сервер или домашние системы ваших друзей.
И вы уже знаете как это делается: username@host или -l username чтобы указать ваше имя пользователя и -p portnumber чтобы указать порт:
Но это забывается очень быстро, особенно когда вам необходимо пройти через кучу других параметров для каждого из этих подключений. Откройте .ssh/config, файл в котором вы можете указать удобные псевдонимы для каждого набора этих параметров:
Теперь это просто:
И да, конфигурационный файл позволяет вам также задать команды пробрасывания портов или запуска чего-то. Если захотите - читайте страницу справки ssh_config для деталей.
Оригинал
Переведено при помощи сервиса translated.by инициативной группой переводчиков welinux при участии пользователей
settler, 
Zereal.
В коментариях к оригиналу статьи нашлось еще много интересного про SSH. Решил их оформить сюда же с дополнениями:
В .ssh/config можно включить вывод RandomArt-а, такого какой вы видите при генерации ключа:
Для этого в конфиг нужно добавить:
Это позволит визуально определять на какой хост вы заходите. Некоторым намного легче сразу заметить разницу, если картинка поменялась
Можно прокидывать вывод гуев приложений, запущенных на удаленной машине. Для этого:
(1) Запустите Х-сервер на локальной машине
(2) Запустите удаленный клиент (например xload для мониторинга загрузки на удаленной машине):
Примечание: может понадобится xhost или xauth чтоб разрешить подключение
Для разрешения форвардинга Х-ов в конфиге sshd на сервере надо включить
это хорошо, но в таком случае когда иногда забудешь про него и случайно наберешь просто alice.example.com, то оно работать не будет. Поэтому лучше сделать так:
тогда настройки для хоста будут работать под любым из этих алиасов
ssh-agent это программа хранящая приватные ключи, используемые для публичной аутентификации (RSA, DSA). Идея ssh-agent состоит в том, что он запускается в начале Х-сессии или при входе в систему, и все другие окна или программы запускаются как клиенты программы ssh-agent. Посредством переменных окружения агент может быть найден и автоматически использован для аутентификации при подключении к другим машинам с использованием ssh. (русский man ssh-agent на OpenNet)
Вот нашлась хорошая статья по ssh-agent. Если кому будет интересно, то можно будет потом тоже перевести :)
Для тех кому необходимо часто переустанавливать некоторые сервера (например для теста чего-то), есть путь отключить проверку ключей:
UserKnownHostsFile - отправит ключ не в файл known_hosts, а в какой-то другой (в данном случае в черную дыру :) )
StrictHostKeyChecking -заставит ssh не спрашивать yes/no при подключений к хосту, которого нет в известных, а сразу дописывать его в файл
Для того чтоб конвертировать существующий файл known_hosts в новый формат (с хешами вместо имен хостов и адресов) можно воспользоваться командой:
Не забудьте после этого удалить файл known_hosts.old, когда удостоверитесь что все нормально работает.
Опция ssh -t поможет также, когда вы хотите, например одной командой снаружи подключится к шлюзу во внутренней сети, а с него уже к какой-то машине в сети:
З.Ы. у ssh есть еще куча прекрасных возможностей :) Не забывайте про ssh-copy-id, reversed forwarding и т.п.
Updated:
По просьбам пользователей, добавлю сюда про передачу файлов с помощью scp
Утилита scp входит в состав пакета openssh и предназначена для удаленного копирования файлов через ssh-соединение.
Для передачи множества мелких файлов, лучше их предварительно за-tar-ить:
эта команда передаст в ssh уже заархивированную папку.
scp использует опции .ssh/config поэтому если у вас там прописаны настройки хоста, к примеру work, то команда копирования выглядит очень просто:
она скопирует локальный файл /local/file в домашнюю папку пользователя, который прописан для хоста work в .ssh/config
Updated2:
Alex2ndr в коментариях дополнил про использование sshfs для монтирования папок с удаленного хоста по ssh:
Про sshfs можно уложиться так:
(1) Командуйте!
Все знают, что SSH используется для доступа к удаленному шелу, но знаете ли вы, что его можно использовать для запуска команд на них? Вы можете просто добавить команду после имени хоста! Например:
| 1 2 |
wdaher@rocksteady:~$ ssh bebop uname -a |
В сочетании с беспарольным входом по SSH, вы сможете расширить возможности своих скриптов. Хотите узнать, какая версия Python установлена на каждой из ваших систем? Просто сложите ssh hostname python -V в цикле и все готово!
Но это работает не со всеми командами:
| 1 2 |
wdaher@rocksteady:~$ ssh bebop top |
Почему? Некоторые программы требуют псевдо-терминал и не знают что делать, когда его нет (все, что хочет рисовать в любой части экран, а скорее всего попадает в эту категорию). Но ssh может обработать это с помощью опции -t. Ssh выделит вам псевдо-терминал, и тогда программа заработает.
| 1 2 |
# Наслаждаемся процессом мониторинга |
| 1 2 |
# Если вы используете GNU Screen, восстановите сессию одной командой |
(2) Пожалуйста, вот вам порты
Подождите, вот еще! Возможности ssh для проброса порта огромны. Допустим, у вас на работе есть веб-панель на 80 порту сервера для аналитики и доступна только внутри корпоративной сети, а сейчас 2 часа ночи, и вам срочно нужен к ней доступ из дома, а ваш пейджер выключился.
К счастью, у вас есть ssh-доступ к вашей рабочей машине, которая находится в той же сети, что и сервер аналитики. Если вы можете подключится к рабочей машине, а она может подключится к серверу аналитики, значит мы можем сделать это, не так ли?
Правильно. Мы пойдем кружным путем:
wdaher@rocksteady:~$ ssh desktop -L 8080:desktop:80
Итак, с ssh desktop все ясно. Опция -L port:hostname:hostport говорит "Установить проброс с port (в этом случае 8080) к hostname:hostport (тут desktop:80)."
Теперь, если вы откроете http://localhost:8080/ в веб-браузере у себя дома, то будете подключены к 80-му порту рабочего компьютера. Близко, но не совсем! Помните, мы хотели подключится к веб-панеле, запущенной на 80-м порту сервера аналитики, а не рабочей машине.
Все, что нам осталось, это выполнить команду:
wdaher@rocksteady:~$ ssh desktop -L 8080:analytics:80
Теперь, удаленный конец проброшенного порта это analytics:80, который находится именно там, где запущена веб-панель. Но подождите, разве сервер аналитики не за фаерволом? Как мы можем добраться до него? Помните: это соединение установлено на удаленной системе (рабочем компьютере), и только из-за этого оно работает.
Если вам необходимо создавать много таких пробросов, то, возможно, больше подойдет что-то подобное:
wdaher@rocksteady:~$ ssh -D 8080 desktop
Эта команда установит SOCKS-прокси на localhost:8080. Если вы настроите свой браузер использовать ее, то весь трафик браузера пойдет по SSH через вашу удаленную систему. Это значит что вы сможете прямо с браузера перейти на http://analytics/.
(3) Не забывайте про тильду
Загадка: подключитесь через ssh к системе, нажмите пару раз Enter, а потом наберите тильду. Ничего не появилось. Почему?
Потому что тильда в ssh является экранирующим символом. Прямо сначала строки вы можете нажать ~ и еще какую-то клавишу, чтоб выполнить интересные вещи с вашим ssh-соединением (таких как добавить 30 бонусных жизней после каждого проигрыша). ~? - покажет полный список управляющих последовательностей, но две самые удобные это ~. и ~^Z.
~. (тильда с точкой) оборвет ваше ssh-соединение, что удобно, когда оборвалось сетевое соединение, а вы не хотите ждать пока ssh-сессия оборвется.
~^Z (тильда с Ctrl+Z) отправит соединение в фоновый режим, если вы в это же время хотите еще что-то сделать. Вот пример в действии:
| 1 2 3 4 5 6 7 |
wdaher@rocksteady:~$ ssh bebop |
(4) Отпечатки пальцев
Я уверен, что вы видели это миллион раз и просто нажимали "yes", не думая:
| 1 2 3 4 |
wdaher@rocksteady:~$ ssh bebop |
Что тут происходит? Если это ваше первое подключение к bebop, то вы не можете точно сказать что это действительно bebop, или же какой-то самозванец, который выдает себя за bebop. Все что вы знаете, это "отпечаток пальцев" (ключ) системы, к которой вы обращаетесь. В принципе, вы должны проверить это вручную (тоесть позвонить туда, где находится удаленный хост, и попросить их прочитать ключ).
Допустим вы и ваш помешанный на безопасности друг действительно хотите это сделать. Как вы можете узнать этот ключ? На удаленном хосте ваш друг должен выполнить:
| 1 2 |
sbaker@bebop:~$ ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key.pub |
Парам! Они совпадают, и это означает что можно спокойно продолжать. С этого момента ключ сохранен в вашем списке известных хостов (в ~/.ssh/known_hosts), так что вам не придется подтверждать каждый раз. И если когда-то на другом конце изменится ключ, вы увидите предупреждение, что кто-то пытается читать ваш трафик! (Или ваш друг переустановил систему и не сохранил ключ.)
(5) Потеряли ваши ключи
К сожалению, спустя некоторое время, вы и ваш друг должны расстаться (что-то о Kirk vs. Picard) (имеются ввиду знаменитые герои Star Trek Джеймс Тибий Кирк и Жан-Люк Пикард - прим.переводчика), и вы хотите удалить его ключ из своего списка известных хостов. "Без проблем," думаете вы, "Я просто удалю его из своего списка известных хостов.". Вы открываете файл и будете неприятно удивлены: перемешанный файл, с кучей непонятных символов. На самом деле это хеши имен хостов (или IP-адресов), к которым вы подключались раньше, и соответствующие им ключи.
Перед тем как продолжить, вы, конечно, спросите себя: "К чему все усложнять? Почему нельзя просто перечислить имена хостов простым текстом, чтоб люди могли легко редактировать файл?". На самом деле все так и было до недавнего времени. Но оказывается оставлять их в таком виде - это потенциальная дыра в безопасности, так как предоставляет злоумышленнику удобный список других мест, к которым вы подключались (мест где, к примеру, пользователь может невольно использовать те же пароли).
К счастью, ssh-keygen -R делает трюк:
| 1 2 3 |
wdaher@rocksteady:~$ ssh-keygen -R bebop |
Как я сказал, все еще нет простого способа удалить ставшие горькими воспоминания о вашей бывшей дружбе.
(6) Подключение под другим именем...
Если вы дочитали до этого места, то вы уже профессионал в ssh. Как и другие профессионалы, вы логинитесь в кучу систем, в каждой свое имя пользователя, порты и длинные хостнеймы. Такие как ваши акаунты в AWS, Rackspace Cloud, ваш выделенный сервер или домашние системы ваших друзей.
И вы уже знаете как это делается: username@host или -l username чтобы указать ваше имя пользователя и -p portnumber чтобы указать порт:
| 1 2 3 |
wdaher@rocksteady:~$ ssh -p 2222 bob.example.com |
Но это забывается очень быстро, особенно когда вам необходимо пройти через кучу других параметров для каждого из этих подключений. Откройте .ssh/config, файл в котором вы можете указать удобные псевдонимы для каждого набора этих параметров:
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
Host bob |
Теперь это просто:
| 1 2 3 |
wdaher@rocksteady:~$ ssh bob |
И да, конфигурационный файл позволяет вам также задать команды пробрасывания портов или запуска чего-то. Если захотите - читайте страницу справки ssh_config для деталей.
ssh! Это (не) секрет
Оригинал
Переведено при помощи сервиса translated.by инициативной группой переводчиков welinux при участии пользователей
settler, Zereal.В коментариях к оригиналу статьи нашлось еще много интересного про SSH. Решил их оформить сюда же с дополнениями:
RandomArt
В .ssh/config можно включить вывод RandomArt-а, такого какой вы видите при генерации ключа:
| 1 2 3 4 5 6 7 8 9 10 11 12 |
The key's randomart image is: |
Для этого в конфиг нужно добавить:
| 1 2 |
Host * |
Это позволит визуально определять на какой хост вы заходите. Некоторым намного легче сразу заметить разницу, если картинка поменялась
X11-форвардинг
Можно прокидывать вывод гуев приложений, запущенных на удаленной машине. Для этого:
(1) Запустите Х-сервер на локальной машине
(2) Запустите удаленный клиент (например xload для мониторинга загрузки на удаленной машине):
ssh -X wayne@mother xload
Примечание: может понадобится xhost или xauth чтоб разрешить подключение
Для разрешения форвардинга Х-ов в конфиге sshd на сервере надо включить
X11Forwarding yes
Несколько алиасов для хоста
| 1 2 3 4 |
Host alice |
это хорошо, но в таком случае когда иногда забудешь про него и случайно наберешь просто alice.example.com, то оно работать не будет. Поэтому лучше сделать так:
| 1 2 3 4 |
Host alice alice.example.com another_name foobar |
тогда настройки для хоста будут работать под любым из этих алиасов
ssh-agent
ssh-agent это программа хранящая приватные ключи, используемые для публичной аутентификации (RSA, DSA). Идея ssh-agent состоит в том, что он запускается в начале Х-сессии или при входе в систему, и все другие окна или программы запускаются как клиенты программы ssh-agent. Посредством переменных окружения агент может быть найден и автоматически использован для аутентификации при подключении к другим машинам с использованием ssh. (русский man ssh-agent на OpenNet)
Вот нашлась хорошая статья по ssh-agent. Если кому будет интересно, то можно будет потом тоже перевести :)
Отключение проверки ключа
Для тех кому необходимо часто переустанавливать некоторые сервера (например для теста чего-то), есть путь отключить проверку ключей:
| 1 2 3 |
Host test-server.example.org |
UserKnownHostsFile - отправит ключ не в файл known_hosts, а в какой-то другой (в данном случае в черную дыру :) )
StrictHostKeyChecking -заставит ssh не спрашивать yes/no при подключений к хосту, которого нет в известных, а сразу дописывать его в файл
Конвертация known_hosts в новый формат
Для того чтоб конвертировать существующий файл known_hosts в новый формат (с хешами вместо имен хостов и адресов) можно воспользоваться командой:
ssh-keygen -H
Не забудьте после этого удалить файл known_hosts.old, когда удостоверитесь что все нормально работает.
SSH over SSH
Опция ssh -t поможет также, когда вы хотите, например одной командой снаружи подключится к шлюзу во внутренней сети, а с него уже к какой-то машине в сети:
ssh -t gateway_at_work ssh workstation
З.Ы. у ssh есть еще куча прекрасных возможностей :) Не забывайте про ssh-copy-id, reversed forwarding и т.п.
Updated:
По просьбам пользователей, добавлю сюда про передачу файлов с помощью scp
Утилита scp входит в состав пакета openssh и предназначена для удаленного копирования файлов через ssh-соединение.
Примеры использования scp:
| 1 2 3 |
scp /directory/some_file user@remote_host:/remote/directory # Копирует файл some_file на удаленную машину remote_host в папку /remote/directory |
Для передачи множества мелких файлов, лучше их предварительно за-tar-ить:
tar czf - /path/to/files | ssh user@remote_host "cat > /path/data.tgz"
эта команда передаст в ssh уже заархивированную папку.
scp использует опции .ssh/config поэтому если у вас там прописаны настройки хоста, к примеру work, то команда копирования выглядит очень просто:
scp /local/file work:~/
она скопирует локальный файл /local/file в домашнюю папку пользователя, который прописан для хоста work в .ssh/config
Updated2:
sshfs
Alex2ndr в коментариях дополнил про использование sshfs для монтирования папок с удаленного хоста по ssh:Про sshfs можно уложиться так:
| 1 2 3 |
sudo aptitude install sshfs #ну или как-там в иных дистрах |
