☰

Каковы последствия использования SSH без пароля?

tag-icon • tag-icon ssh password
Каковы последствия использования SSH без пароля?

Если пользователи UNIX подключаются к серверам через SSH, а мы хотим разрешить вход только с использованием открытого ключа, есть ли еще какие-либо пункты, которые необходимо добавить в этот список и на которые следует обратить внимание?

  1. Разрешить pubkey loginв sshd_configфайле на сервере.
  2. Соображения относительно пароля по умолчанию, такие как"!"или"*"

решение1

Было бы неплохо указать, какой SSH-сервер вы запрашиваете и какой (набор) Unix-систем.

!и *не являются паролями, когда вы видите их в /etc/passwdили /etc/shadow(используйте getentдля чтения этих записей).

Это маркеры, которые указывают, есть ли у учетной записи пароль или нет, и заблокирована ли она или нет.

Это важное различие, зависящее от конфигурации и версии PAM и дистрибутива,если вы используете LinuxЕсли он заблокирован, то вероятность того, что вам разрешат войти в систему, ниже, но, с другой стороны, возможно, что он работает «из коробки» на старых системах (по крайней мере, таков мой опыт).

Вы можете использовать (как суперпользователь) passwd -l <name>для блокировки учетной записи ( !) или passwd -d <name>для удаления из нее пароля ( *), а также вы можете объединить оба варианта, что просто гарантирует удаление любого существующего пароля: passwd -dl <name>.

Вы не говорите, но если предположить, что OpenSSH, то соответствующие директивы в /etc/ssh/sshd_config(путь может отличаться) следующие:

HostKey ...

Сервер должен иметь ключ хоста или RSA2 или DSA (а более современные реализации также добавляют две реализации эллиптических кривых). RSA1 давно заброшен всеми распространенными реализациями SSH-серверов.

Затем:

RSAAuthentication yes
PubkeyAuthentication yes
PasswordAuthentication no

Я бы также всегда рекомендовал настроить /etc/sudoersи полностью запретить rootвход через SSH ( PermitRootLogin no). Однако может быть небольшой недостаток этой более безопасной настройки, когда диск заполнен и ваш непривилегированный sudoучастник не может записывать на диск, но rootможет (из-за зарезервированного пространства). Так что YMMV.

Еще два совета

Назначьте группу для ограничения доступа по SSH

Создайте группу ssh-users(или любое другое имя, которое вам нравится) и установите соответствующую директиву в sshd_config. Убедитесь, что он rootявляется или не является членом этой группы в соответствии с политикой, которую вы выбрали на основе информации выше.

AllowGroups ssh-users

Назначьте группу, чтобы ограничить пользователейтолькоSFTP-доступ

Далее sshd_configмы убедимся, что пользователи не смогут выйти /home, а определенные функции будут для них отключены.

Match group sftponly
    ChrootDirectory /home
    X11Forwarding no
    AllowTcpForwarding no
    ForceCommand internal-sftp
    PasswordAuthentication no

Заключение

Так что да, PAM следует добавить в качестве рассмотрения, если вы работаете в Linux.

Также следует ли разрешить переадресацию агента или оставить это на усмотрение пользователей.

И последнее, но не менее важное: разрешить ли им пересылать порты или соединения X11. Особенно порты могут быть нежелательны, так как они позволяют пользователю использовать ваш сервер в качестве прокси.

Директива Matchтакже позволяет ограничивать пользователей в отношении того, откуда они подключаются (это также может делать брандмауэр или оболочки TCP).

Хотите ли вы, чтобы ваши пользователи имели возможность управлять ключами или хотите абстрагировать это и сделать прямой доступ к authorized_keysним недоступным?

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

решение2

Что бы пользователь ни хотел, учитывая любые политики сложности пароля. Если единственный доступ через SSH и PasswordAuthenticationнаходится noвsshd_config, то не имеет значения, какой пароль. Также обратите внимание, что записи вshadowявляются зашифрованными паролями, поэтому значения !и *не являютсяпароли- но строки, которые не являются допустимыми зашифрованными значениями, что делает невозможным вход в систему с использованием пароля.

решение3

Предполагая, что вы используете что-то вроде RHEL/CentOS с OpenSSH, вот что я обычно делаю, когда перехожу на работу без пароля:

  • Настройте sshd_config так, чтобы он принимал только аутентификацию с помощью открытого ключа ( PubkeyAuthentication yes, PasswordAuthentication no, ChallengeResponseAuthentication no, UsePAM no)
  • Установить для всех существующих пользователей недействительный пароль ( chpasswd -e 'pubkey!!' <username>)
  • Удалить срок действия пароля для всех существующих пользователей ( chage -M -1 <username>)
  • При использовании sudo убедитесь, что все пользовательские спецификации помечены как NOPASSWD (например %wheel ALL=(ALL) NOPASSWD: ALL, )
  • Убедитесь, что ваш процесс создания пользователей соответствует этим требованиям (например useradd -p 'pubkey!!' -K MAX_PASS_DAYS=-1 <username>, )

Прежде чем заблокировать доступ по паролю, убедитесь, что вы можете успешно пройти аутентификацию через открытый ключ. Убедитесь, что ваш раздел /home не находится на сетевом монтировании (или где-то еще, что может быть не всегда доступно). Мало что может быть хуже потери доступа к серверу из-за того, что он не может получить доступ к открытому ключу. Если система не имеет headless, убедитесь, что у вас есть способ быстро получить прямой доступ к консоли в случае чрезвычайной ситуации (KVM, виртуальная консоль, аварийная тележка и т. д.).

Учитывая все вышесказанное, я бы рассмотрел возможность установки пароля на учетную запись любого человека с полным доступом к sudo и настройки sudoers на запрос пароля от них. Если все остальное настроено так, как указано выше, они все равно не смогут войти на сервер с этим паролем, но это даст вам немного дополнительной защиты от того, что кто-то сядет в командную строку и будет делать "плохие вещи(tm)".

решение4

Если это машина UNIX (HP UX), а не Linux, то вам нужно будет добавить rcommandв pam.conf под учетной записью sshd.

sshd     account sufficient /usr/lib/security/libpam_ldap.1 rcommand

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

Связанный контент