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

9

Я знаю, что здесь есть десятки вопросов о том, как подключиться к 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
Дэвид З
источник
Есть ли на сервере /etc/krb5.keytab? GSSAPI (Kerberos) может быть простым в настройке на стороне клиента; Я должен был бы попросить имя хоста сервера, хотя. (Также: keyboard-interactiveочень похоже на password, за исключением одного приглашения «Пароль:».)
user1686
@ grawity Нет /etc/krb5.keytab, но это так /etc/krb5/krb5.keytab. У меня нет доступа к содержимому. Имя сервера sftp.pass.psu.edu(я не думаю, что присвоение этого имени вредно), если оно поможет вам объяснить процедуру.
Дэвид З
Ааа, старый пассдиск БП. Такие приятные воспоминания. Я был вполне доволен аутентификацией пароля. Почему вы не спросили сотрудников компьютерных кампусов (был ли CAC, когда я туда приехал) вместо того, чтобы обращаться к сети? Я имею в виду, давай, у них есть зеркало Debian. Они не все невежественные администраторы только для Windows.
Broam
@ Broam Я не могу себе представить, что я буду первым, кто спросит, так что, предположительно, у них есть некоторые причины для того, чтобы держать это таким образом ... Хотя, я полагаю, попытка не помешает.
Дэвид З

Ответы:

3

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

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

johnshen64
источник
Зловеще небезопасно, но есть голос за самый простой и прямой ответ.
Зак Б
хорошая точка зрения. Лучше, чтобы все это было сделано за брандмауэром и в частной сети.
johnshen64
8

Судя по собранной информации, сервер 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-user" или аналогичном пакете, если они еще не включены в систему.)

    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
    Пароль для вашего_принципа : *********
    ktutil: wkt keytab_file 
    ktutil:  CtrlD
    

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

    $ kinit -kt  keytab_file your_principal
    
user1686
источник
Похоже, что это должно быть очень близко к идеалу для меня, но, похоже, это не работает - мне удалось успешно войти в систему с Kerberos (без сообщений об ошибках), но мне все равно предлагается пароль. Сообщения об ошибках ssh -vvсхожи с трассировкой, которую я выложил, за исключением того, что debug1: Unspecified GSS failure. Minor code may provide more information\n Server not found in Kerberos databaseвместо файла с кэшем учетных данных ничего не найдено.
Дэвид З
Ах, похоже, что «невежественные администраторы только для Windows» настроили таблицу ключей host/sftp.pass.psu.edu, но ее настоящее имя должно было быть host/lutz.cac.psu.edu. Вы можете обойти это, добавив " 128.118.2.85 sftp.pass.psu.edu" в ваш / etc / hosts, но это немного уродливо - было бы намного лучше, если бы администраторы исправили сервер ...
user1686
Да, было бы ... Я спрошу их об этом, но сейчас, надеюсь, твое исправление должно решить проблемы. Я попробую завтра.
Дэвид З
@DavidZaslavsky: Может быть полезно упомянуть им, что MIT Krb5 v1.10 поддерживает несколько принципалов хоста (т.е. оба host/lutz.cac.psu.edu и host/sftp.pass.psu.edu) в одной таблице ключей. (Предыдущие версии использовали только первую.)
user1686
Извините, я забыл вернуться и оставить отзыв об этом. После внесения изменений /etc/hostsкак предложено я получаю debug1: Unspecified GSS failure. Minor code may provide more information Generic error (see e-text). Ничто другое в выводе не имеет отношения к ошибке.
Дэвид З
3

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

roguesys
источник
Мастер-соединение будет сброшено, когда я выключу клиента. Так что это не идеальное решение, но это будет небольшое улучшение по сравнению с моей текущей ситуацией.
Дэвид Z
Используйте screenдля защиты оболочек от прерывания при разрыве соединения или зависании.
LawrenceC