Почему я должен использовать аутентификацию с открытым ключом для SSH?

Я использую SSH-сервер и все еще использую простую аутентификацию по паролю. Везде, где я читаю о безопасности, мне рекомендуется использовать Аутентификацию с открытым ключом. Но я не получаю преимущества. Использовать их, на мой взгляд, небезопасно или очень удобно.

Конечно, если кто-то попытается взломать логин на моем SSH-сервере, Public-Key будет намного сильнее любого пароля. Но кроме этого, это совершенно небезопасно.

Консультанты в основном утверждают, что вам не нужно запоминать пароль. Насколько это небезопасно? Так что, если кто-то взломает мой компьютер, он получит не только мой компьютер, но и мой сервер? Если я использую SSH от разных клиентов, я должен хранить открытые ключи по одному для каждого из них, что увеличивает вероятность того, что они попадут в ложные руки. Я мог бы сохранить их на USB-флешке, которую я ношу с собой, но это может быть потеряно, и искатель имеет доступ к моему серверу.

Возможно, мне лучше работать с двухфакторной аутентификацией.

Есть ли какой-то аргумент, который я пропускаю? Каков лучший способ для меня?

если кто-то взломает мой компьютер, он получит не только мой компьютер, но и мой сервер?

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

Но есть 3 преимущества для ключей:

1) Кэшируемая аутентификация. Введите ваш пароль один раз, выполните несколько команд SSH. Это очень полезно, если вы используете что-то, что использует ssh в качестве транспорта, например scp, rsync или git.

2) Масштабируемая аутентификация. Введите ваш пароль один раз, войдите в несколько машин . Чем больше у вас машин, тем полезнее это. Если у вас есть 100 машин, что вы делаете? Вы не можете использовать один и тот же пароль (если это не ферма клонов), и вы не можете вспомнить столько же. Таким образом, вам придется использовать менеджер паролей, и вы вернетесь к единой точке компромисса. По сути, ключевой парольной фразой является ваш менеджер паролей.

2b) Он масштабируется другим способом, если у вас есть несколько администраторов, использующих одни и те же системы, потому что вы можете отозвать ключи у пользователя A, не сообщая B, C, D, E, F ..., что пароль изменился.

(Это также может быть сделано с отдельными учетными записями и sudo, но тогда вам нужно как-то подготовить эти учетные записи)

3) Автоматизация и частичное делегирование. Вы можете настроить SSH для запуска определенной команды при подключении ключа . Это позволяет автоматизированному процессу в системе A что-то делать в системе B без полного доверия без пароля между ними.

(Это замена для rlogin / rsh, который был крайне небезопасен)

Изменить: еще одним преимуществом открытых ключей, а не паролей, является распространенный сценарий, когда сервер подвергается риску из-за уязвимости. В этом случае вход в систему с паролем немедленно компрометирует пароль. Войти с помощью ключа не! Я бы сказал, что это чаще, чем исходный рабочий стол администратора подвергается риску.

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

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

Есть похожие посты:

1. Сообщение от serverfault .
2. Почта из стека обмена безопасности .
3. Пост от суперпользователя .

Один из способов, с помощью которого авторизация с открытым ключом является более безопасной, - это когда злоумышленнику удается установить промежуточный уровень (MitM) между вашим клиентским компьютером и сервером, и вы не замечаете изменение ключа хоста (возможно, потому что вы не сделали этого). старый ключ, например, потому что это первый раз, когда используется этот конкретный клиентский компьютер).

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

При стандартной аутентификации на основе пароля вы отправляете свой пароль (внутри зашифрованного соединения) в виде обычного текста, подлинный сервер обычно хэширует его и сравнивает результат с хешем, хранящимся в его базе паролей. Злоумышленник MitM может вместо этого взять этот пароль, открыть соединение с реальным сервером и войти туда ... и либо переслать вам содержимое (чтобы вы ничего не заметили), либо просто делать свои злые вещи на вашем сервере ,

При аутентификации с открытым ключом клиент в основном подписывает некоторые данные, известные как серверу, так и клиенту, чтобы доказать, что он владеет закрытым ключом, и отправляет подпись на сервер. Эти подписанные данные включают в себя идентификатор сеанса, который зависит от случайных чисел, выбранных как клиентом, так и сервером, и, таким образом, отличается для каждого сеанса. Если MitM открывает свое собственное SSH-соединение с реальным сервером, у него будет другой ID сеанса, и, таким образом, подпись, предоставленная клиентом, там не будет работать.

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

OpenSSH может иметь свой собственный CA для управления ключами хоста и клиента SSH и использовать списки отзыва на них. Это может повысить безопасность, обеспечиваемую аутентификацией на основе ключей.

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

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

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

Возможно, мне лучше работать с двухфакторной аутентификацией.

Одна возможность для 2FA для SSH (и та, которая требует относительно небольшой настройки / сложности) - это использование открытого ключа и пароля.

Я верю, что что-то в этом роде AuthenticationMethods publickey,keyboard-interactiveможет быть добавлено к /etc/ssh/sshd_configэтой работе.

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

Пароль часто составляет менее 2048 бит и часто не получен из криптографически безопасного источника.

Вы также можете защитить свои ключи паролем, чтобы избежать проблем, связанных с их потерей (хотя кто-то может попытаться взломать этот пароль).

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