Чтение онлайн

□ 

— поддерживаемые протоколы. Обратите внимание, что первым идет число 2, а затем 1. Это значит, что сервер будет сначала пытаться подключиться по протоколу второй версии, и только потом по первому. Я рекомендую убрать комментарии с этой строки и удалить число 1, чтобы использовалась только последняя версия. Уже давно пора обновить клиентское программное обеспечение и перейти на более безопасные технологии. Зацикливание на старых программах приносит только убытки;

□ 

— определяет адреса для прослушивания подключения. У вашего сервера может быть несколько сетевых карт. По умолчанию идет прослушивание всех интерфейсов. Вы должны указать только те, с которых вы будете подключаться по SSH. Например, очень часто одна сетевая карта смотрит во внутреннюю сеть, а другая — в Интернет. Если вы будете подключаться по SSH-протоколу только из внутренней сети, то следует прослушивать только этот адрес (задается в формате ). Разрешается описывать несколько таких записей, чтобы указать требуемые интерфейсы;

□ 

— указывается путь к файлам, содержащим ключи шифрования. Нужно прописывать только закрытые ключи, которые использует сервер для расшифровки пакетов;

□ 

— в версии 1 во время сессии могут регенерироваться ключи. Это позволяет сделать невозможным раскрытие пакетов за счет смены ключей, которые по умолчанию меняются каждые 3600 секунд. Если установить 0, то регенерации не будет. Так как мы отказались от 1 версии протокола (см. параметр ), то этот атрибут не влияет на работу;

□ 

— длина серверного ключа. По умолчанию установлено 768, минимальное значение — 512;

□ 

— задает тип сообщений, которые будут сохраняться в журнале;

□ 

— уровень событий, которые будут попадать в журнал. Возможные уровни соответствуют системным, которые мы будем рассматривать в разд. 12.5;

□ 

— интервал времени, в течение которого пользователь должен ввести правильный пароль, иначе соединение будет разорвано;

□ 

— определяет, разрешено () или запрещено () входить в систему по SSH-протоколу под пользователем root. Мы уже говорили, что root — это бог в системе, и его возможности нужно использовать аккуратно. Если в систему нельзя входить с такими правами, то и по SSH тем более. Срочно меняйте этот параметр на ;

□ 

— указывает, должен ли sshd проверять состояние файлов и их владельцев, пользовательских файлов и домашней директории до ввода пароля. Желательно установить , потому что многие начинающие пользователи делают свои файлы все доступными для записи;

□ 

— разрешена ли аутентификация по алгоритму RSA. Параметр действует для 1 версии протокола;

□ 

— дозволена ли аутентификация по публичному ключу. Параметр действует для 2-й версии протокола;

□ 

— файл с публичным ключом, который может использоваться для аутентификации;

□ 

— разрешение аутентификации по файлам $HOME/.rhosts и /etc/hosts.equiv. По умолчанию стоит , и без особой надобности менять этот параметр не стоит, потому что это небезопасно;

□ 

— если параметр равен yes, то запрещается читать файлы ~/.rhosts и ~/.shosts. Без необходимости значение лучше не изменять, потому что это может повлиять на безопасность;

□ 

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

□ 

— если этот параметр , то при аутентификации будет требоваться ключ хоста из директории /etc/ssh/ssh_known_hosts. Параметр используется в 1 версии SSH;

□ 

— если параметр равен no, то необходимо доверять компьютерам из списка ~/.ssh/known_hosts при RhostsRSAAuthentication-аутентификации. Не верьте никому, поэтому параметр лучше всего изменить на ;

□ 

— если значение равно , то будет требоваться пароль. При использовании авторизации через ключи параметр можно отключить;

□ 

— по умолчанию установлено , что запрещает использование пустых паролей, и изменять это значение не стоит;

□ 

— использовать проверку подлинности по протоколу Kerberos. В последнее время именно эта аутентификация набирает большую популярность благодаря своей безопасности;

□ 

— если пароль Kerberos не был принят, то включается проверка локального файла паролей из файла /etc/shadow;

□ 

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

□ 

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

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

□ 

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

□ 

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

□ 

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