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