Я намагаюся підключитися до Linode (працює Ubuntu 12.04 LTS) з моєї локальної машини (також працює Ubuntu 12.04 LTS)

Я створив приватний та відкритий ключ на своїй локальній машині та скопіював свій відкритий ключ у файл дозволеного_кейса мого Linode. Однак кожного разу, коли я намагаюся перенести скриньку на свій Linode, я отримую повідомлення про помилку Permission denied (publickey).

Це не проблема з налаштуванням ssh на моєму Linode, оскільки я можу передати його на моїй машині Windows за допомогою аутентифікації ключів.

У моєму .sshкаталозі на моїй локальній машині Ubuntu я маю свої id_rsaта id_rsa.pubфайли. Чи потрібно мені створити файл авторизованих_кілей на своїй локальній машині?

EDIT: Це те, що я отримую, коли бігаю ssh -vvv -i id_rsa [youruser]@[yourLinode]:

debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey).

PubKeyAuthentication

Налаштуйте свого клієнта

1. Створіть свій ключ
   • ssh-keygen
2. Налаштуйте ssh для використання ключа
   • vim ~/.ssh/config
3. Скопіюйте ключ на свій сервер
   • ssh-copy-id -i /path/to/key.pub SERVERNAME

Ваш конфігураційний файл із кроку 2 повинен мати щось подібне до наступного:

Host SERVERNAME
Hostname ip-or-domain-of-server
User USERNAME
PubKeyAuthentication yes
IdentityFile ./path/to/key

Ви можете додати, IdentitiesOnly yesщоб забезпечити sshвикористання IdentityFileта відсутність інших ключових файлів під час автентифікації, що може спричинити проблеми та не є хорошою практикою.

Вирішення проблем

1. використовувати опцію "-vvv"
2. Переконайтесь, що на сервері є ваш ПУБЛІЧНИЙ ключ (.pub).
3. Переконайтесь, що ваш IdentiyFile вказує на ваш ПРИВАТНИЙ ключ.
4. Переконайтеся, що у вашому .ssh каталозі 700, а у файлах 700 дозволів (rwx ------).
5. tail -f /var/log/auth.log (на сервері) та контролюйте помилки під час спроби входу
6. Якщо у вас багато ключових файлів, спробуйте IdentitiesOnly yesобмежити автентифікацію, щоб використовувати єдиний вказаний ключ.

Іноді проблема виникає через дозволи та право власності. Наприклад, якщо ви хочете увійти як root /root, .sshі він authorized_keysповинен належати до root. Інакше sshd не зможе їх прочитати, а тому не зможе сказати, чи користувач має право входити в систему.

У вашому домашньому каталозі:

chown -R your_user:your_user .ssh

Що стосується прав, то йдіть з 700 за .sshта 600 заauthorized_keys

chmod 700 .ssh
chmod 600 .ssh/authorized_keys

Вам не потрібно authorized_keysдля вашого клієнта.

Ви повинні сказати ssh-клієнту, щоб він фактично використовував створений вами ключ. Існує кілька способів зробити це. Просто для типу тестування ssh -vvv -i .ssh/id_rsa [youruser]@[yourLinode]. Вам потрібно буде вводити свою парольну фразу щоразу, коли ви хочете підключитися до сервера.

Якщо це спрацювало, ви можете додати ключ до ssh-agentз ssh-add .ssh/id_rsa(для цього вам потрібно буде ввести парольну фразу лише один раз, і вона повинна працювати, доки ви не виходите з системи / не перезавантажуєтесь)

Також перевірте значення PasswordAuthenticationв, /etc/ssh/sshd_configі якщо це noзмінити на yes. Не забудьте після цього перезапустити службу ssh.

Проблема у мене полягала в тому, що вона використовувала неправильні клавіші клієнта. Я перейменував id_rsa та id_rsa.pub на щось інше. Ви можете або перейменувати їх назад до стандартних, або коли ви видаєте команду ssh, використовуйте її так

ssh -i ~/.ssh/private_key username@host

Також переконайтесь, що домашній каталог користувача (на сервері) насправді належить користувачеві ssh'ing into (було встановлено root: root у моєму випадку).

Повинно було:

sudo chown username:username /home/username;

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

Зазвичай я зберігаю список авторизованих ключів на всіх своїх серверах ~/.ssh/authorized_keys2. З мого досвіду, sshdбуде шукати ~/.ssh/authorized_keysабо ~/.ssh/authorized_keys2за замовчуванням.

У випадку з моїм веб-сервером у /etc/ssh/sshd_configцього рядка було

AuthorizedKeysFile    %h/.ssh/authorized_keys

замість

AuthorizedKeysFile    %h/.ssh/authorized_keys2

Я застосував останнє, перезапустив свій демон ssh і вирішив проблему входу в систему за допомогою ssh за допомогою мого пабкі.

Інша можлива причина може бути з AllowedUsersконфігурацією в /etc/ssh/sshd_conf. ПРИМІТКА. У списку розміщено простір (не обмежено комами), як я навчився важкому шляху.

AllowUsers user1 user2 user3

Якщо все інше не вдалося, перевірте, чи належить ваш користувач до входу в ssh AllowedGroup. Тобто ваші користувачі є членом групи, показаної у наступному рядку /etc/ssh/sshd_configна сервері:

AllowGroups ssh #Here only users of 'ssh' group can login

У моєму випадку, клієнт - ubuntu 14.04lts, сервер Win 2012 - сервер під керуванням cygwin. Я використовував 'ssh administrator @ xxxx', коли каталог серверів 2012 у cygwin був / home / Administrator. Так що це було чутливим до регістру, коли я спробував "ssh Administrator @ xxxx" (зверніть увагу на велику літеру А у адміністратора), тоді він спрацював нормально.

Повідомлення про помилку на кшталт "користувача не знайдено" привело б мене до рішення набагато швидше, ніж "Дозвіл відмовлено (publickey, інтерактивна клавіатура)".

У мене була така ж проблема, коли копіювався відкритий ключ звичайного користувача (наприклад, johndoe) з системи cPanel Centos на сервер Ubuntu на AWS. Як запропонував gertvdijk вище, я перевірив /var/log/auth.logі досить впевнений, що він сказав Authentication refused: bad ownership or modes for directory /home/johndoe. Виявляється, я помилявся 777'ed /home/johndoeпри спробі встановити /home/johndoe/public_htmlяк кореневий документ за замовчуванням virtualhost для apache2 (це теж не потрібно для цього завдання).

Дивіться також відповіді тут і тут

Сервер повинен мати лише відкритий ключ, .ssh/authorized_keysа клієнт (комп'ютер, на якому ви працюєте) повинен мати приватний ключ (.pem, або якщо ви використовуєте SFTP з Filezilla, .ppk)

Для таких користувачів Putty, як я, які перейшли до цієї теми, ви також можете отримати цю помилку, якщо забули додати користувача користувача @ Ip!

Інші - це дозвіл на ключовий файл chmod до 600)

ssh 1.1.1.1 -i /path/to/.pem file 
Permission denied (publickey).`

ssh user@1.1.1.1 -i /path/to/.pem file 

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

Оригінальний автор розмістив його тут: цифровий-океан-публічний-доступ-ключ-заборонений

sudo nano /etc/ssh/sshd_config

Замініть це

UsePAM yes
IgnoreUserKnownHosts no
PasswordAuthentication no

З цим

UsePAM no
IgnoreUserKnownHosts no
PasswordAuthentication yes

Збережіть файл і перезавантажте ssh

reload ssh

ssh має працювати зараз із запитом пароля

У мене була така ж проблема, як описана в питанні. Вихід від виконання ssh -vvv -i id_rsa [youruser]@[yourLinode]на клієнтській машині був подібний до того, який описаний у питанні. Я перевірив усі дозволи для файлів і каталогів, як було зазначено в інших відповідях, і вони були правильними.

Виявилося, що, копіюючи створений файл id_rsa.pubна серверну машину, як файл ~username/.ssh/authorized_keys, я випадково пропустив слово ssh-rsaз самого початку. Додавання його вирішило проблему.

Працює і на Ubuntu 16.04.

Проблема знаходиться у sshd_configфайлі

Ось рішення ULTIMATE:

Увійдіть як корень до сервера Ubuntu

vi /etc/ssh/sshd_config

Тепер перейдіть до самого низу та змініть значення з "ні" на "так".

Це повинно виглядати так:

Змініть на "ні", щоб вимкнути тунельовані текстові паролі

PasswordAuthentication yes
service sshd reload

набути чинності.

Тепер ви можете просто ввести ключ, використовуючи наступну команду з вашого локального апарату (він же ноутбук тощо)

Тож відкрийте нове вікно терміналу і НЕ увійдіть у сервер, просто поставте цю команду:

ssh-copy-id john @ serverIPAdress

(Замініть Джон на ваше ім'я користувача).

ви повинні йти іти

Деякі люди, які задаються питанням, можливо, налаштували доступ до ssh лише для кореневого облікового запису, потім створили нового користувача і не зрозуміли, що їм потрібно

ssh root@your-ip-address

rsync --archive --chown=[user]:[user] ~/.ssh /home/[user]

logout

Потім спробуйте ще раз. Замініть [користувача] на новий обліковий запис користувача.

Це часто під час налаштування нового сервера на DigitalOcean, коли ви використовували ssh-клавіші під час налаштування.

https://www.digitalocean.com/community/tutorials/initial-server-setup-with-ubuntu-18-04

У моєму випадку проблема була викликана копіюванням .sshкаталогу зі старої машини. Виявляється, мій старший конфігуратор SSH використовував клавіші DSA, які з тих пір застаріли . Перехід на нову пару клавіш, цього разу на основі RSA, вирішив для мене проблему.

Наступний метод може працювати, якщо ви можете отримати доступ до машиниA та machineB незалежно (наприклад, з machineC).

Якщо ssh-copy-id не працює, автентифікацію пароля можна відключити. Далі йде обхід .

Наявність відкритого ключа machineA в авторизованих ключах machineB (тобто ~ / .ssh / санкціонованих_ ключів) дозволить вам сш сш з машиниA. Це стосується і scp.

Після генерації пар ключів використовуючи: ssh-keygen

На машиніA виконайтеcat ~/.ssh/id_rsa.pub

Вибірка зразка:

ssh-rsa AAAAB3NzaSGMFZW7yB anask@mahineA

Скопіюйте роздрукований ключ ( ⌘ Command+ C, або CRTL+ C), а потім додайте його до файлу ~ / .ssh / санкціонованих ключів на machineB .

Наприклад, виконайте такі дії на machineB :

echo 'ssh-rsa AAAAB3NzaSGMFZW7yB anask@mahineA' >> ~/.ssh/authorized_keys