А давайте подружимся с SSH?

А давайте подружимся с SSH?

Многие мои знакомые так или иначе используют протокол SSH (заходя на свои роутеры, веб хостинги и непосредственно на собственные компьютеры дома и в офисе), при этом не все об этом знают.

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

В этой заметке вы узнаете:

* как прописать псевдонимы для соединений
* как настроить авторизацию без пароля
* как передавать файлы по SSH
* как запускать графические приложения по SSH
* а так же получите общие советы по опциям SSHD

Используем псевдонимы

Чтобы подключиться к удаленному компьютеру или роутеру, можно воспользоваться клиентом ssh, который есть во всех популярных операционных системах, будь то Linux или MacOSX. Вам необходимо знать IP адрес или хостнейм машины, к которой будете подключаться, порт, который прослушивает SSH демон (sshd, по умолчанию 22), а так же актуальные логин и пароль, под которыми разрешено подключение.



далее все действия на клиенте

Согласитесь, ssh -l babl -p 22 babl.starlink.ru команда довольно длинная и даже более короткий вариант ssh [email protected] не делает ее более приятной, когда приходится по несколько раз в день заходить на одни и те же компьютеры.

Создадим (если его нет) файл ~/.ssh/config со следующим содержимым:




Выполняем:



Итого задачу себе немного упростили. Что можно сделать дальше? Согласитесь, вводить пароль каждый раз при попытке войти на один и тот же компьютер — занятие радости доставляющее не так много, как хотелось бы.

Авторизация по ключу

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

Для начала проверим необходимые опции:
на клиенте (/etc/ssh/ssh_config):



на сервере (/etc/ssh/sshd_config):



Лирическое отступление

Стоит так же обратить внимание на такие параметры sshd_config:

PermitRootLogin no - разрешить пользователю root логиниться по SSH. Лучше запретить, так как действительно права рута нужны не так часто, а повысить свои привилегии можно с помощью того же sudo. К тому же в этом случае имя пользователя так же для злоумышленника будет загадкой, а root стандартен везде.
На крайняк можно описать следующую конструкцию:



В этом случае рут сможет залогиниться только из указанных подсетей.

PermitEmptyPasswords no - разрешить использовать пустые пароли. Так же плохой вариант, фактически пустой пароль сводит всю защиту на нет, так что и разрешать его в общем-то не стоит.

AllowUsers - указывает список пользователей, под которыми можно входить по SSH. Крайне рекомендую использовать эту опцию! Если ее нет в конфиге - создайте. AllowUsers babl,vasya

Port - указывает прослушиваемый демоном SSHD порт. Стандартный 22, первый в списке искомых злоумышленником. Советую сменить его на что-то выходящее за пределы 1024 или еще лучше, за пределы 10000. К примеру поставить 33333, легко запоминается, а вот nmapом фиг достанешь.

создадим ключ командой ssh-keygen -t rsa



Итак, введя ssh-keygen -t rsa и ответив на несколько простых вопросов, мы создали публичный ключ нашего клиента: /home/babl/.ssh/id_rsa.pub. Теперь необходимо этот ключ запихнуть на сервер в домашнюю директорию пользователя, под которым мы логинимся, в файл ~/.ssh/authorized_keys. Путей это сделать множество, но я настоятельно рекомендую использовать скрипт ssh-copy-id, как правило входит в пакет openssh-client.



Проверяем:



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

Подводные камни

Часто бывает что вместо заветного входа в удаленную систему, Вы получаете все тот же запрос на ввод пароля. Что следует делать в этом случае?
1. не паниковать.
2. запустить с клиента:
ssh -v [email protected]
и посмотреть полный вывод попытки установить соединение.



Опа… ключик то послали, а сервер отверг, сказал пошли дальше пробовать и вводи ка пароль, парень!

Идем на сервер, смотрим /var/log/auth.log



и понимаем, что SSH демон довольно параноидальный и заботится о том, чтобы соединение по ключу было доступно ТОЛЬКО нужному пользователю. Внимательно осматриваем права доступа к домашней папке и непосредственно к файлам в ~/.ssh и видим, к домашней папке, к примеру, есть права на запись у всех — ssh это не понравилось и демон отверг вход по ключу, посчитав его небезопасным. Выставляем стандартные права 0755 и вуаля:



все работает!

На всякий случай, корректные права:



Работаем с файлами по SSH

Я встречал людей, которые держат веб или фтп серверы для того, чтобы периодически кидать себе домой несколько файлов или же забирать их оттуда. При этом они по SSH копируют файл в веб/фтп папки и потом скачивают их браузером или wget'ом, но ведь все можно сделать гораздо проще… Если Вы делаете так же — этот пункт для Вас!

Приложение scp входит в комплект openssh-client и работает по своей сути как и программа cp, но при этом позволяет использовать SSH адреса. Рассмотрим пример:



Я скачал на ноутбук 2 файла, которые находятся по адресам:
/mnt/gtb12,avi
/mnt/gtb13,avi
на моем домашнем компьютере. При этом /mnt не смотрит в веб или фтп, но у пользователя babl есть к нему доступ и права на чтение этих файлов. Другими словами Вы можете получить любой файл, к которому может дотянуться Ваш пользователь на целевой системе, указав адрес вида:
login@host:/путь_к_файлу

С учетом того, что мы сделали ранее (авторизация без ключа и прописанный псевдоним) — все становится совсем просто



Замечательная возможность приложения состоит еще и в том, что SSH адрес можно указать не только в качестве источника, но и в качестве назначения. Так же часто используемой опцией может стать -r, позволяющая (с/за)качивать рекурсивно папки со всем их содержимым.

Перенаправляем Х11 приложения

На сервере в /etc/ssh/sshd_config подключаем следующую опцию:



Теперь введя на клиенте:



мы увидим окно редактора kate (пример чисто символический, можно было вызвать и gedit и даже eclipse), который физически будет работать на хосте bbh (домашний компьютер), но отображаться у нас на ноутбуке. Так можно поступить практически с любым графическим приложением, полезно бывает.

Извращаемся

SSH поистине может творить чудеса! Так как клиент может выполнять приложения на удаленном сервере и при этом напрямую передавать в них поток — открываются большие возможности для управления всем чем угодно. Вот несколько примеров, буду рад если пригодятся в жизни, но их основная задача — показать что есть куда копать и стоит это делать.

Упаковываем директорию и копируем на удаленный хост с распаковкой, все это происходит налету и без использования scp:



и на локальный:



так же можно было дописать свой rsa ключ на сервер не с помощью ssh-copy-id, а выполнив:



P.S.: Желаю удачи в освоении таких сложных на первый взгляд и таких полезных на второй утилит, как SSH.

и особенно популярной виндовс

а что это за система такая?
в виндовс есть ни разу небезопасный telnet, хотя МС так не считает.
еще есть сторонняя разработка PuTTY (клиент)

SSH под виндой прекрасно существует. Сам юзал winsshd пару лет назад, когда надо было через виндовую машину ходить на линуксовый шлюз. . А список SSHd под винду вот _http://www.sysadmin.m...r-windows.html