SSH fingerprint check

constantine.malov — Sat, 17 Mar 2012 16:59:25 +0000

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

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

В принципе эта проверка очень даже полезна, так как значительно снижает вероятность атаки “человек посередине”, но внутри собственной сети от нее часто больше бед, чем пользы. Уже несколько раз наталкивался в своей практике, как страдали бекапы через ssh от проверки fingerprint хоста. Как правило, такое происходит при переустановки ОС, смене доменного имени, или IP. Если машин немного – проблем особых нет, сам все вовремя отловишь. Но когда число серверов переваливает за второй десяток, да еще серверами и бекапами занимаются разные люди – быть беде.
Решение есть – не проверять fingerprint. Конечно же оно связано с определенным риском получить MITM, так что нужно сперва взвесить все плюсы и минусы. Реализация же очень простая:

ssh -o StrictHostKeyChecking=no host.ru

Можно еще запретить добавление fingerprint в known_hosts

ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null host.ru

Источник: http://linuxcommando.blogspot.com

Использование аутентификации по публичному ключу в SSH.

constantine.malov — Mon, 21 Sep 2009 12:26:37 +0000

Вы когда-нибудь смотрели логи попыток аутентификации по ssh? Каждый день сотни ботов рыскают по интернету, пытаясь подобрать пароль и от вашего сервера. Вам не страшно? У вас пароль из двенадцати символов в разном регистре из букв, цифр и специальных символов? Думаю нет, и в один прекрасный день может оказаться, что ваш сервер уже не только ваш.
Есть простой способ оставить ботов с носом, достаточно использовать аутентификацию по публичному ключу.

Сперва нужно сгенерировать на клиентском компьютере (на компьютере с которого вы будете заходить по ssh на сервер) пару ключей (приватный и публичный ключи). Ключи должны быть в каталоге .ssh
cd ~/.ssh
$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/admin/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/admin/.ssh/id_rsa.
Your public key has been saved in /home/admin/.ssh/id_rsa.pub.
The key fingerprint is:
45:de:04:26:59:4f:11:a3:43:d3:d6:a4:82:84:dc:1c admin@it-computer01

Лучше поменять права на файл, так чтобы его нельзя было перезаписать:
$ chmod 400 id_rsa
Теперь нужно поместить публичный ключ на сервер, можно это сделать «руками», т. е. скопировать в буфер публичный ключ, зайти на сервер и добавить редактором в ~/.ssh/authorized_keys нужные строчки. А можно воспользоваться утилитой ssh-copy-id:
$ ssh-copy-id -i id_rsa.pub admin@server1.domain.ru
ssh-copy-id не только корректно скопирует ключ, но и проверит права на файл, его владельца, а так же вы копируете именно публичный ключ, а не приватный по ошибке.

При генерации пары ключей ssh-keygen запросит у вас пароль, его можно оставить пустым. Это конечно удобно, заход на сервер будет производиться без каких либо вопросов, но нужно помнить, если ваши ключи будут украдены, ничто не помешает злоумышленнику ими воспользоваться.

mysyslog.ru » ssh

SSH fingerprint check

Использование аутентификации по публичному ключу в SSH.