В прошлый раз мы остановились на проверке
принадлежности ключа конкретному серверу.
Продолжим рассмотрение работы SSH.

Изменение ключей

SSH может тремя разными способами
реагировать на неправильный или измененный
ключ. Параметр, который отвечает за это
называется  StrictHostKeyChecking.

Самый небезопасный способ такой:

StrictHostKeyChecking=no

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

Другой вариант выглядит так:

StrictHostKeyChecking=ask 

Именно так настраивается SSH по умолчанию.
Если у вас нету ключа для сервера, то клиент
покажет fingerprint и попросит подтвердить его
подлинность, это мы уже проходили в первой
части статьи. Если же вы соединяетесь с
сервером и ключи не совпадают, то программа
не даст зайти на удаленный компьютер и
укажет где найти конфликтующую запись в known_hosts:

$ ssh -o stricthostkeychecking=ask ssh-server.example.com
WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
23:00:20:83:de:02:95:f1:e3:34:be:57:3f:cf:2c:e7.
Please contact your system administrator.
Add correct host key in /home/xahria/.ssh/known_hosts to get rid of this message.
Offending key in /home/xahria/.ssh/known_hosts:8
RSA host key for localhost has changed and you have requested strict checking.
Host key verification failed.

Ну и последний вариант этой опции:

StrictHostKeyChecking=yes

Это, понятно, самый защищенный, но в то же
время и не дружественный для владельца
вариант. Если ключа нет, SSH просто запретит
соединение с сервером:

$ ssh -o 'StrictHostKeyChecking=yes' ssh-server.example.com
No RSA host key is known for localhost and you have requested strict checking.
Host key verification failed.

Если ключ етсь, но он не соответствует
полученному, то события будут
разворачиваться по варианту "ask".

Почему меняются ключи?

На то возможно несколько причин. Помимо
хакерской активности возможны и вполне
мирные объяснения:

  • Клиент или сервер изменились и теперь
    они работают по SSHv2, а не по SSHv1
  • Сервер переустановили с прежним именем,
    но ключи потерялись и естественно были
    сгенерированны заново.
  • Машина обрела другое имя или IP адрес.

Виды ключей

SSH включает в себя два протокола - SSHv2 и SSHv1.
Более старый SSHv1 использует алгоритм RSA, в то
время как SSHv2 поддерживает RSA и DSA. Сервер SSH
может использовать любой из типов ключей:
SSHv1 RSA, SSHv2 RSA или SSHv2 DSA. В терминологии OpenSSH
это rsa1, rsa и dsa. SSH Host Keys создаются командой
ssh-keygen. Вероятнее всего, так как у вас на
машине уже есть SSH, клиент или сервер уже
сгенерировали его во время инсталляции.
Конфиг sshd_config из /etc/ssh показывает какие хост
ключи грузятся при запуске:

# Which protocol(s) should we support?
Protocol 2,1

# HostKey for protocol version 1
HostKey /etc/ssh/ssh_host_key

# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key

Ключи можно создать так:

# ssh-keygen -t rsa /etc/ssh/ssh_host_rsa_key
# ssh-keygen -t dsa /etc/ssh/ssh_host_dsa_key
# ssh-keygen -t rsa1 /etc/ssh/ssh_host_key

На самом деле ssh-keygen создает два файла для
каждого ключа. Первый содержит закрытый и
открытый ключи, второй - только открытый. В
данном примере первой командой мы создадим
сразу /etc/ssh/ssh_host_rsa_key и /etc/ssh/ssh_host_rsa_key.pub. Ясно,
что открытый ключ можно выставить на
обозрение публики, а закрытый хранить в
особо надежном месте (кстати говоря, ssh-keygen
сам устанавливает правильные права). Если
открытый ключ потеряется, то его можно
восстановить:

$ ls -1 /etc/ssh/ssh_host_rsa_key*
/etc/ssh/ssh_host_rsa_key
/etc/ssh/ssh_host_rsa_key.pub

$ cat /etc/ssh/ssh_host_rsa_key.pub
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEApCyGZbDdzrRdszzQUZI+siu3
/mUI57nmjzKwHS7M27AoMZNJ6yIDTn5J3/MVCDJAeyB53LvIFFD9Kzp6P9
fhNhPm8+b0joJ5Wrn+YfUnt2moI3lkAzQUZI+siu3/mUI57nmjzKwH

$ ssh-keygen -y -f /etc/ssh/ssh_host_rsa_key
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEApCyGZbDdzrRdszzQUZI+siu3
/mUI57nmjzKwHS7M27AoMZNJ6yIDTn5J3/MVCDJAeyB53LvIFFD9Kzp6P9
fhNhPm8+b0joJ5Wrn+YfUnt2moI3lkAzQUZI+siu3/mUI57nmjzKwH

Типсы

Есть несколько советов, которые могут
облегчить вам жизнь в мире SSH.

  • Создайте глобальный файл known_hosts (/etc/ssh/ssh_known_hosts)
    со всеми ключами с серверов к которым
    коннектятся юзеры с вашей машины. Это
    облегчит управление и модификацию
    ключей. Храните все три типа ключей для
    всех серверов.
  • Учитывайте различные имена для серверов.
  • Вот скрипт, который коннектится к
    серваку и записывает все три ключа.
    Помните, что он их не проверяет, а лишь
    получает что дают:
    #!/bin/sh
    #
    # add-known-hosts
    # Add all possible SSH keys for the specified hosts to the file
    # specified. It's your responsibility to be sure that the keys
    # found are, in fact, valid.
    #
    # Copyright 2003, Brian Hatch
    # Released under the GPL

    KNOWN_HOSTS=./ssh_known_hosts
    SSH_ARGS="-o StrictHostKeyChecking=no -o UserKnownHostsFile=$KNOWN_HOSTS"

    if [ $# -lt 1 ] ; then
    echo "Usage: $0 hostname [hostname ...]" >&2
    exit 1;
    fi

    for host in "$@"
    do
    ssh $host $SSH_ARGS -1 echo ''
    ssh $host $SSH_ARGS -o'HostKeyAlgorithms=ssh-rsa' echo ''
    ssh $host $SSH_ARGS -o'HostKeyAlgorithms=ssh-dss' echo ''
    done

Check Also

Операция BrainfuckPC. Как я построил самый безумный релейный компьютер и не стал на этом останавливаться

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

Оставить мнение