Неможливо зробити автентифікацію відкритого ключа SSH для роботи [закрито]

Мій сервер працює під управлінням CentOS 5.3. Я на Mac під управлінням Leopard. Я не знаю, хто за це відповідальний:

Я можу ввійти на свій сервер чудово за допомогою автентифікації пароля. Я пройшов усі етапи налаштування PKA (як описано на веб-сторінці http://www.centos.org/docs/5/html/Deployment_Guide-en-US/s1-ssh-beyondshell.html ), але коли Я використовую SSH, він відмовляється навіть намагатися перевірити publickey. Використання команди

ssh -vvv user@host

(де -vvv підкручує багатослів’я до максимального рівня) я отримую такий відповідний вихід:

debug2: key: /Users/me/.ssh/id_dsa (0x123456)
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug3: start over, passed a different list publickey,gssapi-with-mic,password
debug3: preferred keyboard-interactive,password
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password

після чого з'являється запит на пароль. Якщо я спробую вирішити проблему

ssh -vvv -o PreferredAuthentications=publickey user@host

я отримав

debug2: key: /Users/me/.ssh/id_dsa (0x123456)
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug3: start over, passed a different list publickey,gssapi-with-mic,password
debug3: preferred publickey
debug3: authmethod_lookup publickey
debug3: No more authentication methods to try.

Отже, незважаючи на те, що сервер каже, що він приймає метод аутентифікації publickey, і мій клієнт SSH наполягає на цьому, я спростую. (Зверніть увагу на очевидну відсутність рядка "Пропозиція відкритого ключа:" вище.) Будь-які пропозиції?

Перевірте, чи є у вашої машини Centos:

RSAAuthentication yes
PubkeyAuthentication yes

в sshd_config

і переконайтеся, що у вас є відповідний дозвіл на каталог ~ / .ssh / в центрі машини.

chmod 700 ~/.ssh/
chmod 600 ~/.ssh/*

повинен зробити трюк.

У мене була подібна проблема - віддалений ПК не міг використовувати автентифікацію відкритих ключів для входу на сервер CentOs 6. Проблема в моєму випадку була пов'язана з SELinux - домашній каталог користувача, який намагався увійти, мав контексти безпеки повідомлень. Я вирішив це за допомогою restoreconінструменту таким чином:

restorecon -Rv /home

1) перевірте / etc / ssh / sshd_config, переконайтеся, що у вас є

Аутентифікація RSA так
PubkeyAuthentication так

2) перевірити захищений журнал із віддаленої машини, перегляньте деталі журналу помилок sshd daemon. наприклад, в моєму Ubuntu

# grep 'sshd' / var / log / secure | grep 'Відхилена автентифікація' | хвіст -5
4 серпня 06:20:22 xxx sshd [16860]: Відхилена автентифікація: неправильне володіння або режими для каталогу / home / xxx
4 серпня 06:20:22 xxx sshd [16860]: Відхилена автентифікація: неправильне володіння або режими для каталогу / home / xxx
4 серпня 06:21:21 xxx sshd [17028]: Відхилена автентифікація: неправильне володіння або режими для каталогу / home / xxx
4 серпня 06:21:21 xxx sshd [17028]: Відхилена автентифікація: неправильне володіння або режими для каталогу / home / xxx
4 серпня 06:27:39 xxx sshd [20362]: Відхилена автентифікація: неправильне володіння або режими для каталогу / home / xxx

Потім перевірте право власності та режими на каталог / home / xxx, можливо, вам потрібно запустити це

chmod 755 / домашня / ххх

Двічі перевірте, чи є ваші дозволи правильними та як файли (зокрема написання) є правильними як для локальних, так і віддалених машин. URL-адреса, на яку ви посилаєтесь, указує їх усі, але варто перевірити, чи є у вас відповідність. Зазвичай дозволи дозволяють створити відповідну помилку.

Ви перевірили, чи встановлено sshd_config у вікні CentOS 5.3, щоб дозволити PubkeyAuthentication або RSAAuthentication?

Перевірте журнали SSH-серверів у системі CentOS - вони можуть надати більше інформації. Я не впевнений, чи CentOS виконує перевірку ключа ssh у чорному списку, що робить Debian, але я бачив відхилення ssh publickey, які відносно безшумні, наскільки йде вихід -vvv, але журнали досить чітко пояснюють, що відбувається

Зрозумів! Виявляється, це було проблемою для клієнта. (Я думаю, що будь-яка проблема на стороні сервера дала б більш корисний вихід налагодження.) З невідомих мені причин, на моєму Mac, файл / etc / ssh_config мав рядок

PubkeyAuthentication = no

Я прокоментував, що один рядок, і зараз все працює добре.

Окрім режимів файлів / каталогів, переконайтесь, що право власності є правильним! Користувач повинен мати власний домашній каталог, .ssh / та файли в ньому.

Мені довелося бігти, chown -R $user:$user /home/$userщоб подолати свої невдачі в ssh.

Також перевірте, чи може він автоматично надати ключ чи ні, використовуйте -i шлях / до / ключ, якщо ні, або просто для тестування

Для мене звучить проблема з конфігурацією. Як Даніель запропонував перевірити дві речі:

1. Ключі SSH в $HOME/.ssh/authorized_keysчитаються; і
2. SSHd налаштовано для входу в відкритий ключ.

Позначте ім’я користувача, з яким ви намагаєтесь увійти. За замовчуванням це ваше ім'я користувача на локальній машині.

Вихід клієнта, як у ssh -v, виявить, що існує проблема на певному кроці протоколу, але коли це пов'язано з чимось на сервері, клієнт не буде повідомлений про причину. Перевірте файли журналу сервера, щоб з’ясувати, що не так. Ймовірно, вам потрібно буде мати rootдля цього дозволи. Наприклад, для sshdналаштованого входу в syslog ви можете знайти повідомлення /var/log/secure. Як ці:

Authentication refused: bad ownership or modes for directory /home/you/.ssh
Authentication refused: bad ownership or modes for file /home/you/.ssh/authorized_keys

Причина в даному випадку був (дурний) по замовчуванням defaultв 0002. Це означає, що пишіть доступ для групи. (Ім'я групи = ім'я користувача, але все ж.) Демон SSH не буде довіряти файлам, які можуть підробляти інші, ніж користувач (ну, і rootзвичайно). Вирішити проблему можна за допомогою chmod.

chmod 700 ~/.ssh # solve the issue
chmod 720 ~/.ssh # reproduce the issue
# or similar for a file

Я щойно потрапив у пастку в тій же проблемі, що отримує доступ до ядра Fedora 16 до центів 5,5

колоди та багатослівні виглядали точно так само

проблема була відкритим ключем, вона отримала кілька помилкових даних, відновлює їх та розміщує їх у sshd_server, ви sshd_client надсилає ключову інформацію, але її не розпізнає сервер (вона відповідає, що відповідає жодному з ключів в авторизованих_кеях)

Ще одне покусане цим. Після тривалого пошуку виявилося, що я явно подав ssh публічний ключ (з опцією -i) замість приватного ключа. До!