- Ошибка SSH в Linux. Исправление разрешения denied (publickey)
- Ошибка исправления отказа от прав (publicickey)
- Разрешить или запретить доступ SSH определенному пользователю или группе в Linux
- Разрешить SSH Доступ пользователю или группе
- Запретить SSH Доступ пользователю или группе
- SSH Won’t login permission denied (publickey,password)
- Related
- Устранение неполадок SSH: ошибки аутентификации
- Требования
- Основные ошибки
- Отказ в доступе (парольная аутентификация)
- Отказ в доступе (аутентификация на основе SSH-ключей)
- Консоль не поддерживает пароли
- Устранение неполадок
- Проверка доступных методов аутентификации
- Настройка прав доступа и собственности
- Проверка открытого и закрытого ключа
- OpenSSH 7 и устаревшие ключевые алгоритмы
- Заключение
Ошибка SSH в Linux. Исправление разрешения denied (publickey)
Главное меню » Операционная система Linux » Ошибка SSH в Linux. Исправление разрешения denied (publickey)
В этом кратком руководстве вы узнаете, как исправить ошибку ssh. “sign_and_send_pubkey: signing failed: agent refused operation Permission denied (publickey)” в Linux.
Е сли вы пытаетесь подключиться к удаленному серверу через SSH, вы можете столкнуться с ошибкой, отказано в доступе. Эта ошибка может произойти по ряду причин. И исправление этой проблемы зависит от причины ошибки.
В нашем случае у нас были общедоступные и закрытые ключи, хранящиеся на рабочем столе Ubuntu 16.04. После выпуска Ubuntu 18.04 мы решили перейти на эту новую версию. Мы предпочитаем новую установку поверх обновлений дистрибутива.
Итак, мы сделали резервную копию основных папок моего домашнего каталога, включая папку .ssh, на которой были открытые и закрытые ключи на внешнем диске. После установки Ubuntu 18.04 мы восстановили все, включая ключи SSH.
Теперь, когда мы попытались подключиться к удаленному серверу с помощью ssh, то подумали, что это сработает сразу, потому что были такие же публичные и закрытые ключи.
Но это не сработало. SSH выдал эту ошибку:
Если вы находитесь в аналогичной ситуации, когда вы скопировали свои SSH-ключи из другого источника, позвольте показать вам, как исправить эту ошибку SSH.
Ошибка исправления отказа от прав (publicickey)
Поэтому проблема заключается в разрешении файлов. Видите ли, когда мы копировали файлы, USB флешка была в формате файла FAT Microsoft. Этот файл не поддерживает разрешения файлов UNIX/Linux.
И, следовательно, разрешения на скопированные ключи ssh были изменены на 777.
Для SSH права доступа к файлу слишком открыты. Просто не разрешено иметь 777 для открытых или закрытых ключей. И вот почему SSH отказался от подключения.
Закрытый ключ должен иметь права на чтение и запись только для пользователя и другие разрешения для группы и других.
Вы должны изменить разрешение, используя команду CHMOD:
Аналогично, открытый ключ не должен иметь права на запись и выполнение для группы и других.
Теперь, когда вы установили правильные разрешения, вы можете снова подключиться к ssh. Он попросит пароль администратора чтобы разблокировать ключи. Введите пароль администратора.
Это также научило нас одному уроку, копирование и вставка файлов – плохая идея, и правильная резервная копия должна быть сделана иначе, все файлы будут иметь опасные разрешения 777 на них. Мне пришлось рекурсивно менять права доступа к файлу во всем каталоге Home и поверьте мне, это было не очень приятно.
Как мы сказали ранее, для этой ошибки могут быть разные причины. Для проблемы, связанной с разрешением на открытие файла, это исправление должно помочь вам исправить ошибку, Permission denied (publickey) в SSH.
Дайте нам знать в разделе комментариев, исправление работает для вас или нет. Также предложите свое мнение о копировании ключей ssh на другие компьютеры.
Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.
Источник
Разрешить или запретить доступ SSH определенному пользователю или группе в Linux
В этом руководстве мы рассмотрим, как разрешить или запретить доступ SSH к определенному пользователю или группе в Linux
Файл конфигурации OpenSSH по умолчанию имеет две директивы для разрешения и запрета доступа SSH к определенному пользователю (пользователям) или группе.
Во-первых, мы увидим, как разрешить SSH-доступ для определенного пользователя, например sk.
Обратите внимание, что все команды должны выполняться как пользователь root.
Разрешить SSH Доступ пользователю или группе
Перейдите на ваш удаленный сервер и отредактируйте файл sshd_config:
$ sudo vi /etc/ssh/sshd_config
Добавьте или отредактируйте следующую строку:
Замените «sk» на свое имя пользователя.
Вы также можете указать несколько пользователей, как показано ниже.
AllowUsers sk itsecforu
Чтобы разрешить целую группу, скажем, например, root, добавьте / отредактируйте следующую строку:
Те, кто входит в группу, могут передавать ssh на удаленный сервер.
Сохраните и закройте конфигурационный файл SSH.
Перезапустите службу SSH, чтобы изменения вступили в силу.
$ sudo systemctl restart sshd
Теперь пользователям sk, itsecfor или всем пользователям под группой «root» разрешено ssh на ваш удаленный сервер. Другие пользователи (кроме sk, itsecforu и пользователи «root») не могут.
Если вы попытаетесь передать ssh на удаленный сервер с помощью любого из недопустимых пользователей, вы получите следующее сообщение об ошибке:
Теперь давайте рассмотрим, как запретить / отключить доступ ssh определенному пользователю или группе.
Запретить SSH Доступ пользователю или группе
Чтобы отключить или запретить доступ SSH к любому пользователю или группе, вам необходимо добавить / изменить следующие директивы в файле sshd_config вашего удаленного сервера.
Чтобы запретить доступ SSH к определенному пользователю с именем «sk», отредактируйте файл sshd_config:
Добавьте / отредактируйте следующую строку в файле sshd_config.
Аналогично, чтобы запретить доступ SSH нескольким пользователям, укажите имена пользователей как показано ниже.
DenyUsers sk itsecforu
Чтобы запретить доступ SSH ко всей группе, например root, добавьте:
Сохраните и закройте файл конфигурации ssh.
Перезапустите службу ssh, чтобы внести изменения.
$ sudo systemctl restart sshd
если вы пытаетесь использовать ssh для сервера с использованием запрещенных пользователей, например sk:
Появится следующее сообщение:
Что еще более важно, вы также должны отключить вход пользователя root.
Доступ root по ssh считается плохой практикой с точки зрения безопасности.
Чтобы отключить root ssh login, отредактируйте файл sshd_config:
Найдите следующую строку, Раскомментируйте ее и установите значение равным no.
Перезапустите службу SSH. Вы только что отключили вход ssh root.
Источник
SSH Won’t login permission denied (publickey,password)
I’ve tried all the tutorials on DO how to set up SSH but nothing will let me get past the access denied. I set it up originally and wanted to add another user, so I followed a tutorial on that, now I cant login with either…
Is there a way to reset ssh and start over without damaging the server (being online) as there is a website connected that needs not be interrupted.
Thank you any help is appreciated…
Related
Join 1M+ other developers and:
- Get help and share knowledge in Q&A
- Subscribe to topics of interest
- Get courses & tools that help you grow as a developer or small business owner
Join Now
These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.
Ok, so let’s start with not able to login with either user. If you can’t login to SSH, the only other way to login to your Droplet is using console, which you’d access by clicking on the name of the droplet and then clicking on ‘Access’ and then ‘Launch Console’.
To login to console, you’ll need your root user password. If you never received a password and your Droplet is setup with SSH Keys only, there’s very little that can be done at this point, unfortunately, as you can’t use SSH Keys to login to the console.
If you can login to console, you can re-enable PasswordAuthentication by modifying:
and then restarting SSHD:
You could then reset passwords using passwd , such as:
Getting you back in is what’s important right now. We can then work on setting up SSH Keys after though the best way to setup SSH Keys is actually to deploy them when you deploy your Droplet (as this makes it easier). You could then create a new user and we can walk through the setup,
If you can’t login to console, short of submitting a support ticket and seeing if they can help get you back in, you would effectively be locked out and would need to deploy a new Droplet.
When you start tinkering with SSH and a Firewall, you have to be very careful.
Источник
Устранение неполадок SSH: ошибки аутентификации
В первой статье этой серии вы узнали о том, как и в каких ситуациях вы можете попробовать исправить ошибки SSH. Остальные статьи расскажут, как определить и устранить ошибки:
- Проблемы с подключением к серверу: здесь вы узнаете, как исправить ошибки подключения к серверу.
- Ошибки протокола: в этой статье вы узнаете, что делать, если сбрасываются клиентские соединения, клиент жалуется на шифрование или возникают проблемы с неизвестным или измененным удаленным хостом.
- Ошибки оболочки: это руководство поможет исправить ошибки ветвления процессов, валидации оболочки и доступа к домашнему каталогу.
После установления соединения и инициирования протокола система может проверить подключение пользователя к системе. SSH поддерживает множество механизмов аутентификации. В этом руководстве рассмотрены два наиболее распространенных механизма: парольная аутентификация и аутентификация на основе SSH-ключей.
Требования
- Убедитесь, что можете подключиться к виртуальному серверу через консоль.
- Проверьте панель на предмет текущих проблем, влияющих на работу и состояние сервера и гипервизора.
Основные ошибки
Отказ в доступе (парольная аутентификация)
Примечание: Если вы настроили на сервере SSH-ключи и отключили PasswordAuthentication, сервер не поддерживает паролей. Используйте SSH-ключ, чтобы подключиться к серверу.
Клиенты PuTTY и OpenSSH выдают такое сообщение:
root@111.111.111.111’s password:
Permission denied (publickey,password).
PuTTY Error output
root@111.111.111.111’s password:
Access denied
Server sent disconnect message
type 2 (protocol error):
«Too many authentication failures for root»
Это значит, что аутентификация прошла неудачно. Ошибка может быть вызвана рядом проблем. Вот несколько советов по устранению этой ошибки:
- Убедитесь, что вы используете правильное имя пользователя. В CoreOS используйте пользователя core. В FreeBSD используйте аккаунт пользователя freebsd.
- Парольная аутентификация пользователя может быть нарушена. Проверьте, поддерживает ли парольную аутентификацию веб-консоль сервера. Если она не поддерживает пароли, вам придется попытаться сбросить пароль или обратиться за помощью к службе поддержки, чтобы восстановить доступ.
- Убедитесь, что сервер поддерживает парольную аутентификацию.
Отказ в доступе (аутентификация на основе SSH-ключей)
Этот метод использует криптографические ключи для аутентификации пользователя.
Читайте также:
Вы можете получить такую ошибку:
Permission denied (publickey).
PuTTY Error output
Disconnected: No supported authentication methods available (server sent: publickey)
Многие наиболее распространенные проблемы, связанные с аутентификацией на основе ключей, вызваны неправильными правами доступа к файлам или правами собственности. Чтобы устранить проблему, попробуйте сделать следующее:
- Убедитесь, что файл authorized_keys и сам закрытый ключ имеют правильные права доступа и собственности.
- Убедитесь, что сервер поддерживает аутентификацию на основе ключей SSH.
- Убедитесь, что клиент SSH может получить закрытый ключ. Если вы используете PuTTY, убедитесь, что ключи SSH правильно настроены в сессии. Если вы используете OpenSSH, убедитесь, что у закрытого ключа SSH есть соответствующие привилегии.
- Убедитесь, что файл authorized_keys содержит правильный открытый ключ, и что открытый ключ добавлен на сервер.
- Возможно, вы используете закрытый ключ, который больше не поддерживается сервисом OpenSSH. Эта ошибка обычно затрагивает серверы OpenSSH 7+ при использовании закрытого DSA-ключа SSH. Обновите конфигурацию сервера.
Консоль не поддерживает пароли
Если вы не можете восстановить доступ к консоли, это может указывать на проблемы с файловой системой или конфигурацией в подсистеме PAM, которые влияют на механизм аутентификации. Эта ошибка также повлияет на попытки сбросить пароль root и войти в систему через консоль.
В консоли появляется форма аутентификации:
Ubuntu 14.04.4 LTS server tty1
server Login:
Password:
Но после ввода пароля появляется ошибка:
После сброса пароля вы получите:
You are required to change your password immediately (root enforced)
Changing password for root.
(Current) UNIX Password:
Повторно введите текущий пароль. Если соединение закроется, возможно, вы допустили ошибку, повторно вводя пароль. Повторите попытку.
При успешном завершении вам будет предложено дважды ввести новый пароль:
Enter new UNIX password:
Retype new UNIX password:
Однако если после повторного ввода правильного нового пароля сессия перезапустится (т.е. снова вернется форма для входа в систему) или появится сообщение об ошибке, это означает, что проблема в одном из файлов, в котором хранятся данные аутентификации.
В таком случае рекомендуется обратиться за помощью в службу поддержки хостинг-провайдера, подготовить сервер к повторному развёртыванию или исправить ошибки в настройках PAM.
Устранение неполадок
Проверка доступных методов аутентификации
Если вы используете подробный вывод или следите за логами SSH-клиента, убедитесь, что в сообщении, описывающем методы аутентификации, указаны password и/или publickey.
debug1: Authentications that can continue: publickey,password
Если вы не нашли в списке метод аутентификации, который хотите использовать, откройте файл /etc/ssh/sshd_config. В нём часто допускается ошибка: PasswordAuthentication имеет значение yes, а PermitRootLogin – no или without-password для пользователя root.
Исправьте эту ошибку, перезапустите сервис.
Настройка прав доступа и собственности
Сервер и клиент OpenSSH имеют строгие требования к привилегиям и правам собственности на файлы ключей.
Сервер и клиент OpenSSH должны иметь следующие права:
./ssh должен принадлежать текущему аккаунту.
/.ssh/authorized_keys должен принадлежать текущему аккаунту.
Кроме того, клиент должен также иметь такие права:
/ .ssh / config – 600.
Эти изменения можно внести с помощью консоли.
Проверка открытого и закрытого ключа
Если вы забыли, какой закрытый ключ соответствует тому или иному открытому ключу, инструменты OpenSSH и PuTTY помогут вам сгенерировать открытый ключ на основе зарытого ключа. Полученный результат вы можете сравнить с файлом
Чтобы восстановить открытый ключ на основе закрытого ключа в среде OpenSSH, используйте ssh-keygen и укажите путь к закрытому ключу.
/.ssh/id_rsa
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCfBiMwCU1xoVVp0VbSYV3gTDV/jB57IHdILQ8kJ2622//Lmi4gDPlxA6HXVKq8odkGD/5MjqUw85X2rwEbhoBul74+LCToYJvvvBaDPCgg5z1icCKIJ1m/LJBrGNqPKCgqFWu0EH4/EFP2XIQqWqX1BZtJu/2YWrTr+xFOE/umoYmOd+t3dzQqMsv/2Aw+WmA/x/B9h+41WrobDgCExYNLPYcD0PO7fpsa8CcrZCo+TUWCe7MgQQCSM6WD4+PuYFpUWGw3ILTT51bOxoUhAo19U8B2QqxbMwZomzL1vIBhbUlbzyP/xgePTUhEXROTiTFx8W9yetDYLkfrQI8Q05+f
В среде PuTTY команда PuTTYgen.exe загружает интерфейс, в котором можно использовать опцию Load и импортировать закрытый ключ. PuTTY хранит такие файлы в формате .ppk (нужно знать место хранения файла).
Импортировав ключ, вы увидите окно с разделом Public key for pasting into OpenSSH authorized_keys file. В нём и будет искомый открытый ключ. Выделите текст и вставьте его в файл. Он сгенерирует открытый ключ.
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCfBiMwCU1xoVVp0VbSYV3gTDV/jB57IHdILQ8kJ2622//Lmi4gDPlxA6HXVKq8odkGD/5MjqUw85X2rwEbhoBul74+LCToYJvvvBaDPCgg5z1icCKIJ1m/LJBrGNqPKCgqFWu0EH4/EFP2XIQqWqX1BZtJu/2YWrTr+xFOE/umoYmOd+t3dzQqMsv/2Aw+WmA/x/B9h+41WrobDgCExYNLPYcD0PO7fpsa8CcrZCo+TUWCe7MgQQCSM6WD4+PuYFpUWGw3ILTT51bOxoUhAo19U8B2QqxbMwZomzL1vIBhbUlbzyP/xgePTUhEXROTiTFx8W9yetDYLkfrQI8Q05+f imported-openssh-key
Можно проигнорировать комментарий после открытого ключа (imported-openssh-key).
В любом случае этот открытый ключ нужно добавить в файл
OpenSSH 7 и устаревшие ключевые алгоритмы
В системах с OpenSSH 7 (FreeBSD и CoreOS по умолчанию) старые ключи DSA не поддерживаются.
Ключи ssh-dss считаются слабыми, вместо них рекомендуют использовать более надёжные современные алгоритмы.
Следовательно, в данном случае лучшим решением будет создать новые ключи и добавить их на хосты.
Однако в качестве обходного пути вы можете установить в PubkeyAcceptedKeyTypes значение +ssh-dss в файле /etc/ssh/sshd_config.
Заключение
Если у вас не получается самостоятельно настроить аутентификацию SSH, вы можете обратиться за помощью к службе поддержки своего хостинг-провайдера.
Источник