Как создать ключ для авторизации по SSH и добавить его на сервер?
SSH-ключи используются для идентификации клиента при подключении к серверу по SSH-протоколу. Используйте этот способ вместо аутентификации по паролю.
SSH-ключи представляют собой пару — закрытый и открытый ключ. Закрытый должен храниться в закрытом доступе у клиента, открытый отправляется на сервер и размещается в файле authorized_keys.
Создание SSH-ключей в Linux на примере CentOS
На клиентской стороне должен быть установлен пакет ssh (openssh). На серверах FirstVDS с шаблонами по умолчанию необходимое ПО уже установлено.
yum -y install openssh-server openssh-clients
На клиентском компьютере в командной строке выполните команду генерации ключей:
ssh-keygen
Введите путь файла, в который будут помещены ключи. Каталог по умолчанию указан в скобках, в примере /домашний_каталог/.ssh/id_rsa. Если хотите оставить расположение по умолчанию, нажмите Enter.
Пароль (passphrase) используется для ограничения доступа к закрытому ключу. Пароль усложнит использование ключа третьими лицами в случае утраты. Если не хотите использовать секретную фразу, нажмите Enter без заполнения строки.
Успешно сгенерировав пару ключей, вы увидите уведомление:
Открытый ключ хранится в файле /домашний_каталог/.ssh/id_rsa.pub
/домашний_каталог/.ssh/id_rsa.
Скопируйте открытый ключ на сервер в файл /домашний_каталог/.ssh/authorized_key. Одной строкой:
cat ~/.ssh/id_rsa.pub | ssh root@ip-адрес-сервера %22cat >> ~/.ssh/authorized_keys%22
Или откройте этот файл на сервере редактором vi и вставьте строку с открытым ключом после ssh-rsa.
Ещё один способ скопировать ключ в authorized_keys — команда echo, которая помещает строку в конец файла.
echo ssh-rsa строка-публичного-ключа >> /root/.ssh/authorized_keys
Теперь можно отключить на сервере аутентификацию по паролю и использовать только SSH-ключи.
Создание SSH-ключей на Windows с PuTTYgen
Если вы используете ОС Windows, то подключиться по SSH к вашему (Linux) серверу можно через PuTTY или OpenSSH. Генерация ключей в этом случае выполняется также при помощи этих программ. В примере мы используем клиент PuTTY.
Запустите приложение PuTTYgen, которое устанавливается вместе с PuTTY.
Выберите тип ключа SSh3-RSA и нажмите Generate.
В процессе генерации ключей несколько раз произвольно проведите мышкой по экрану приложения для создания случайных величин, используемых для ключей.
После завершения создания ключей открытый ключ выводится на экран, закрытый хранится в памяти приложения. Чтобы сохранить эти ключи нажмите Save public key и Save private key. Укажите расположение файлов с ключами.
При сохранении закрытого ключа, если не заполнено поле Key passphrase, появится запрос «Хотите ли вы сохранить ключ без секретной фразы?»
Теперь открытый ключ необходимо скопировать на сервер в файл authorized_keys. Используйте WinSCP или другой клиент для работы с файлами на удалённом Linux-сервере. Вы можете скопировать файл с открытым ключом целиком на сервер, чтоб его копия хранилась в папке .ssh
Откройте файл authorized_keys через WinSCP и файл, в который вы сохранили открытый ключ (public), на локальном компьютере текстовым редактором. Скопируйте значение ключа, сохраните и закройте файл в WinSCP.
При запуске PuTTY укажите путь к закрытому ключу на локальном компьютере. Для этого во вкладке Connections → Auth выберите необходимый путь.
Теперь можно отключить на сервере аутентификацию по паролю и использовать только SSH-ключи.
Отключение аутентификации по паролю
Подключитесь к серверу по SSH, используя пароль, и откройте файл sshd_config для редактирования.
vi /etc/ssh/sshd_config
Убедитесь, что указан правильный путь к открытым ключам SSH, поставьте значение параметра PasswordAuthentication no.
Перезапустите службу sshd.
service sshd restart
Подключитесь к серверу по SSH без использования пароля. Например, запустите PuTTY, проверьте, что во вкладке Connections -> Auth содержится путь к закрытому ключу и откройте подключение.
В случае успешной аутентификации по SSH-ключу вы получите доступ к командной строке сервера и сообщение вида
firstvds.ru
Авторизация по ключу SSH | Losst
SSH или Secure Shell — это зашифрованный протокол, который часто используется для взаимодействия и удаленного управления серверами. Если вы захотите что-либо сделать на удаленном сервере, скорее всего, вам придется воспользоваться SSH и работать через терминал.
В SSH существует несколько способов авторизации. Вы можете каждый раз вводить пароль пользователя или использовать более безопасный и надежный способ — ключи SSH. Что самое интересное, он более удобен для применения, вам даже не нужно будет вводить пароль. В этой статье мы рассмотрим как настраивается авторизация по ключу SSH.
Содержание статьи:
Как работают ключи SSH?
SSH сервер может выполнять аутентификацию пользователей с помощью различных алгоритмов. Самый популярный — это аутентификация по паролю. Он достаточно прост, но не очень безопасный. Пароли передаются по безопасному каналу, но они недостаточно сложны для противостояния попыткам перебора. Вычислительная мощность современных систем в сочетании со специальными скриптами делают перебор очень простым. Конечно, существуют другие способы дополнительной безопасности, например, fail2ban, но аутентификация по ключу SSH более надежна.
Каждая пара ключей состоит из открытого и закрытого ключа. Секретный ключ сохраняется на стороне клиента и не должен быть доступен кому-либо еще. Утечка ключа позволит злоумышленнику войти на сервер, если не была настроена дополнительная аутентификация по паролю.
Открытый ключ используется для шифрования сообщений, которые можно расшифровать только закрытым ключом. Это свойство и используется для аутентификации с помощью пары ключей. Открытый ключ загружается на удаленный сервер, к которому необходимо получить доступ. Его нужно добавить в специальный файл ~/.ssh/authorized_keys.
Когда клиент попытается выполнить проверку подлинности через этот ключ, сервер отправит сообщение, зашифрованное с помощью открытого ключа, если клиент сможет его расшифровать и вернуть правильный ответ — аутентификация пройдена.
Как создать ключи SSH?
Сначала необходимо создать ключи ssh для аутентификации на локальном сервере. Для этого существует специальная утилита ssh-keygen, которая входит в набор утилит OpenSSH. По умолчанию она создает пару 2048 битных RSA ключей, которая подойдет не только для SSH, но и для большинства других ситуаций.
И так, генерация ключей ssh выполняется командой:
ssh-keygen
Утилита предложит вам выбрать расположение ключей. По умолчанию ключи располагаются в папке ~/.ssh/. Лучше ничего не менять, чтобы все работало по умолчанию и ключи автоматически подхватывались. Секретный ключ будет называться id_rsa, а публичный id_rsa.pub.
Затем утилита предложит ввести пароль для дополнительного шифрования ключа на диске. Его можно не указывать, если не хотите. Использование дополнительного шифрования имеет только один минус — необходимость вводить пароль, и несколько преимуществ:
- Пароль никогда не попадет в сеть, он используется только на локальной машине для расшифровки ключа. Это значит что перебор по паролю больше невозможен.
- Секретный ключ хранится в закрытом каталоге и у клиента ssh нет к нему доступа пока вы не введете пароль;
- Если злоумышленник хочет взломать аутентификацию по ключу SSH, ему понадобится доступ к вашей системе. И даже тогда ключевая фраза может стать серьезной помехой на его пути.
Но все же, это необязательное дополнение и если не хотите, то вы можете просто нажать Enter. Тогда доступ по ключу ssh будет выполняться автоматически и вам не нужно будет что-либо вводить.
Теперь у вас есть открытый и закрытый ключи SSH и вы можете использовать их для проверки подлинности. Дальше нам осталось разместить открытый ключ на удаленном сервере.
Загрузка ключа на сервер
Когда генерация ключей завершена, нам осталось только загрузить ключ на сервер. Для загрузки ключа можно использовать несколько способов. В некоторых случаях вы можете указать ключ в панели управления сервером, например, сPanel или любой другой. Но мы такой способ рассматривать не будем. Мы рассмотрим ручные способы.
Самый простой способ скопировать ключ на удаленный сервер — это использовать утилиту ssh-copy-id. Она тоже входит в пакет программ OpenSSH. Но для работы этого метода вам нужно иметь пароль доступа к серверу по SSH. Синтаксис команды:
ssh-copy-id username@remote_host
При первом подключении к серверу система может его не распознать, поэтому вам нужно ввести yes. Затем введите ваш пароль пользователя на удаленном сервере. Утилита подключится к удаленному серверу, а затем использует содержимое ключа id.rsa.pub для загрузки его на сервер в файл ~/.ssh/authorized_keys. Дальше вы можете выполнять аутентификацию с помощью этого ключа.
Если такой способ по какой-либо причине для вас не работает, вы можете скопировать ключ по ssh вручную. Мы создадим каталог ~/.ssh, а затем поместим наш ключ в файл authorized_keys с помощью символа >>, это позволит не перезаписывать существующие ключи:
cat ~/.ssh/id_rsa.pub | ssh username@remote_host "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"
Здесь вам тоже нужно набрать yes, если вы подключаетесь к новому серверу, а затем ввести пароль. Теперь вы можете использовать созданный ключ для аутентификации на сервере:
ssh username@remote_host
Если вы не захотели создать ssh ключ с доступом по паролю, то вы сразу же будете авторизованы, что очень удобно. Иначе, сначала вам придется ввести фразу-пароль для расшифровки ключа.
Отключение проверки пароля
Если пароль больше не будет использоваться, то для увеличения безопасности системы лучше его вовсе отключить. Но убедитесь, что ключ надежно сохранен и вы его не потеряете, потому что по паролю вы больше не войдете. Авторизуйтесь на сервере, затем откройте конфигурационный файл /etc/ssh/sshd_config и найдите там директиву PasswordAuthenticatin. Нужно установить ее значение в No:
sudo vi /etc/ssh/sshd_config
PasswordAuthentication no
Теперь сохраните файл и перезапустите службу ssh:
sudo service ssh restart
Дальше будет возможно только подключение по ключу ssh, пароль не будет приниматься.
Выводы
В этой статье мы рассмотрели как выполняется авторизация по ключу ssh, настройка ключей ssh и добавить ssh ключ. Теперь вы можете войти на сервер без ввода пароля. Если у вас остались вопросы, спрашивайте в комментариях!
losst.ru
Как сгенерировать ssh ключ
HI, сегодня я продолжу тему админства и расскажу как сгенерировать свой ssh ключ для подключения к vds серверу.
Что такое ssh ключ
SSH ключ позволяет более безопасно подключаться к вашему веб серверу и передавать все ваши данные в шифрованном виде. В отличие от обычной авторизации по паролю, SSH-ключи практически невозможно подобрать с помощью перебора паролей (brunforse).
Создание ssh ключа представляет из себя соединение двух длинных символьных строк. Одна из строк является открытым ключем, вторая закрытым. Открытый ключ вы размещаете на сервере к которому подключаетесь, а закрытый ключ храниться у вас на локальной машине или в облаке. Закрытый ключ используется при подключении к вашему серверу, он указывается при выборе настроек подключения в вашем клиенте. Когда эти ключи совпадают, система разблокируется без необходимости ввода пароля. Так же для повышения безопасности вашего ключа можно задать парольную фразу вашему закрытому ключу.
Создание ssh ключа на windows
Для Windows есть простой и быстрый способ получить ssh ключи. Для этого я как правило использую PuTTY. В комплекте с этой программой устанавливается и нужный нам генератор ключа. Скачать его можно с официального сайта putty (он будет в комплекте) либо по ссылке.
Открыв данную программу вы увидите простой и понятный интерфейс. Теперь чтобы сгенерировать ssh ключи нужно выбрать тип генерации RSA (первый в списке внизу) и нажать кнопку Generate. После чего PuTTY попросит вас поводить по пустой области экрана курсором чтобы псевдослучайно сгенерировать строки ключа.
После этого вам станут доступны 2 кнопки: Save public key и Save priate key. Они дают возможность сохранить файлы с ключами на компьютер.
Сохраните их, они понадобятся в дальнейшем для авторизации на сервере. В основном поле программы показан сгерерированый нами публичный ключ, его вы можете вставить в такое же текстовое поле у вашего хостинг провайдера если он предоставляет возможность подключаться по ssh. В дальнейшем для подключения к вашему серверу понадобиться только файл с приватным ключем.
Создание ssh ключа на Linux/MacOS
Для того чтобы создать ssh ключ вам понадобиться открыть терминал и выполнить следующую команду:
ssh-keygen -t rsa
После чего вам предложат выбрать местоположение для ваших ключей. Вы можете задать собственное, а можете просто нажать на Enter. Так же эта программа попросит вас придумать специальную парольную фразу для дополнительной защиты, этот этап можно так же пропустить.
После указания пути для файлов вы увидите примерно следующий ответ от программы:
Your identification has been saved in /home/-имяпользователя-/.ssh/id_rsa.
Your public key has been saved in /home/-имяпользователя-/.ssh/id_rsa.pub.
Вот так быстро и просто можно сгенерировать ssh ключ на Unix системах.
Как подключиться к серверу используя ssh
Если же ваш хостинг провайдер позволяет вставить публичный ssh ключ (это тот что id_rsa.pub) в веб интерфейсе, то вам не придется делать лишних телодвижений. После добавления ключа таким способом вы сможете подключаться к серверу просто указав при подключении приватный ключ (это то что id_rsa).
Если же нет то вы должны проделать следующие шаги:
- Подключиться к вашему серверу по FTP под своим пользователем, как правило это root.
- Зайти в директорию вашего пользователя и создать там папку под названием .ssh (если таковой не будет).
- Скачать в эту папку ваш публичный ключ который вы уже сгенерировали ранее.
- Переименовать данный файл на authorized_keys
После выполнения данных действий вы сможете подключаться к вашему серверу по ssh, указав в качестве логина имя пользователя в папке которого вы создавали директорию .ssh и так же указав ваш приватный ключ.
Пример такой команды в UNIX системах:
Так же я настоятельно советую вам отключить возможность авторизоваться на вашем сервере от имени root пользователя используя пароль. Отключив эту возможность единственный оставшийся способ подключения к нему будет только по SSH.
Перейдите в директорию основных настроек ssh:
sudo nano /etc/ssh/sshd_config
В этом файле найдите следующую строку PremitRootLogin и измените для нее значение на PremitRootLogin without-password
После сохранения файла перезагрузите ssh следующей командой:
service ssh reload
Способы подключения через GUI
Вот примеры того как можно подключаться к серверу используя ssh:
Используя популярный и кроссплатформенный ftp клиент Filezilla.
Используя программу ZOC Terminal
Через ещё один популярный кроссплатформенный клиент PuTTY
На этом можно завершать мой рассказ о генерации ssh ключа для доступа к серверу.
До скорого и удачи!
dmkweb.ru Права на контент защищены.dmkweb.ru
Памятка пользователям ssh / Habr
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 [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).
Возможность копировать здорово. Но хочется так, чтобы «сохранить как» — и сразу на сервер. И чтобы в графическом режиме копировать не из специальной программы, а из любой, привычной.
Так тоже можно:
Теория: модуль 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 [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).
По подсказке UUSER: вы можете указать настройки соединения по умолчанию с помощью конструкции Host *, т.е., например:
Host * User root Compression yes
То же самое можно сделать и в /etc/ssh/ssh_config (не путать с /etc/ssh/sshd_config), но это требует прав рута и распространяется на всех пользователей.
Собственно, немножко я проспойлерил эту часть в примере конфига выше. 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-трафика.
Когда я оказываюсь в очередной гостинице (кафе, конференции), то местный 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 [email protected]
Опция -R позволяет перенаправлять с удалённого (Remote) сервера порт на свой (локальный).
Важно: если мы хотим использовать адрес 8.8.8.8, то нам нужно разрешить GatewayPorts в настройках сервера Б.
Задача. На сервере «Б» слушает некий демон (допустим, sql-сервер). Наше приложение не совместимо с сервером (другая битность, ОС, злой админ, запрещающий и накладывающий лимиты и т.д.). Мы хотим локально получить доступ к удалённому localhost’у.
Итоговая конфигурация: запросы на localhost:3333 на ‘A’ должны обслуживаться демоном на localhost:3128 ‘Б’.
ssh -L 127.1:3333:127.1:3128 [email protected]
Опция -L позволяет локальные обращения (Local) направлять на удалённый сервер.
Задача: На сервере «Б» на сером интерфейсе слушает некий сервис и мы хотим дать возможность коллеге (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» не отличим от обычного трафика компьютера А.
Если к этому моменту попа отдела безопасности не сияет лысиной, а 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-ключ, который бы авторизовывал [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-сервера и т.д.
Разумеется, в посте про туннели должен быть туннель, а в любой успешной статье — секретный ингредиент всеобщей популярности. Держите:
habr.com
Как сгенерировать SSH-ключ для доступа на сервер – Vscale Community
Использование SSH-ключей —простой и надёжный способ обеспечения безопасности соединения с сервером. В отличие от пароля, взломать SSH-ключ практически невозможно. Сгенерировать SSH-ключ очень просто.
Linux/MacOS
Откройте терминал и выполните команду:
$ ssh-keygen -t rsa
На консоль будет выведен следующий диалог:
Enter file in which to save the key (/home/user/.ssh/id_rsa):
Нажмите на клавишу Enter. Далее система предложит ввести кодовую фразу для дополнительной защиты SSH-подключения:
Enter passphrase (empty for no passphrase):
Этот шаг можно пропустить. При ответе на этот и следующий вопрос просто нажмите клавишу Enter.
После этого ключ будет создан, а на консоль будет выведено следующее сообщение:
Your identification has been saved in /home/user/.ssh/id_rsa.
Your public key has been saved in /home/user/.ssh/id_rsa.pub.
The key fingerprint is:
476:b2:a8:7f:08:b4:c0:af:81:25:7e:21:48:01:0e:98 user@localhostThe key's randomart image is:
+--[ RSA 2048]----+
|+.o. |
|ooE |
|oo |
|o.+.. |
|.+.+.. S . |
|....+ o + |
| .o .... |
| . .. . |
| .... |
+-----------------+
Далее выполните в терминале команду:
$ cat ~/.ssh/id_rsa.pub
На консоль будет выведен ключ. Скопируйте его и вставьте в соответствующее поле:
Нажмите на кнопку “Добавить.”
Добавив ключ, выполните в терминале команду:
$ ssh root@[IP-адрес сервера]
После этого соединение с сервером будет установлено. Вводить пароль при этом не потребуется.
Windows
В OC Windows подключение к удаленным серверам по SSH возможно, например, с помощью клиента Putty. Скачать его можно здесь (ссылка взята с официального сайта). Putty не требует установки — чтобы начать с ним работать, достаточно просто распаковать скачанный архив.
По завершении распаковки запустите файл puttygen.exe.
Выберите тип ключа SSH-2 RSA и длину 2048 бит, а затем нажмите на кнопку Generate:
Во время генерации водите курсором в пустой области окна (это нужно для создания псевдослучайности):
Сохраните сгенерированную пару ключей на локальной машине (кнопки Save public key и Save private key).
Скопируйте сгененированный ключ и вставьте его в соответствующее поле:
tglnkSSH
community.vscale.io
Использование putty и ssh ключей в Windows / Habr
Так как приходиться уже не первый раз объяснять как это делается, решил оформить в виде How-To в картинкахСкачиваем архив putty отсюда putty.zip
1. Распаковываем и запускаем ssh-keygen
Выбираем ключ ssh-rsa и длину 2048 бит. Жмем «Generate».
Ключ готов, заполняем кодовую фразу и комментарий к нему. Сохраняем приватный ключ как mykey.ppk и публичный как id_rsa.pub
2. Далее необходимо скопировать наш публичный ключ на сервер. Для этого запускаем psftp.
psftp: no hostname specified; use «open host.name» to connect
psftp> open myserver
The server’s host key is not cached in the registry. You
have no guarantee that the server is the computer you
think it is.
The server’s rsa2 key fingerprint is:
ssh-rsa 2048 XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX
If you trust this host, enter «y» to add the key to
PuTTY’s cache and carry on connecting.
If you want to carry on connecting just once, without
adding the key to the cache, enter «n».
If you do not trust this host, press Return to abandon the
connection.
Store key in cache? (y/n) y
login as: root
root@myserver’s password:
Remote working directory is /root
psftp>put id_rsa.pub /tmp/id_rsa.pub
local:id_rsa.pub => remote:/tmp/id_rsa.pub
psftp>
3. Ключ скопировался, теперь нужно добавить его в /root/.ssh/authorized_keys
Для этого логинимся еще раз по паролю, через putty и выполняем
ssh-keygen -i -f /tmp/id_rsa.pub >> /root/.ssh/authorized_keys
Теперь осталось добавить наш ключ в ssh-agent’a. После запуска он сидит в трее, чтобы добавить ключ кликаем правой кнопкой на «Add Key»
Вводим кодовую фразу:
Теперь логинимся в putty:
login as: root Authenticating with public key "rsa-key-20080908" from agent
Практически все, чтобы устранить проблемы с кодировками, с кривым отображением mc в путти, исправляем локаль в настроках:
habr.com
Аутентификация на SSH сервере с помощью ключей
Подключаясь к SSH серверу есть возможность использовать для авторизации использовать пару приватный/публичный ключ вместо логин пароль.
В данной статье описано, как создать приватный и публичный ключ, а также настроить OpenSSH сервер для использования ключа вместо пароля.
Создание приватного и публичного ключа
Приватный и публичный ключи, которые в дальнейшем будут использоваться для авторизации, можно создать с помощью ssh-keygen:
mydesktop$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/xahria/.ssh/id_rsa):
Enter passphrase (empty for no passphrase): (enter passphrase)
Enter same passphrase again: (enter passphrase)
Your identification has been saved in /home/xahria/.ssh/id_rsa.
Your public key has been saved in /home/xahria/.ssh/id_rsa.pub.
The key fingerprint is:
2c:3f:a4:be:46:23:47:19:f7:dc:74:9b:69:24:4a:44 xahria@mydesktop
mydesktop$ cd $HOME/.ssh
mydesktop$ ls -l
-rw------- 1 xahria hatchclan 883 Jan 21 11:52 id_rsa
-rw-r--r-- 1 xahria hatchclan 223 Jan 21 11:52 id_rsa.pub
mydesktop$ cat id_rsa
-----BEGIN RSA PRIVATE KEY-----
MIICWgIBAAKBgQCc+1oixZ/g84gpZH0NeI+CvVoY5O0FOCSpFCbhUGJigQ6VeKI5
gpOlDztpJ1Rc+KmfZ2qMaftwwnLmefhk1wPcvfZvvLjfdmHY5/LFgDujLuL2Pv+F
7tBjlyX9e9JfXZau2o8uhBkMbb3ZqYlbUuuoCAnUtL5uZUiiHM0BAtnGAd6epAYE
gBHw1xnqsy+mzbuWdLEVF7crlUSsctwGapb6/SEQgEXFm0RITQ3jCY808NjRS3hW
Z+uCCO8GGUsn2bZpcGXa5vZzACvZL8epJoMgQ4D0T50rAkEA0AvK4PsMF02Rzi4E
mXgzd1yCa030LYR/AkApG1KT//9gju6QCXlWL6ckZg/QoyglW5myHmfPR8tbz+54
/lj06BtBA9iag5+x+caV7qKth2NPBbbUF8Sbs/WI5NYweNoG8dNY2e0JRzLamAUk
jK2TIwbHtE7GoP/Za3NTZJm2Ozviz8+PHPIEyyt9/kzT0+yo3KmgsstlqwIBIwKB
XdBh52izEWsWpXf9t4So0upV1DEcjq8CQQDEKGAzNdgzOoIozE3Z3thIjrmkimXM
J/Y3xQJBAMEqZ6syYX/+uRt+any1LADRebCq6UA076Sv1dmQ5HMfPbPuU9d3yOqV
j0Fn2H68bX8KkGBzGhhuLmbrgRqr3+SPM/frUj3UyYxns5rnGspRkGB3AkALCbzH
9EAV8Uxn+Jhe5cgAC/hTPPdiwTJD7MpkNCpPuKRwrohytmNAmtIpKipAf0LS61np
wtq59ssjBG/a4ZXNn32n78DO0i6zVV5vwf8rv2sf
-----END RSA PRIVATE KEY-----
mydesktop$ cat id_rsa.pub
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAcMJy5nn4ZNcD3L32b7y433Zh3IEAnPt
aIsWf4POIKWR9DXiPgr1aGOTtBTgkqRQm4VBiYoEOlXiiOYKTpQ87aSdUXPipn
2dqjGn7OfyxYA7oy7i9j7/hYytkyMGx7ROxqD/2WtzU2SZtjs74s/PjxzyBMsr
ff5M09PsqNypoLLLZas= xahria@mydesktop
Обратите внимание, что ‘ssh-rsa…xahria@mydesktop’ это одна строка, а не несколько.
ssh-keygen создал два файла: id_rsa и id_rsa.pub. В первом файле хранится приватный ключ, защищенный кодовой фразой, введенной при создании. Этот ключ никогда не должен передаваться кому-либо. Файл id_rsa.pub — публичный ключ. Публичный ключ вы передаете тому, кто должен иметь возможность проверить вашу подпись. В данном случае мы будем размещать публичный ключ на сервере, доступ к которому нам нужен.
Название файла можно изменить, используя опцию -f filename. Если Вы не определили имя файла, то ключи будут записаны в каталог $HOME/.ssh/ с именем id_rsa
Включение Pubkey аутентификации на сервере
После того, как мы создали ключи, необходимо разрешить данный тип аутентификации на сервере SSH. Сначала определим тип аутентификации — Pubkey или Identity, установив следующие настройки в sshd_config:
# Should we allow Identity (SSH version 1) authentication? RSAAuthentication yes # Should we allow Pubkey (SSH version 2) authentication? PubkeyAuthentication yes # Where do we look for authorized public keys? # If it doesn't start with a slash, then it is # relative to the user's home directory AuthorizedKeysFile .ssh/authorized_keys
Приведенные выше значения разрешают аутентификацию Identity/Pubkey для протокола SSH версии 1 и 2, и проверяют наличие публичных ключей в файле $HOME/.ssh/authorized_keys.
Проверьте наличие этих строк в файле конфигурации sshd_config (обычно он находится в каталоге /etc/ssh/), при необходимости добавьте и перезапустите сервис.
Добавление на сервер публичного ключа
Прядок действий следующий:
- Создаем файл authorized_keys в каталоге ~/.ssh.
- Добавляем публичный ключ RSA в конец файла authorized_keys.
- Проверяем, устанавливаем права доступа и выходим.
Содержимое файла authorized_keys
Файл authorized_keys просто содержит список ключей, по одному в строке. В него мы и пропишем ключ, сгенерированный на своей машине.
# Copy the RSA Pubkey to the server using scp. # You can use any method you like, including using # copy/paste if it's convenient. mydesktop$ cd $HOME/.ssh mydesktop$ scp id_rsa.pub ssh-server:id_rsa_mydesktop.pub xahria@ssh-server's password: (enter password) # Now let's log in and create the authorized_keys file mydesktop$ ssh ssh-server xahria@ssh-server's password: (enter password) # Create the .ssh dir if it doesn't already exist ssh-server$ mkdir .ssh ssh-server$ chmod 700 .ssh ssh-server$ cd .ssh # Concatenate the RSA Pubkey we just uploaded to # the authorized_keys file. (This will create # if it doesn't already exist.) ssh-server$ cat ../id_rsa_mydesktop.pub >> authorized_keys # Let's check out the file ssh-server$ cat authorized_keys ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAcMJy5nn4ZNcD3L32b7y433Zh3IEAnPt aIsWf4POIKWR9DXiPgr1aGOTtBTgkqRQm4VBiYoEOlXiiOYKTpQ87aSdUXPipn 2dqjGn7OfyxYA7oy7i9j7/hYytkyMGx7ROxqD/2WtzU2SZtjs74s/PjxzyBMsr ff5M09PsqNypoLLLZas= xahria@mydesktop # Make sure permissions are paranoid ssh-server$ chmod 600 authorized_keys # Excellent, let's log out. ssh-server$ exit
Можно проверить. что все работает:
mydesktop$ ssh ssh-server Enter passphrase for key '/home/xahria/.ssh/id_rsa':
Ваш SSH клиент сначала попробует пройти аутентификацию по Pubkey/Identity, а в случае неудачи — идентификацию по паролю. Он будет искать ключ в именах файлов, заданных по умолчанию, если Вы не указали ключа явно.
Как происходит процесс подключения по шагам:
- /usr/bin/ssh соединяется с сервером на порт SSH
- Клиент и сервер обмениваются ключами, определяется алгорит м шифрования
- Клиент ищет файлы, по умолчанию испрользуемые Pubkey/Identity
- Если один из таких файлов был найден, то посылается публичный ключ на сервер и запрашивается аутентификация по этому ключу
- Сервер проверяет файл authorized_keys пользователя на наличие публичного ключа и посылает клиенту последовательность, зашифрованную открытым ключом . Если приватный ключ защищен кодовым словом, то /usr/bin/ssh просит его ввести для дешифровки приватного ключа.
- Клиент расшифровывает посланную последовательность для подтверждения правильности публичного и приватного ключей
- Если расшифровка удалась, то сервер пускает клиента без запроса пароля Unix
- Если клиент не может доказать, что это имеет ключ, то он может предложить другие ключи
- При отсутствии корректных ключей пользователю будет предложено авторизоваться с помощью авторизации Unix
Все это проходит незаметно для пользователя. Если Вы хотите наблюдать за фазами соединения, то используйте ключ -v:
mydesktop$ ssh ssh-server OpenSSH_3.8.1p2, SSH protocols 1.5/2.0, OpenSSL 0x009060cf ... debug1: identity file /home/xahria/.ssh/identity type 0 debug1: identity file /home/xahria/.ssh/id_rsa type 1 debug1: Remote protocol version 1.99, remote software version OpenSSH_3.7.1p2 ... debug1: SSh3_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,password,keyboard-interactive debug1: Next authentication method: publickey debug1: Offering public key: /home/xahria/.ssh/id_rsa debug1: Server accepts key: pkalg ssh-rsa blen 149 lastkey 0x601d0 hint 1 debug1: PEM_read_PrivateKey failed debug1: read PEM private key done: type Enter passphrase for key '/home/xahria/.ssh/id_rsa': (Enter wrong passphrase) debug1: PEM_read_PrivateKey failed debug1: Next authentication method: keyboard-interactive debug1: Authentications that can continue: publickey,password,keyboard-interactive debug1: Next authentication method: password xahria@ssh-server's password: (Enter Unix password)
Для наглядности, в этом примере мы вводим неправильное кодовое слово для дешифровки приватного ключа. Также Вы можете заметить, что были найдены файлы identity и id_rsa, хотя они могут использоваться только с SSHv2.
Выбор ключей
Если Вы имеете один ключ для каждого типа, то вы можете использовать стандартные имена файлов и ssh-клиент самостоятельно найдет их и использует, но может так случиться, что Вы используете для аутентификации разные файлы:
- У Вас есть персональный ключ и ключ группы(например, административный), для различных хостов и пользователей. У Вас слишком большой список ключей и сервер отбрасывает вас из-за превышения числа попыток авторизации. Вы хотите использовать специальный ключ, потому как связали с ним специфические особенности — такие как предоставление возможности работать только с командой rsync.
Определить используемый ключ можно с помощью опции -i private_key_file:
mydesktop$ ssh -i ~/.ssh/special_ssh_key ssh-server Enter passphrase for key '/home/xahria/.ssh/special_ssh_key':
Следущая опция создаст в Вашем ~/.ssh/config указание на отображение еспользуемого ключа:
mydesktop$ cat ~/.ssh/config Host ssh-server IdentityFile ~/.ssh/special_ssh_key mydesktop$ ssh ssh-server Enter passphrase for key '/home/xahria/.ssh/special_ssh_key':
Обратите внимание, что переменная config всегда равна IdentityFile, независимо от того, используется Pubkey или Identity.
Безопасность кодовой фразы
Ваши приватные ключи могут и должны шифроваться кодовой фразой, так как это оберегает Ваш ключ от компрометации. Даже если Вы установили соответствующие права доступа, но не защитили ключь кодовой фразой, без всяких проблем полюбоваться Вашим ключом сможет пользователь root. Так что не спускайте на тормозах это дело.
authorized_keys2
Старые версии OpenSSH использовали два различных публичных ключа для доступа к серверу — authorized_keys для Identities (SSHv1) и authorized_keys2 для Pubkeys (SSHv2). Позже было решено, что это глупо и теперь используется один файл для ключей всех типов, но при отсутствии подходящего ключа будет проверен и authorized_keys2. Более поздние версии OpenSSH могут вполне прекратить поддерживать authorized_keys2 вовсе.
Чтобы не думать об этом ограничении, создадим жесткую ссылку authorized_keys2 на файл authorized_keys.
ssh-server$ cd .ssh ssh-server$ ls -l -rw------- 1 xahria hatchclan 883 Jan 21 11:52 authorized_keys # make a hard link so they are the same file, just different # file names. ssh-server$ ln authorized_keys authorized_keys2 ssh-server$ ls -l -rw------- 2 xahria hatchclan 883 Jan 21 11:52 authorized_keys -rw------- 2 xahria hatchclan 883 Jan 21 11:52 authorized_keys2
Так мы удовлетворим потребности любой версии OpenSSH.
itman.in