Як встановити 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

У цьому випадку написання (або кращого запису) сценарію очікування буде одним із ваших варіантів.

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

З інформації, зібраної на даний момент, сервер sftp.pass.psu.eduпідтримує автентифікацію Kerberos 5 (GSSAPI) і знаходиться у dce.psu.eduцарині.

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

^{(Щодо "безглуздих адміністраторів лише для Windows": ця dce.psu.eduобласть фактично базується на Active Directory і розміщена на серверах Windows.)}

Спробуйте виконати наступні дії:

1. Увійти в Керберос. (Інструменти 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нього можна зробити "клавішу" для використання замість пароля.

   $ 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
   

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