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

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

Я знаю, что здесь есть десятки вопросов окак подключиться к 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

решение1

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

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

решение2

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

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

(Что касается «невежественных администраторов, работающих только с Windows»: dce.psu.eduна самом деле эта область, по-видимому, основана на Active Directory и размещена на серверах Windows.)

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

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

    кинитваш логин@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: addent -password -pваш_принципал-k 1 -e aes256-cts-hmac-sha1-96
    Пароль дляваш_принципал: *********
    ktutil: wktkeytab_file
    ктутил:  CtrlD
    

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

    $ kinit -ktkeytab_file ваш_принципал
    

решение3

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

Связанный контент