- How to Resolve SSH Permission Denied (publickey) Error?
- Reason: Incorrect Configuration of the sshd_config File
- Solution 1: Enable the Password Authentication in the sshd_config File
- Solution 2: Install the Openssh Package
- For Ubuntu/Debian/Linux Mint:
- For RHEL/Centos/Fedora:
- Solution 3: Generate and Add an SSH Key to the Server
- Verify SSH Services
- Conclusion
- Проблема с ssh — отказанно в доступе. [РЕШЕНО]
- Вложения
- Карл
- Iskatel_znaniy
- Вложения
- Iskatel_znaniy
- Проблема с ssh — отказанно в доступе. [РЕШЕНО]
- Вложения
- oko
- Iskatel_znaniy
- Iskatel_znaniy
- Iskatel_znaniy
- Vosiley
- Iskatel_znaniy
- Iskatel_znaniy
How to Resolve SSH Permission Denied (publickey) Error?
Secure Shell (SSH) keys are a combination of public-private key-value pairs for making a secure connection between remote devices. The public key has significant importance in automating the authentication process. While dealing with the SSH keys, an error “ssh permission denied (publickey)” occurs in the terminal.
This article will explain multiple solutions to resolve the error mentioned above. The supported content of this article is given below:
- Reason: Incorrect Configuration of the sshd_config File
- Solution 1: Enable the Password Authentication in the sshd_config File
- Solution 2: Install the Openssh Package
- Solution 3: Generate and Add SSH Key to the Server
Let’s start with the first reason for this error.
Reason: Incorrect Configuration of the sshd_config File
One of the common reasons causing errors is the sshd_config file is not properly configured. Therefore, the system does not locate the required public keys:
Solution 1: Enable the Password Authentication in the sshd_config File
To encounter the above error, disable the password authentication services. To do so, access the “sshd_config” file and perform some modifications. By default, the value of “PasswordAuthentication” is “no”. Change the value from “no” to “yes” and save the file by disabling the public authentication:
$ sudo nano /etc/ssh/sshd_config
After closing the file, restart the “sshd” services to apply changes:
$ sudo systemctl restart sshd
Solution 2: Install the Openssh Package
Another solution that can resolve the error is possible by installing the “openssh-server” package. To install the required package, execute the below script:
For Ubuntu/Debian/Linux Mint:
$ sudo apt install openssh-server
For RHEL/Centos/Fedora:
$ yum -y install openssh-server
The output shows that the “openssh-server” package is installed in the system.
Solution 3: Generate and Add an SSH Key to the Server
Another solution to resolve the ssh permission denied error, generate the new ssh keys and add them to the server. To generate the public-private key pair, follow the below script:
The output shows that the public-private key has been successfully generated.
To add the generated key to the server, specify the username with the host. In this case, the “itslinuxfoss” represents the username, and “ubuntu” refers to the hostname:
The output shows that the ssh key has been added successfully to the server.
Verify SSH Services
To verify the ssh services, write the current username with the host that will display the detail of the last login with the IP address:
The output shows that ssh services are running perfectly.
These are all the reasons and solutions to fix the permission denied (publickey) error.
Conclusion
The error “ssh permission denied (publickey)” occurs due to the incorrect configuration of the sshd_config file. It can be solved by disabling the password authentication in the sshd_config file, reinstalling the Openssh package, and adding the SSH Key to the Server. This article has provided all possible methods to encounter the above error.
Проблема с ssh — отказанно в доступе. [РЕШЕНО]
в астре первый пользователь, создаваемый при установке, при подаче им sudo не требует пароля !
а твой user_2 может даже и вообще не в группе sudo
в первой команде порт неправильно указал, надо ssh -p 22 -X .
Вложения
Карл
New member
Iskatel_znaniy
New member
Так и не смог сделать запуск удаленных графических приложений через ssh от рута но нашел обходной путь. Нужно запустить удаленно утилиту «Запуск приложений» командой ssh -XC username@192.168.1.11 -p 22 «fly-run» и через нее от имени удаленного пользователя через su запустить нужное приложение с правами root. Правда немного странно: Политику безопасности от рута запускать и изменять удаленно получается а файловый менеджер из под рута как то не выходит. нельзя даже создать удаленно файл в графике и удалить его но когда его создавать на другой машине он здесь сразу бывает в графике виден. Запустил еще некоторые приложение от рута — получается. То есть в утилите «Запуск приложений» при указании нужного приложения и вводе имени пользователя и пароля, если нажать «выполнить» то он требует ввода пароля удаленного пользователя и из под него запускает. Похоже проблема видимо в файловом менеджере. Это конечно на страшно так как все это можно делать удаленно и через терминал но все таки странно.
Вложения
Iskatel_znaniy
New member
При попытке скопировать на удаленный сервер музыкальный файл командой put имя_файла пишет что Couldn’t open local file
что значит «Не удалось открыть локальный файл». В то время как какой нибудь txt файл созданный мной копируется. Видимо более сложные файлы таким образом скопировать невозможно.
Проблема с ssh — отказанно в доступе. [РЕШЕНО]
Есть два созданных новых пользователя. Один на сервере а другой на клиенте. Доступ по паролю получается но когда набираю команду
ssh-copy-id пользователь@192.168.1.12 -p 22 то требует пароль а после сообщение «отказанно в доступе». (обязательно так же важно разрешить удаленный доступ на обеих машинах.)
Вложения
oko
New member
to Iskatel_znaniy
Выхлоп бы полностью, а то гадаем на кофейной гуще.
Вот тут ребята описывают схожую проблему. Проверить не могу — нет двух связанных сетевых Astra-машин.
Iskatel_znaniy
New member
to Iskatel_znaniy
Выхлоп бы полностью, а то гадаем на кофейной гуще.
Вот тут ребята описывают схожую проблему. Проверить не могу — нет двух связанных сетевых Astra-машин.
Логи что ли какие нибудь нужны? Но вообще у меня получилось когда в первый раз проделал это с клиента который под основным пользователем с тем на сервере который под созданным другим (не основным пользователем). То есть в первый раз у меня получилось. Тогда создал на сервере и на клиете по пользователю и попытался командой ssh-copy-id пользователь@192.168.1.12 -p 22 переслать созданный ключ от созданного на клиенте пользователя к созданному на сервере пользователю но вот выходит сообщение что отказанно в доступе. В то время как по паролю доступ есть без проблем. Сейчас снова проверил и заметил вот что: Вместо authorized keys у меня id_rsa и id_rsa_pub. Как сделать authorized keys? А, нашел ответ! Попробую!
Iskatel_znaniy
New member
Переименовал ключ командой mv ~/.ssh/id_rsa.pub ~/.ssh/authorized_keys . При вводе команды ssh-copy-id пользователь@192.168.1.12 -p 22 пишет что нет такого файла или каталога /home/пользователь/.pub .
Iskatel_znaniy
New member
Сделал вот что: Назначил временно каталогу .ssh на сервере права командой chmod 777 . После этого доступ получается и удалось скопировать ключ. Пишет: Now try logging into the machine, with: «ssh -p ’22’ ‘пользователь@192.168.0.12’ » and chek to make sure that only the key(s) you wanted were added. Но по ключу зайти не могу. Permission denied (publickey) . Естественно я переключаю в файле сервера /etc/ssh/sshd_config пункт PubkeyAuthentication yes и PasswordAuthentication no .
Vosiley
New member
1. Чтобы не использовать ssh-copy-id можно вручную создать файлик .ssh/authorized_keys, либо добавить текст ключа в уже существующий.
2. При подключении по ssh можно попытаться явно указать private_key параметром -i
3. А также, можно посмотреть логи sshd на сервере через Journalctl.
Iskatel_znaniy
New member
1. Чтобы не использовать ssh-copy-id можно вручную создать файлик .ssh/authorized_keys, либо добавить текст ключа в уже существующий.
2. При подключении по ssh можно попытаться явно указать private_key параметром -i
3. А также, можно посмотреть логи sshd на сервере через Journalctl.
В первый раз у меня получилось как раз без ручных действий а начинал я именно с ручных но под ними не получалось.
Iskatel_znaniy
New member
Решил проблему так: Назначил каталогу ./ssh на сервере права доступа 755 командой chmod 755 /home/пользователь/.ssh а файлу authorized_keys права 644 командой chmod 644 /home/пользователь/.ssh/authorized_keys . Эти права я смотрел у того пользователя под которым вход по ключу получался без проблем. Теперь вход получается. При чем хочу подчеркнуть: На многих сайтах советы установить права доступа 700 на каталог /ssh . Я пробовал но не работает. Сработало именно при правах 755 (то есть полный доступ для владельца и чтение для группы и для всех). То есть по ключу можно входить обычному пользователю а не root что на мой взгляд безопаснее — я так понимаю. Но прежде чтобы скопировать ключ на сервер командой ssh-copy-id пользователь@192.168.1.12 -p 22 нужно временно назначить на сервере каталогу ./ssh права доступа 777 чтобы ключ смог скопироваться а уже потом 755 . Эксперимент так же показал что на сервере файлу authorized_keys можно дать права 600 и все будет работать нормально.
Ну еще добавлю как перейти на sftp. Нужно набрать команду sftp -P 22 username@remote_host_or_ip где буква P должна быть в верхнем регистре в отличии от входа на удаленную систему через ssh (ssh user@ip_адрес -p 22) . При чем в первый раз у меня не получилось и получил отказ а во второй раз попал. После входа появляется строка sftp> в которой можно вводить команды как написанно в этой статье. Пишу для начинающих пользователей и тех кому это интересно. Если включен сетевой экран то нужно вначале набрать команду sudo ufw allow 22/tcp а чтобы выключить то есть запретить доступ набрать команду sudo ufw deny 22/tcp Ну я набрал на сервере команду sudo ufw allow from 192.168.1.15 to any port 22 где 192.168.1.15 адрес клиента.