Почему мне следует использовать аутентификацию с открытым ключом для SSH?
Я использую SSH-сервер и все еще использую простую аутентификацию по паролю. Всюду, где я читал о безопасности, мне советуют использовать аутентификацию с открытым ключом. Но я не получаю преимуществ. Их использование, на мой взгляд, либо небезопасно, либо очень удобная работа.
Конечно, если кто-то попытается подобрать логин на моем SSH-сервере, открытый ключ будет намного надежнее любого пароля. Но помимо этого, это совершенно небезопасно.
Консультанты в основном утверждают, что вам не нужно запоминать пароль. Насколько это небезопасно? Значит, если кто-то взломает мой компьютер, он получит не только мой компьютер, но и мой сервер? Если я использую 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, который был до смешного небезопасен)
Edit: еще одно преимущество к открытым ключам, а не к паролям - это распространенный сценарий, когда сервер подвергается опасности из-за уязвимости. В этом случае вход в систему с паролем немедленно скомпрометирует пароль. Авторизации с помощью ключа нет! Я бы сказал, что это более распространено, чем взлом исходного рабочего стола администратора.
Если вы используете надежные пароли, это может быть достаточно безопасно. Я обычно ограничиваю количество общедоступных серверов до минимума и разрешаю SSH с определенных IP-адресов, когда это возможно.
Кроме того, вы можете защитить свои ключи парольной фразой (паролем). Таким образом, эту парольную фразу необходимо вводить всякий раз, когда вам нужно войти на свой сервер (ы). Никто не сможет использовать ваш ключ, если не будет предоставлена правильная кодовая фраза.
Есть похожие сообщения:
- Сообщение из serverfault .
- Сообщение из security stackexchange .
- Сообщение от суперпользователя .
Один из способов более безопасной авторизации с открытым ключом - это когда злоумышленнику удается быть посредником (MitM) между вашим клиентским компьютером и сервером, а вы этого не сделаете. обратите внимание на изменение ключа хоста (возможно, из-за того, что у вас не было старого ключа, например, потому что вы впервые используете этот конкретный клиентский компьютер).
(То же самое применимо, когда злоумышленнику удается получить контроль над сервером, и есть и другие серверы, на которых работают те же учетные данные.)
При стандартной аутентификации на основе пароля вы отправляете свой пароль (внутри зашифрованного соединения) в виде простого текста, подлинный сервер обычно хеширует его и сравнивает результат с хешем хранится в его базе паролей. Злоумышленник MitM может вместо этого взять этот пароль, открыть соединение с реальным сервером и войти в систему ... и либо перенаправить вам содержимое (чтобы вы ничего не заметили), либо просто сделать свои собственные злые вещи на вашем сервере .
При аутентификации с открытым ключом клиент в основном подписывает некоторые данные, известные как серверу, так и клиенту, чтобы доказать, что он владеет закрытым ключом, и отправляет подпись на сервер. Эти подписанные данные включают идентификатор сеанса, который зависит от случайных чисел, выбранных как клиентом, так и сервером, и поэтому отличается для каждого сеанса. Если MitM открывает собственное SSH-соединение с реальным сервером, у этого будет другой идентификатор сеанса, и, следовательно, подпись, предоставленная клиентом, там не будет работать.
Конечно, как уже говорили другие ответы, вам необходимо храните свой закрытый ключ в безопасности, например зашифровано парольной фразой или возможно на отдельном устройстве, которое создает подписи только после ввода PIN-кода.
OpenSSH может иметь собственный центр сертификации для управления ключами хоста и клиента SSH и может использовать для них списки отзыва. Это могло бы повысить безопасность, обеспечиваемую аутентификацией на основе ключей.
Вы правы насчет утверждения «вам не нужен пароль». На стороне клиента это действительно небезопасно.
Что делает разрешение только открытых ключей для входа в систему намного более безопасным, так это тот факт, что нет способа получить доступ к вашему серверу методом грубой силы. Все, что может сделать злоумышленник, - это добавить некоторую нагрузку на ваш сервер - вы можете использовать fail2ban , чтобы держать это под контролем.
Для обеспечения безопасности на стороне клиента вы должны защитить закрытый ключ хорошей парольной фразой. Конечно, теперь подключиться к серверу сложнее, чем с паролем. Чтобы преодолеть это, вы можете использовать ssh agent для хранения закрытого ключа в памяти, если вы собираетесь подключаться к серверу несколько раз подряд. Рекомендуется ограничивать время хранения ключа в памяти.
Возможно, мне лучше подойдет двухфакторная аутентификация.
Одна из возможностей для 2FA для SSH (и та, которая требует относительно небольших настроек/сложностей) - это использование открытого ключа и пароля.
Я думаю, что что-то вроде AuthenticationMethods publickey,keyboardd-interactive можно добавить в /etc/ssh/sshd_config, чтобы это заработало.
В общем, проблема в том, что пароли (одни) не являются отличным методом аутентификации, так как они часто имеют сомнительное качество. Очень простой "аргумент" для ключей против паролей заключается в том, что ключ обычно будет как минимум 2048 бит, а часто и больше (для ключей EC это будет эффективной силой, а не реальным размером). Эти биты также генерируются криптологически безопасным (или подходящим) механизмом.
Пароль часто имеет длину менее 2048 бит и часто не является производным от криптографически защищенного источника.
Вы также можете защитить свои ключи паролем, чтобы избежать проблем, связанных с их потерей (хотя кто-то может попробовать применить грубую силу к этому паролю).
Таким образом, в принципе, можно сделать различия между ключами и паролями достаточно прозрачными, и использование ключей дает вам лучший пароль, чем тот, с которым может справиться человек. Это не означает, что они являются панацеей, но в среднем они обеспечивают большую безопасность, чем пароли.