Вопрос или проблема
Если я использую аутентификацию с помощью закрытого ключа, например, с Ubuntu 11.04, как я могу настроить SSH-клиент на использование только парольной аутентификации для сервера? (необходимо только для тестирования паролей на сервере, куда я обычно захожу с ключом)
Я нашел способ:
mv ~/.ssh/id_rsa ~/.ssh/id_rsa.backupmv ~/.ssh/id_rsa.pub ~/.ssh/id_rsa.pub.backup
и теперь меня запрашивают пароль, но существуют ли какие-либо официальные способы?
Отключите PubkeyAuthentication и также установите PreferredAuthentications в password, чтобы альтернативные методы, такие как gssapi-with-mic, не использовались:
ssh -o PubkeyAuthentication=no -o PreferredAuthentications=password example.com
Вам нужно убедиться, что клиент не настроен на запрет парольной аутентификации.
Я обнаружил сокращенный способ для этой цели:
ssh user:@example.com
Обратите внимание на двоеточие (:) и пустой пароль после него.
Помимо метода, предложенного scoopr, вы можете установить опции для каждого хоста в файле конфигурации вашего SSH-клиента.
В вашем каталоге .ssh создайте файл под названием config (если он еще не существует) и установите для него права доступа 600, после чего вы можете создавать секции, которые начинаются с
host <some hostname or pattern>
и затем задавать опции для каждого хоста, например,
host bob.specific.foouser fredhost *.home.exampleuser billyport 9191
так что вы могли бы иметь
host server.to.testPubkeyAuthentication no
в этом файле, и затем просто
ssh server.to.test
и опция будет использована.
Недавно мне нужно было сделать это, но ни один из вышеперечисленных вариантов не сработал, ssh -v показал, что параметры командной строки, переданные через -o переключатель, были переопределены значениями, указанными в моем файле ~/.ssh/config.
То, что сработало, это:
ssh -F /dev/null <username>@<host>
Из страницы man ssh:
-F configfile Specifies an alternative per-user configuration file. If a configuration file is given on the command line, the system-wide configuration file (/etc/ssh/ssh_config) will be ignored. The default for the per-user configuration file is ~/.ssh/config.
Благодарности автору этого ответа: How can I make ssh ignore .ssh/config?
Я пробовал несколько этих ответов, но ssh -v постоянно показывал, что мои публичные ключи извлекаются из моего домашнего каталога. Однако, указав фиктивный файл идентификации, это сработало для меня:
ssh -i /dev/null host
Мне нужно сделать это навсегда (чтобы обойти неисправный SSH-сервер в APC rack-mounted PDU — держитесь подальше от этих вещей, если вы заботитесь о безопасности), поэтому я в итоге добавил опцию в свой файл конфигурации:
Host apc1 apc2KexAlgorithms +diffie-hellman-group1-sha1IdentityFile /dev/null
Это упомянуто в комментарии выше, но я думаю, что это заслуживает быть отдельным ответом.
Для людей, получающих ошибку Permission denied (publickey), несмотря на другие решения здесь, проблема, вероятно, в том, что сервер настроен не принимать пароли. Чтобы изменить это, вам нужно попасть на сервер (многие сервисы позволяют доступ по паролю через виртуальную консоль на их консоли управления) и:
- nano /etc/ssh/sshd_config
- Найдите PasswordAuthentication no и измените его на yes, и разкомментируйте его.
- Запустите sudo service sshd restart (или sudo systemctl restart sshd, если используете systemd сервисы)
- Теперь попробуйте войти, с удаленного сервера, используя один из методов выше, таких как ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no example.com
Ответы @scoopr и @Halil Özgür не сработали для меня.
Это сработало для меня:
ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no [email protected]
Источник: http://linuxcommando.blogspot.com/2008/10/how-to-disable-ssh-host-key-checking.html
Я могу быть единственным в мире с этой проблемой, но у меня работал ssh из другой операционной системы (choco ssh в Windows в оболочке cygwin), увиденный через which ssh
Так что решение было
/usr/bin/ssh [email protected]
Обратите внимание на полный путь. Я сделал это после того, как я запустил cyg-get openssh
Хотя это поздний ответ, но мне пришлось установить опцию ControlPath в none, потому что у меня уже было установлено соединение с помощью SSH connection sharing. Поэтому аутентификация пропускалась, вместо того чтобы запрашивать пароль. Если у вас такая же проблема, попробуйте следующую команду.
ssh -o ControlPath=none -o PreferredAuthentications=password example.org
А также убедитесь, что в .ssh/config нет BatchMode=yes.
В противном случае у вас не будет шанса получить интерактивный запрос пароля.
Я пробовал почти все предложенное, в том числе установку
PasswordAuthentication yes в /etc/ssh/sshd_config на хосте и множество различных аргументов к ssh на клиенте, но все равно получал Permission denied (pubkey).
Затем я заметил в /etc/ssh/sshd_config на хосте строку:
Include /etc/ssh/sshd_config.d/*.conf
и заинтересовался, какая конфигурация может быть загружена, которая, по всей видимости, переопределяла PasswordAuthentication yes. Я закомментировал это (и перезапустил sshd) — и теперь я могу зайти, просто введя ssh user@host!
Как клиент, так и сервер представляют собой “капли” (сервера) DigitalOcean Ubuntu, один из которых испорчен из-за прерванного do-release-upgrade, и я просто пытаюсь перенести данные с старого (клиента) на новый (хост). Поскольку я имею доступ только к консоли восстановления на старом сервере через веб, с которой я не могу скопировать любой текст (например, открытый ключ), и если я пытаюсь вставить открытый ключ в authorized_keys через веб, вставка искажается — и я действительно хочу избежать ручного ввода открытого ключа! — я пытался подключиться к новому серверу, используя пароль вместо открытого ключа, поэтому нашел этот вопрос. Надеюсь, теперь я смогу начать переносить некоторые данные с помощью scp или rsync. Но я вынужден был закомментировать этот Include, чтобы это сделать, что может быть не безопасным или желательным в долговременной перспективе — я сделал это только для того, чтобы перенести свои данные. Так что будьте осторожны! Но это может помочь, если вы в похожей ситуации.
Дополнительно к тому, что уже было замечено, еще одна причина для отказа в парольной аутентификации заключается в том, что SSH-вход отключен для пользователя, к которому вы пытаетесь подключиться, или пользователь не существует.
Даже с slogin -o PreferredAuthentications=password -o PubkeyAuthentication=no -o PasswordAuthentication=yes user@hostname
Я получаю ответ
user@hostname: Permission denied (publickey).
если пользователь не существует. Так что slogin все еще пытается использовать аутентификацию по открытому ключу в этом случае, даже если я говорю ему этого не делать. (На сервере и парольная, и аутентификация по открытому ключу разрешены.)
В моем случае, я решил проблему, используя -i для указания закрытого ключа для целевой ВМ. Например:
ssh -i /path/to/private_key <username>@<vm_ip>
Ответ или решение
Чтобы настроить SSH-клиент на использование только аутентификации по паролю вместо аутентификации по ключу, необходимо внести некоторые изменения в конфигурацию как с клиентской, так и с серверной стороны. Это может быть полезно в ситуациях, когда необходимо протестировать доступность или работу паролей на сервере, к которому обычно подключаются с помощью ключей. Рассмотрим этот процесс подробнее, применяя подход TEA (Теория, Пример, Применение).
Теория
SSH (Secure Shell) — это протокол, который обеспечивает безопасный обмен данными между компьютерами в сети. Существует несколько методов аутентификации в SSH, включая аутентификацию по паролю и по ключу. На практике использование ключевой аутентификации более безопасно и обычно предпочтительнее, однако иногда необходимо переключаться на использование паролей.
По умолчанию SSH-клиент может использовать оба метода аутентификации, с предпочтением ключевой, если в конфигурации клиента настроены соответствующие ключи. Основная цель — принудительно отключить использование ключей и использовать исключительно пароли для аутентификации.
Пример
Простейшие способы временно заставить SSH-клиента использовать только пароли могут включать в себя переименование файлов ключей:
mv ~/.ssh/id_rsa ~/.ssh/id_rsa.backupmv ~/.ssh/id_rsa.pub ~/.ssh/id_rsa.pub.backup
Однако этот метод не является ни удобным, ни рекомендованным, так как подразумевает ручные изменения в файлах ключей. Вместо этого существуют более целенаправленные способы настройки клиента:
1. Использование SSH-параметров:
Вы можете настроить SSH-сессию так, чтобы она игнорировала ключевую аутентификацию и использовала только пароли:
ssh -o PubkeyAuthentication=no -o PreferredAuthentications=password example.com
2. Конфигурационный файл SSH:
Создайте или отредактируйте файл конфигурации пользователя ~/.ssh/config. В нем можно задать настройки для конкретного хоста:
Host server.to.test PubkeyAuthentication no
Эти изменения гарантируют, что при подключении к указанному серверу будет использована только аутентификация по паролю.
3. Игнорирование пользовательского конфигурационного файла:
Если хотите, чтобы настройки из пользовательского ~/.ssh/config не влияли на текущую сессию, используйте:
ssh -F /dev/null <username>@<host>
Применение
Когда данные изменения сделаны, клиент будет использовать только аутентификацию по паролю для подключения, что позволит тестировать пароли на сервере без необходимости физически изменять или удалять ключи.
Кроме того, иногда проблема может быть связана с серверной конфигурацией, где аутентификация по паролю может быть отключена. В этом случае потребуется доступ к серверу, чтобы изменить настройки:
- Откройте конфигурационный файл сервера /etc/ssh/sshd_config.
- Найдите строку PasswordAuthentication no и измените её на yes, сняв возможный комментарий (#).
- Перезапустите службу SSH с помощью команды:
sudo systemctl restart sshd
Итак, настройка SSH-клиента на использование только паролей может потребовать изменения конфигураций как на стороне клиента, так и на стороне сервера. Эти действия дадут вам возможность более гибко управлять методами аутентификации и обеспечат контроль над безопасностью соединения в зависимости от ваших нужд.
Этот подход особенно полезен в корпоративной среде и для системных администраторов, которые занимаются настройкой серверов и хотят убедиться в правильности настройки всех возможных доступа к своей архитектуре.