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

Question

Я знаю, что здесь есть десятки вопросов о том, как подключиться к SSH-серверу без ввода пароля каждый раз, и ответом всегда будет «использовать открытый ключ». Ну, я нахожусь в редком случае, когда это действительно не вариант. По какой-то необъяснимой причине демон OpenSSH на сервере, к которому я пытаюсь подключиться, настроен с

RSAAuthentication no
PubkeyAuthentication no

в /etc/ssh/sshd_config . У меня нет административного доступа на сервере, поэтому я не могу изменить эти или другие параметры конфигурации сервера. (Я, конечно, имею полный контроль над конфигурацией клиента: OpenSSH 5.8 в Linux.)

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

Другими способами аутентификации, которые может принять сервер, являются, очевидно, GSS API (о котором я ничего не знаю), интерактивная клавиатура (о которой я тоже ничего не знаю) и пароль. Вот некоторые соответствующие параметры конфигурации:

#ChallengeResponseAuthentication yes

#KerberosAuthentication no

GSSAPIAuthentication yes
GSSAPICleanupCredentials yes

#UsePAM no

и вот трассировка отладки (-vv):

debug1: Authentications that can continue: gssapi-with-mic,password,keyboard-interactive
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure.  Minor code may provide more information
Credentials cache file '/tmp/krb5cc_1000' not found
debug1: Unspecified GSS failure.  Minor code may provide more information
Credentials cache file '/tmp/krb5cc_1000' not found
debug1: Unspecified GSS failure.  Minor code may provide more information

debug1: Unspecified GSS failure.  Minor code may provide more information

debug2: we did not send a packet, disable method
debug1: Next authentication method: keyboard-interactive
debug2: userauth_kbdint
debug2: we sent a keyboard-interactive packet, wait for reply
debug1: Authentications that can continue: gssapi-with-mic,password,keyboard-interactive
debug2: we did not send a packet, disable method
debug1: Next authentication method: password

Answer 1

Судя по собранной информации, сервер sftp.pass.psu.edu поддерживает аутентификацию Kerberos 5 (GSSAPI) и находится в области dce.psu.edu .

Kerberos очень распространен в сетях со многими серверами и рабочими станциями; во многих крупных учебных заведениях он есть. Одним из преимуществ, по сравнению с аутентификацией с открытым ключом, является то, что один kinit автоматически предоставляет учетные данные всем машинам в области Kerberos без необходимости копировать открытые ключи на каждую. Другой - поддержка протокола - одни и те же учетные данные Kerberos могут использоваться с более чем 30 протоколами (почта, файловые системы, базы данных ...), а не только с SSH.

^{(Что касается «невежественных администраторов только для Windows»: сфера dce.psu.edu фактически основана на Active Directory и размещена на серверах Windows.)}

Попробуйте выполнить следующие действия:

1. Войдите в Kerberos. (В kinit и klist инструменты могут быть в «krb5-пользователь» или аналогичного пакета, если уже не входит в систему.)

   kinit your_username @ dce.psu.edu
   

   Если ошибки не отображаются, вход был успешным. klist должен показывать элемент " krbtgt/dce.psu.edu@... ".

2. Теперь подключитесь к серверу SSH с опциями -vv ; если аутентификация прошла успешно, хорошо.

   Если это не так, возможно, вам придется отредактировать файл /etc/krb5.conf . В разделе [domain_realm] добавьте следующее:

   [domain_realm]
       .psu.edu = dce.psu.edu
   

3. При стандартных настройках Krb5 билет, полученный в # 1, должен быть действителен в течение 10 часов и продлеваться до недели. Однако у меня нет возможности проверить настройки.

   Если вы хотите сохранить пароль в файле, простой kinit your_principal < password.txt должен работать, хотя он не является полностью надежным.

   С помощью ktutil можно создать "keytab" для использования вместо пароля.

   $ ktutil ktutil: addent -password -p your_principal -k 1 -e aes256-cts-hmac-sha1-96 Пароль для your_principal: ********* ktutil: wkt keytab_file ktutil: Ctrl D
   

   и войдите, используя:

   $ kinit -kt keytab_file your_principal
   

Answer 2

В этом случае написание (или лучшая запись) ожидаемого сценария будет одним из ваших вариантов.

Каждая система индивидуальна, поэтому сценария не будет, но с помощью функции автоматического ожидания очень легко записать сценарий для этой цели.

Answer 3

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