Делюсь опытом в описанных технологиях. Блог в первую очередь выполняет роль памяток для меня самого.

Минимальная настройка SSH в Debian

17 комментариев

Цели

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

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

Установка пакетов

Установить сервер OpenSSH в Debian очень просто:

Установка
apt-get install openssh-server -y

Вместе с самим сервером ставится несколько зависимостей. В моём случае (Debian 7.5) это openssh-client и ncurses-term.

Служба сервера sshd будет автоматически запущена после установки. Обращаться к ней в терминале следует по имени ssh, например (запуск, остановка, перезапуск):

Установка
service ssh start
service ssh stop
service ssh restart

Увеличение длины серверного ключа

По умолчанию длина ключа OpenSSH в Debian 7 - 768 бит, что явно недостаточно. Следует указать значение не ниже 2048 и сгенерировать ключи заново!

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

  1. Переходим в каталог /etc/ssh
  2. Изменяем в sshd_config значение параметра ServerKeyBits с 768 на 2048.
  3. Удаляем старые ключи командой

    rm -rf ssh_host_*
  4. Выполняем перегенерацию ключей сервера (служба будет перезапущена автоматически):

    dpkg-reconfigure openssh-server

Минимальная настройка

Все найстроки сервера OpenSSH хранятся в файле /etc/ssh/sshd_config. Откроем его для редактирования и рассмотрим минимально необходимые опции, которые не рекомендуется трогать либо наоборот настоятельно рекомендуется изменить.

  • Port 22 - лучше всего сразу сменить порт на другой, однако, номер порта желательно выбрать больше 1024, чтобы случайно не создать конфликт с какой-нибудь другой программой, работающей на этом порту.
  • ListenAddress 0.0.0.0 - по умолчанию закомментировано. Можно указать, какой интерфейс должен слушать наш сервер. Если на сервере несколько интерфейсов, один из которых торчин наружу, например, предоставляет доступ к WEB-серверу, а работа с сервером будет производиться только из внутренней сети, я советую указать здесь адрес сервера во внутренней сети, чтобы заблокировать доступ из Интернета.
  • UsePrivilegeSeparation yes - ни в коем случае не отключать разделение привилегий!
  • LoginGraceTime 120 - время в секундах, в течение которого следует авторизоваться на сервере. По истечении указанного интервала сервер автоматически разорвёт соединение.
  • PermitRootLogin yes - настоятельно рекомендую сменить на no! Пользователь root не должен подключаться к серверу! Для выполнения команд, требующих повышения привилегий, следует использовать sudo!
  • PubkeyAuthentication yes - включаем, т.к. дальше будет рассматриваться использование публичных ключей для подключения к серверу.
  • AuthorizedKeysFile %h/.ssh/authorized_keys - следует раскомментировать для доступа с помощью открытых ключей шифрования. По умолчанию эта настройка указывает на то, что открытые ключи каждого пользователя следует искать в его домашнем каталоге, в файле authorized_keys, лежащем в подкаталоге .ssh.

Изменив эти минимальные настройки, перезапустите службу ssh.

Проверка работоспособности

Попробуйте подключиться к своему серверу с него самого:

ssh user@localhost

где user - ваш настоящий логин в системе.

При самом первом подключении ваш SSH-клиент будет спрашивать, следует ли доверять указанному хосту и принять от него ключ шифрования. Отвечаем yes (нужно написать слово полностью). Сервер предложит ввести пароль для авторизации в системе. Вводим его. Если всё правильно, вы окажетесь в консоли, где сможете вводить команды.

Генерация и размещение ключей

Генерация ключей

При шифровании с открытым ключом потребуется создать пару из двух ключей - открытого и закрытого. В *nix-системах стандартным средством для их генерации является программа ssh-keygen. Запуск её с различными параметрами приводит к созданию различных ключей. В нашем случае будет использован минимум настроек.

Выполните указанную ниже команду для создания ключа длиной 2048 бит и с комментарием "New generated key". Права root не требуются. Я советую добавить комментарий для ключа - в этом случае при подключении с его помощью в логах сервера будет отображаться этот комментарий. Можете ввести сюда свои имя и фамилию.

Генерация пользовательских ключей
ssh-keygen -b 2024 -C "New generated key"

Система предложит указать имя для новых файлов. Для примера будем использовать new_key

Затем будет задан вопрос, какая парольная фраза будет использоваться для ключа. Если не заполнять это поле, то ключ не будет защищён паролем. Рекомендую ввести сюда что-нибудь. После первого ввода парольной фразы будет предложено ввести её ещё раз.

После этого в текущем каталоге (если вы ввели имя файла выше) будут созданы два файла - new_key и new_key.pub

Файл new_key - это закрытый ключ. Его нужно сохранить в надёжное место на вашем компьютере и не давать никому. Как правило, его кладут в домашнем каталоге в папку .ssh под именем id_rsa, при этом права на файл должны быть 0600:

Изменение прав доступа к ключу
mv new_key.pub ~/.ssh/id_rsa
chmod 0600 ~/.ssh/id_rsa

Если права будут указаны неправильно, могут возникнуть проблемы. Например, утилита Seahorse из комплекта Gnome при попытке добавить этот ключ в хранилище будет запрашивать пароль, но при нажатии кнопки "Сохранить" выдаст ошибку.

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

Размещение ключей на целевой системе

Если в домашнем каталоге пользователя не существует каталога .ssh, создайте его, а внутри него разместите пустой файл authorized_keys.

Размещение ключей на сервере
cd ~
mkdir .ssh
cd .ssh/
touch authorized_keys

Теперь в этот файл мы добавим наш открытый ключ с помощью стандартной команды >>

cat ~/new_key.pub >> authorized_keys

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

Использование закрытых ключей и Putty

Формат закрытых ключей, используемых программой Putty, несколько отличается от того, который используется в *nix-системах. Тем не менее, в комплекте идёт программа puttygen. Запустите её.

В меню выберите пункт Conversion, а в нём - Import key.

Найдите ваш закрытый ключ и откройте его.

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

Нажмите кнопку Save private key

Дайте подходящее имя закрытому ключу и сохраните его куда-нибудь. Как видите, формат файла изменился - теперь он ppk

Создайте в Putty новое подключение. В настройках найдите пункт Auth. На этой странице в поле Private key file for authentication выберите сохранённый ключ.

Сохраните подключение.

Нажмите Open

Теперь при подключении вам нужно будет вводить не пароль пользователя системы, а пароль от вашего ключа. Удобство заключается в том, что можно создать один публичный ключ и разместить его на десятке серверов. Теперь вместо того, чтобы помнить 10 разных паролей, достаточно помнить всего один и хранить его и секретный ключ в надёжном месте, исключающем доступ посторонних лиц.

Использование ключей для авторизации не отменяет ввода пароля пользователя при вызове команды sudo!

17 комментариев :

  1. Спецаильно чтоли? в статье куча ошибок в коде

    ОтветитьУдалить
    Ответы
    1. Если не затруднит, укажите, где именно. Буду признателен.

      Удалить
    2. Этот комментарий был удален автором.

      Удалить
  2. Были готовы у меня уже ключи, второй день уже бьюсь с этой авторизацией по ключам, ничего не выходит Debian 8.
    Кучу сайтов облазил и действительно нигде подробно не описаны шаги.

    ОтветитьУдалить
    Ответы
    1. Я помогу. Пишите, что именно уже сделано и какие настройки. Код желательно выложить на pastebin.com или подобный ресурс. Данная статья писалась давно, под Debian 7, самое время обновить её под Debian 8. Посмотрим, что можно сделать.

      Удалить
  3. хорошая статья, одна из немногих по которой чайник может разобраться. ошибки есть, но если понимаешь логику, то они видны: mv new_key.pub ~/.ssh/id_rsa. Думаю, что здесь должен быть приватный ключ. Добавил бы описание, как можно перенести ключи с юникс машины на винду. Процедура не сложная, но без gui требует сноровки. Было бы неплохо увидеть как заставить putty читать ключ с etoken. А как уже сказал, хорошая статья. Человек ясно мыслит, поэтому может ясно изложить.

    ОтветитьУдалить
    Ответы
    1. Тут нет ошибки. Речь идёт о линуксовой машине, поэтому публичный и приватный ключи следует сохранить в ~/.ssh/ - там их будет искать Seahorse или Remmina при создании подключения. При этом на машине, к которой будет подключение, нужно сохранить именно публичный ключ. Таким образом получается, что на одной машине в надёжном месте хранятся оба ключа, а на целевой - только один, публичный, и то его содержимое кладётся в файл ~/.ssh/authorized_keys, один ключ на строку.
      Как переносить ключи c Linux на Windows? Самый простой способ - отправить по почте. Дальнейшие шаги я расписал.
      С etoken отдельная проблема. К сожалению, с аппаратно-программными шифровальными устройствами я так и не разобрался, тут помочь не смогу.

      Удалить
    2. Даже по почте слать не надо =) копи-пасте из терминала в винду... потом открываете спащенное путти-геном и сохраняете в формате годном для путти, как указано в статье... успехов!

      Удалить

  4. RSAAuthentication yes? разве не нужно для ключа? и еще вопрос: как в дебиан8 в sshd_config разрешить доступ с подсети, а не с одного адреса? ListenAddress 192.168.0.0/24 не катит

    ОтветитьУдалить
    Ответы
    1. 1. Безусловно, да.
      2. У Вас немного неверное понимание назначения параметра ListenAddress. Там нужно указать либо *, если хотите слушать все интерфейсы, либо конкретный IP-адрес сервера. Допустим, у Вас две сетевых карты: eth0 - 192.168.150.1, eth1 - 10.0.0.1. Вы хотите, чтобы к серверу можно было подключиться только из второй подсети, тогда:
      ListenAddress 10.0.0.1

      Удалить
    2. т.е. если я правильно понял, указывается интерфейс на котором ssh слушает запросы?

      Удалить
  5. айл new_key - это закрытый ключ. Его нужно сохранить в надёжное место на вашем компьютере и не давать никому. Как правило, его кладут в домашнем каталоге в папку .ssh под именем id_rsa, при этом права на файл должны быть 0600:

    в листинге указываете pub не перепутаны ли названия ключей?

    Изменение прав доступа к ключу
    mv new_key.pub ~/.ssh/id_rsa
    chmod 0600 ~/.ssh/id_rsa


    ОтветитьУдалить
  6. айл new_key - это закрытый ключ. Его нужно сохранить в надёжное место на вашем компьютере и не давать никому. Как правило, его кладут в домашнем каталоге в папку .ssh под именем id_rsa, при этом права на файл должны быть 0600:

    в листинге указываете pub не перепутаны ли названия ключей?

    Изменение прав доступа к ключу
    mv new_key.pub ~/.ssh/id_rsa
    chmod 0600 ~/.ssh/id_rsa


    ОтветитьУдалить
  7. ошибка?
    Изменяем в sshd_config значение параметра ServerKeyBits с 768 на 2048.
    ssh-keygen -b 2024 -C "New generated key"

    ОтветитьУдалить
  8. Да хватит уже путать автора))) Учитесь как надо объяснять))

    Автору:

    Дружище, в статье указано, что перемещаем приватный ключ
    mv new_key.pub ~/.ssh/id_rsa

    Но в этой команде идет перемещение публичного ключа. Нужно исправить на
    mv new_key ~/.ssh/id_rsa

    Последствия, если не исправить.

    1) Выдаст ошибку вот эта команда, которая идет далее
    cat ~/new_key.pub >> authorized_keys

    Почему? Потому что ошибочной командой автора мы его уже переместили и там его нет!!!

    2) Ввел я эту команду. Когда скачал этот ключ и открыл его в PUTTY Key Generator, то тот не принял пароль. А все потому, что это оказался публичный ключ))

    ОтветитьУдалить
  9. Спасибо за AuthorizedKeysFile %h/.ssh/authorized_keys , давно боролся с данной проблемой

    ОтветитьУдалить