Linux глазами хакера - Михаил Флёнов

□ KerberosTicketCleanup — очищать билет Kerberos из кэша при выходе из системы;

□ Banner — позволяет указать файл, в котором находится текст приветствия, отображаемый пользователями.

5.3.3. Параметры доступа к серверу sshd

Кроме приведенных в листинге 5.1 можно использовать следующие директивы:

□ AllowGroups — позволить вход в систему только пользователям указанных групп (перечисляются через пробел в одной строке);

□ AllowUsers — разрешить вход в систему пользователям, имена которых перечислены через пробел;

□ DenyGroups — запретить вход в систему пользователям указанных через пробел групп;

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

Я рекомендую вам явно прописать группы или имена пользователей, которые могут входить в систему по SSH.

5.3.4. Конфигурирование клиента SSH

Настройки SSH-клиента содержат еще меньше параметров. В файле /etc/ssh/ssh_config находятся глобальные настройки для всех пользователей в системе. Но вы можете для любого из них переопределить произвольный параметр в файле .ssh_config из директории пользователя. В листинге 5.2 приведено содержимое глобального файла настроек без некоторых комментариев.

# Site-wide defaults for various options

# Host *

#  ForwardAgent no

#  ForwardX11 no

#  RhostsAuthentication yes

#  RhostsRSAAuthentication yes

#  RSAAuthentication yes

#  PasswordAuthentication yes

#  FallBackToRsh no

#  UseRsh no

#  BatchMode no

#  CheckHostIP yes

#  StrictHostKeyChecking ask

#  IdentityFile ~/.ssh/identity

#  IdentityFile ~/.ssh/id_rsa

#  IdentityFile ~/.ssh/id_dsa

#  Port 22

#  Protocol 2,1

#  Cipher 3des

#  Ciphers aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc

#  EscapeChar ~

Host *

Protocol 1,2

Некоторые из этих параметров мы уже видели при рассмотрении серверного конфигурационного файла. Здесь также присутствует параметр Protocol, в котором указываются используемые версии SSH. Только в данном случае не стоит запрещать 1 версию. На безопасность клиента это не повлияет. Зато не будет проблем при подключении к серверу, который работает только на такой версии. Я надеюсь, что это будет не ваш сервер ☺.

Перечислю характерные для клиента команды:

□ Host — указывает, к какому серверу будут относиться следующие настройки;

□ CheckHostIP — разрешена проверка IP-адреса с перечисленными в файле know_hosts адресами;

□ Compression — позволяет (yes) или запрещает (no) использование сжатия данных;

□ KerberosAuthentication — позволяет (yes) или запрещает (no) использование аутентификации по протоколу Kerberos;

□ NumberOfPasswordPrompts — задает количество попыток ввода пароля. Если пароль не введен верно, то соединение разрывается;

□ IdentityFile — определяет имя файла, содержащего закрытые ключи пользователя;

□ PasswordAutentication — указывает на использование аутентификации по паролю.

5.3.5. Пример работы клиента SSH

Теперь рассмотрим на примере, как можно подключиться к удаленному серверу. Для этого используется команда:

ssh пользователь@сервер

Например, чтобы подсоединиться к серверу flenovm под именем flenov, нужно выполнить следующую команду:

ssh [email protected]

В ответ на это вы можете увидеть сообщение:

The authenticity of host 'localhost(127.0.0.1)' can't be established

RSA1 key fingerprint is f2:a1:6b:d6:fc:d0:f2:a1:6b:d6:fc:d0.

Are you sure you want to continue connection (yes/no)?

Данным сообщением программа информирует вас, что подлинность хоста не была установлена и отображает снимок RSA-ключа. Для продолжения соединения необходимо набрать на клавиатуре "yes". На экране появится уведомление:

Permanently added 'localhost' (RSA1) to the list of known hosts.

Здесь вам сообщается, что ключ добавлен в список известных хостов. Это значит, что в вашей домашней директории, в папке .ssh/ появился (или обновился) файл known_hosts с ключом удаленной системы.

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

5.3.6. Вход по ключу

Намного удобнее и даже безопаснее способ авторизации по ключу, а вход по паролю может быть даже заблокирован. Обращение к системе по SSH не совсем безопасно. Злоумышленник может подсмотреть пароль, когда вы будете вводить его в другой программе. Тогда зачем шифровать SSH-соединение, если секретное слово может быть выявлено при работе с другими программами?

Для каждого подключения должны быть свои пароли. Но помнить их все очень сложно, поэтому лучше для авторизации использовать ключи, которые итак защищены, дальше некуда. Нужно сделать только небольшие изменения в конфигурации.

Для начала нужно создать новый ключ. Для этого используется программа ssh-keygen. Ей нужно передать два параметра:

□ -t — тип ключа. Здесь можно указывать rsa или dsa для второй версии SSH или rsa1 — для первой. Для примера будем использовать rsa ключ;

□ -f — файл, в котором будет сохранен закрытый ключ. Открытый ключ получит такое же имя, но с расширением pub;

□ -b — длина ключа, которая может быть минимально 512. По умолчанию установлено значение 1024, оставим его, и не будем указывать этот параметр.

Итак, для генерации ключа выполним команду:

ssh-keygen -t rsa -f ~/.ssh/myrsakey

Обратите внимание, что я указал сохранение ключа в директории .ssh — своей домашней директории (об этом свидетельствует знак "~"). Это директория, в которой SSH будет искать все настройки. Если вы еще не подключались к серверу, то этот путь и ключ отсутствуют. Для исправления ситуации нужно перейти в свою домашнюю директорию и создать папку .ssh:

cd /home/flenov

mkdir .ssh

Если при генерации ключа не указывать файл для его сохранения, то по умолчанию он будет создан в директории ~/.ssh/ с именем id_rsa для RSA-шифрования. Для DSA-шифрования файл будет располагаться там же, но с именем id_dsa. Я специально задал имя, чтобы показать, как с ним работать.

Если программа запустилась успешно, то на экране вы должны увидеть следующее приглашение:

Generating public/private rsa key pair.

Enter passphrase (empty for no passphrase) :

В данном сообщении говорится, что начат процесс генерации публичного и закрытого RSA-ключей. Вам предлагается ввести пароль или оставить его пустым. Я рекомендую лучше указать достаточно длинный пароль (не менее 10 символов, а лучше фразу). После нажатия клавиши <Enter> вам предложат подтвердить комбинацию, чтобы исключить ошибки при вводе.

Если все прошло успешно, то вы должны увидеть следующее сообщение:

Your identification has been saved in ~/ssn/myrsakey.

Your public key has been saved in ~/ssh/myrsakey.pub.

В первой строке нас проинформировали о том, что закрытый ключ сохранен в файле ~/ssh/myrsakey, а открытый — в ~/ssh/myrsakey.pub.

Получив ключи, вы должны отправить файл ~/ssh/myrsakey.pub на удаленный компьютер, чтобы SSH-сервер мог использовать его для аутентификации. Для передачи можно смело использовать открытые каналы связи, потому что публичный ключ ничего не стоит без фразы, которую вы ввели, и без секретного ключа. Даже если хакер сможет получить файл myrsakey.pub, пользы от этого не будет никакой.

Администратор сервера должен добавить содержимое публичного ключа в файл .ssh/authorized_keys. Для этого можно выполнить на сервере следующую команду:

cat myrsakey.pub .ssh/authorized_keys

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

RSAAuthentication yes

PubkeyAuthentication yes

Для подключения к серверу выполните команду:

ssh -i ~/.ssh/myrsakey

С помощью параметра -i мы указываем файл публичного ключа. Если этого не сделать, то будет использоваться id_rsa — файл по умолчанию, его имя задает директива IdentityFile в конфигурационном файле SSH-клиента.

Теперь сервер будет запрашивать у вас не пароль, а слово, которое вы указали при генерации публичного ключа:

Enter passphrase for key

Если в конфигурационном файле SSH-сервера изменить параметр PasswordAuthentication на no, то пароль проверяться не будет, а связь будет устанавливаться только на основании ключей. Для обеспечения безопасной связи этого достаточно.