Вместо пароля используется другой метод авторизации – с
использованием ключевого файла. Всё как у pgp/gnupg – у пользователя
есть идентифицирующий его ключ, который он хранит как зеницу ока.
Как создать свой ключ.
На своём компьютере (откуда будем делать соединения):
Я создаю dsa-ключ, он будет работать только при использовании
протокола ssh2 – именно его всегда и надо использовать.
Спросит, куда сохранить ключ:
Расположение по умолчанию нас устраивает, <Enter>.
В точности как для gpg ключей, просит ввести ключевую фразу:
Для начала создадим ключ без пароля, нажимаем просто <Enter>
И ещё раз.
Всё, ключи готовы:
id_dsa – приватный, id_dsa.pub – публичный.
Данный процесс использовался для получения ключей, которые удовлетворят и windows и linux машинку.
Для варианта, в котором коннект делаем с виндовой машинки.
Запускаем puttygen.exe. Указываем SSH2 DSA – тип ключа. Жмем
«Генерировать» и возим мышкой по пустой области в окне.
По окончанию генерации, копируем ключик из бокса окошка
и вставляем одной строкой в файлик /.ssh/authorized_keys
на линуксовой машинке.
Сохраняем приватный и публичный ключи. Приватный ключик оставляем
на виндовой машинке. Публичный кидаем на линуксовую.
Хотя беспарольные ключи и имеют свою область применения (например,
использование в скриптах), обычно надо защищать ключ паролем.
Делается это так:
Самый простой способ выложить свой ключ на сервер для дальнейшего
применения – воспользоваться скриптом `ssh-copy-id` из стандартной
поставки OpenSSH. В самом простом случае (если ключ у вас один и загружен с помощию ssh-agent)
командная строка будет выглядеть так:
После чего скрипт спросит у вас пароль к серверу и сам выложит ключ
туда, куда надо. В более сложных случаях придётся либо прочесть `man
ssh-copy-id` или же выложить ключ вручную.
Ключ представляет из себя простую текстовую строку – можно копировать
его через буфер, отправлять по email и пр.
Скопируем его по scp:
Подробнее о scp – далее.
Далее на remotehost:
Добавили публичную часть ключа к списку разрешённых.
Всё, можно проверять (со своей машины):
Теперь никаких паролей спрашивать не должно для всех сервисов на
базе ssh (scp/sftp).
Если всё-таки спрашивает:
1. Проверить в sshd_config параметры:
1. запустить клиента с ключом -v (Verbose mode)
1. запустить на сервере ещё одного демона на другом порту с ключом -d
Это всё отлично, но что делать с приватным ключом?
Если на него не устанавливать ключевую фразу – то злоумышленник может
забрать файлик с приватным ключом и ходить от вашего имени. Если
ключевую фразу установить – то при каждом соединении надо вводить
эту ключевую фразу, опять нехорошо...
Помнить один пароль вместо десятка – конечно, легче.
Чтобы не расшифровывать ключ (вводя пароль) при каждом соединении,
можно использовать программу ssh-agent.
Идея тут такая: в памяти сидит ssh-agent, которому с помощью ssh-add
добавляются ключи и говорится пароль. Дальше авторизацию берёт на
себя ssh-agent – все программы, запущенные из-под него могут
авторизоваться через сокет в /tmp.
Обычно ssh-agent делают login shell (.profile / .xinitrc).
В случае с xdm/kdm/gdm – прописывается в .xsession (в Debian
прописан в стартовых скриптах безо всяких телодвижений)
То есть вместо запуска window``manager (icewm)
запускается “ssh-agent icewm”.
Потом с помощью ssh-add добавляем нужные ключи:
Для «умолчательных» ключей указывать имена необязательно.
Если ssh-add при запуске не имеет терминала для ввода паролей (в
случае, например, запуска из того же .xsession), но установлена
переменная окружения 'DISPLAY', то он попытается воспользоваться
программой ssh-askpass.
Тут я постарался описать удобные возможности ssh, о которых мало кто знает.
SSH можно использовать для копирования файлов и каталогов по сети.
Для рекурсивного копирования каталогов используйте ключ '-r'.
Символические ссылки при копировании разыменовываются.
Если при заходе по ssh использовать опцию -X, то ssh выставит
правильный $DISPLAY и проделает всё, что надо с xhost/xauth.
Все сервера, которым вы доверяете, можно перечислить в /.ssh/config
(на той машине, откуда вы будете заходить):
SSH можно использовать для создания безопасных шифрованных
TCP-туннелей. Для этого предназначены ключи -R и -L:
После уcтановки связи соединение на localhost:1234 будет
перенаправлено на remotehost:5678.
После уcтановки связи соединение на server:1234 будет
перенаправлено на internal:5678.
Кстати, можно указывать эти ключи не только при запуске ssh. Вы можете поднять туннель для уже установленного ssh-соединения, нажав `C` и отдав команду `-R port:host:hostport` с появившейся консоли.
Предположим, вам нужно из внешней сети зайти на сервер терминалов
(ts.acme.localnet) во внутренней сети acme.com. Установить с ним
соединение напрямую не получается – на шлюзе gate.acme.com запрещены
соединения на порт 3389 (порт Windows Terminal Services по умолчанию).
Но если у вас есть возможность зайти по ssh на gate.acme.com (или на
любую другую машину во внутренней сети) – то вы можете воспользоваться
этим, чтобы подключиться-таки к ts.acme.localnet:
Пока это соединение активно, вы это можете подключаться к
localhost:1234 и попадать при этом на ts.acme.localnet:
SSH перенаправляет потоки ввода-вывода. При грамотном использовании это позволяет сэкономить очень много времени!
Несколько примеров с небольшими пояснениями:
*
ls -l выполняется на server, а file.txt создаётся на клиенте.
*
`tar cz` пишет архив в stdout, который по сети в шифрованном виде
передаётся на server и там `tar xz` его разворачивает.
*
`mkisofs` создаёт iso-образ на нашей стороне, образ передаётся
по сети на `remotehost` и там записывается
с помощью `cdrecord`
*
Созданный image.iso – копия диска в /dev/cdrom на машине remotehost
Добавить бы пару абзацев про putty?