Permission denied linux как исправить

Как убрать сообщения Permission denied при использовании find?

Когда использую команду find, то часто получаю сообщения Permission denied (Отказано в доступе) об отсутствии доступа к некоторым директориям и файлам. Особенно это мешает, когда ищу по всему диску:
find / -name myfile

В итоге получаю много лишних сообщений среди которых нужно еще выискивать найденные файлы:
find / -name «apache*»
find: `/etc/ssl/private’: Отказано в доступе
/etc/apparmor.d/abstractions/apache2-common
find: `/etc/polkit-1/localauthority’: Отказано в доступе
find: `/etc/cups/ssl’: Отказано в доступе
find: `/sys/kernel/debug’: Отказано в доступе
find: `/run/udisks2′: Отказано в доступе
…

Данные сообщения появляются, когда алгоритм поиска натыкается на файлы, к которым у пользователя нет доступа.

Есть несколько способов убрать сообщения Permission denied. Наверное, самый простой — это перенаправлять все ошибки в /dev/null. Для этого в конце вашей команды просто дописываем: 2>/dev/null. Например:

find / -name "*.txt" 2>/dev/null

У этого способа есть и недостаток, так как вы не получите на экран сообщения об ошибках. Но для простого поиска данный метод подходит.

Как исправить ошибку SSH Permission Denied Public key в Linux?

SSH – аббревиатура от Secure Shell, является удаленным протоколом, который широко используется для удаленного подключения к серверам, сетевым устройствам и другим удаленным хостам, на которых запущена эта служба. Он использует пару открытый/закрытый ключ для шифрования трафика между пользователем и удаленным узлом.

При создании соединения вы можете столкнуться с ошибкой «ssh permission denied public key». В этом руководстве мы постараемся понять причину этой ошибки и способы ее устранения.

Причина ошибки SSH Permission denied (publickey).

В основном причиной этой ошибки является неправильная конфигурация файла /etc/ssh/sshd_config, который является стандартным файлом конфигурации SSH .

Другой причиной является недостаточное количество прав на файл authorized_keys на удаленной системе. Этот файл содержит открытые ключи клиентских систем, которым разрешено подключаться по SSH к серверу.

Без лишних слов, давайте рассмотрим возможные решения для устранения этой ошибки.

Включить проверку подлинности пароля.

Как уже отмечалось ранее, одной из причин возникновения этой ошибки является неправильная настройка файла /etc/ssh/sshd_config. Одной из неправильных настроек является отключение функции аутентификации по паролю. Это может произойти в том случае, если кто-то использует аутентификацию только на основе ключей SSH , а закрытый ключ по какой-то причине отсутствует.

Для устранения этой ошибки отредактируйте стандартный файл конфигурации SSH .

sudo vim /etc/ssh/sshd_config

Найдите атрибут PasswordAuthentication и установите его в yes , как показано ниже.

Сохраните изменения и выйдите из файла конфигурации. Затем перезапустите службу SSH , чтобы изменения вступили в силу.

sudo systemctl restart sshd

Теперь вы должны иметь возможность беспрепятственно подключаться к удаленному хосту.

Проверьте разрешение SSH Authorized_keys.

Иногда ошибка возникает из-за неправильных разрешений и прав собственности на ./.ssh/authorized_keys файл на удаленной системе.

Этот файл ./.ssh/authorized_keys расположен на удаленном сервере. Он содержит открытый SSH -ключ клиентской системы, подключающейся к нему с помощью SSH -ключей. Помните, что закрытый ключ должен оставаться на клиентской системе и никогда не передаваться.

Файл authorized_keys должен принадлежать пользователю на удаленной системе. Кроме того, пользователь должен иметь права на чтение и запись.

Если это не так, установите разрешения на файл, как показано на рисунке.

sudo chmod 600 ~/.ssh/authorized_keys ls -l .ssh/authorized_keys

На клиентской системе убедитесь, что Public и Private Keys имеют правильные разрешения.

• Закрытый ключ* должен иметь разрешения на чтение и запись только для владельца файла.
• Публичный ключ* должен иметь разрешения на чтение и запись для владельца файла и разрешения на чтение для группы и других глобальных пользователей.

Если это не так, настройте разрешения следующим образом в восьмеричном формате.

sudo chmod 600 ~/.ssh/id_rsa sudo chmod 644 ~/.ssh/id_rsa.pub

Это два основных способа, которые вы можете использовать для устранения ошибки «ssh permission denied public key». Может быть, мы упустили что-то еще? Сообщите нам об этом в комментариях.

Зарубин Иван Эксперт по Linux и Windows

Парашютист со стажем. Много читаю и слушаю подкасты. Люблю посиделки у костра, песни под гитару и приближающиеся дедлайны. Люблю путешествовать.

Не запускается скрипт linux: permission denied

Нахожусь в папке, где располагается скрипт. Через «sh имя скрипта» он запускается. А через «./имя скрипта». Получаю permission denied . По заданию надо чтобы он запустился при ./ (он запускается из другого скрипта, этот скрипт редактировать нельзя)

Отслеживать
8,576 4 4 золотых знака 21 21 серебряный знак 36 36 бронзовых знаков
задан 22 авг 2022 в 6:56
Otveterohelp Otveterohelp
41 2 2 бронзовых знака

1 ответ 1

Сортировка: Сброс на вариант по умолчанию

сделайте скрипт исполняемым с помощью команды

chmod +x имяскрипта 

Отслеживать
ответ дан 22 авг 2022 в 7:01
1,632 3 3 серебряных знака 10 10 бронзовых знаков

• linux
• консоль

Важное на Мете

Похожие

Подписаться на ленту

Лента вопроса

Для подписки на ленту скопируйте и вставьте эту ссылку в вашу программу для чтения RSS.

Дизайн сайта / логотип © 2023 Stack Exchange Inc; пользовательские материалы лицензированы в соответствии с CC BY-SA . rev 2023.10.27.43697

Нажимая «Принять все файлы cookie» вы соглашаетесь, что Stack Exchange может хранить файлы cookie на вашем устройстве и раскрывать информацию в соответствии с нашей Политикой в отношении файлов cookie.

Ошибка: отказано в разрешении (publickey)

Ошибка «Отказано в разрешении» означает, что сервер отклонил подключение. Ниже приведено несколько причин и разъяснение по самым распространенным примерам.

Platform navigation

Should the sudo command or elevated privileges be used with Git?

You should not be using the sudo command or elevated privileges, such as administrator permissions, with Git. If you have a very good reason you must use sudo , then ensure you are using it with every command (it’s probably just better to use su to get a shell as root at that point). If you generate SSH keys without sudo and then try to use a command like sudo git push , you won’t be using the same keys that you generated.

Check that you are connecting to the correct server

Typing is hard, we all know it. Pay attention to what you type; you won’t be able to connect to «githib.com» or «guthub.com». In some cases, a corporate network may cause issues resolving the DNS record as well.

To make sure you are connecting to the right domain, you can enter the following command:

$ ssh -vT git@github.com > OpenSSH_8.1p1, LibreSSL 2.7.3 > debug1: Reading configuration data /Users/YOU/.ssh/config > debug1: Reading configuration data /etc/ssh/ssh_config > debug1: /etc/ssh/ssh_config line 47: Applying options for * > debug1: Connecting to github.com port 22. 

The connection should be made on port 22, unless you’re overriding settings to use SSH over HTTPS.

Always use the «git» user

All connections, including those for remote URLs, must be made as the «git» user. If you try to connect with your GitHub username, it will fail:

$ ssh -T GITHUB-USERNAME@github.com > Permission denied (publickey). 

If your connection failed and you’re using a remote URL with your GitHub username, you can change the remote URL to use the «git» user.

You should verify your connection by typing:

$ ssh -T git@github.com > Hi USERNAME! You've successfully authenticated.  

Make sure you have a key that is being used

1. Open Terminal Terminal Git Bash .
2. Verify that you have a private key generated and loaded into SSH.

# start the ssh-agent in the background $ eval "$(ssh-agent -s)" > Agent pid 59566 $ ssh-add -l -E sha256 > 2048 SHA256:274ffWxgaxq/tSINAykStUL7XWyRNcRTlcST1Ei7gBQ /Users/USERNAME/.ssh/id_rsa (RSA) 

If you have GitHub Desktop installed, you can use it to clone repositories and not deal with SSH keys.

If you are using Git Bash, turn on ssh-agent:

# start the ssh-agent in the background $ eval "$(ssh-agent -s)" > Agent pid 59566 

If you are using another terminal prompt, such as Git for Windows, turn on ssh-agent:

```shell # start the ssh-agent in the background $ eval $(ssh-agent -s) > Agent pid 59566 ``` 

Note: The eval commands above start ssh-agent manually in your environment. These commands may fail if ssh-agent already runs as a background system service. If that happens, we recommend you check the relevant documentation for your environment.

$ ssh-add -l -E sha256 > 2048 SHA256:274ffWxgaxq/tSINAykStUL7XWyRNcRTlcST1Ei7gBQ /Users/USERNAME/.ssh/id_rsa (RSA) 

1. Open Terminal Terminal Git Bash .
2. Verify that you have a private key generated and loaded into SSH.

$ ssh-add -l -E sha256 > 2048 SHA256:274ffWxgaxq/tSINAykStUL7XWyRNcRTlcST1Ei7gBQ /Users/USERNAME/.ssh/id_rsa (RSA) 

The ssh-add command should print out a long string of numbers and letters. If it does not print anything, you will need to generate a new SSH key and associate it with GitHub.

Tip: On most systems the default private keys ( ~/.ssh/id_rsa and ~/.ssh/identity ) are automatically added to the SSH authentication agent. You shouldn’t need to run ssh-add path/to/key unless you override the file name when you generate a key.

Getting more details

You can also check that the key is being used by trying to connect to git@github.com :

$ ssh -vT git@github.com > . > debug1: identity file /Users/YOU/.ssh/id_rsa type -1 > debug1: identity file /Users/YOU/.ssh/id_rsa-cert type -1 > debug1: identity file /Users/YOU/.ssh/id_dsa type -1 > debug1: identity file /Users/YOU/.ssh/id_dsa-cert type -1 > . > debug1: Authentications that can continue: publickey > debug1: Next authentication method: publickey > debug1: Trying private key: /Users/YOU/.ssh/id_rsa > debug1: Trying private key: /Users/YOU/.ssh/id_dsa > debug1: No more authentication methods to try. > Permission denied (publickey). 

In that example, we did not have any keys for SSH to use. The «-1» at the end of the «identity file» lines means SSH couldn’t find a file to use. Later on, the «Trying private key» lines also indicate that no file was found. If a file existed, those lines would be «1» and «Offering public key», respectively:

$ ssh -vT git@github.com > . > debug1: identity file /Users/YOU/.ssh/id_rsa type 1 > . > debug1: Authentications that can continue: publickey > debug1: Next authentication method: publickey > debug1: Offering RSA public key: /Users/YOU/.ssh/id_rsa 

Verify the public key is attached to your account

You must provide your public key to GitHub to establish a secure connection.

1. Open Terminal.
2. Start SSH agent in the background.

$ eval "$(ssh-agent -s)" > Agent pid 59566 

$ ssh-add -l -E sha256 > 2048 SHA256:274ffWxgaxq/tSINAykStUL7XWyRNcRTlcST1Ei7gBQ /Users/USERNAME/.ssh/id_rsa (RSA) 

In the upper-right corner of any page, click your profile photo, then click Settings.

1. Open the command line.
2. Start SSH agent in the background.

$ ssh-agent -s > Agent pid 59566 

$ ssh-add -l -E sha256 > 2048 SHA256:274ffWxgaxq/tSINAykStUL7XWyRNcRTlcST1Ei7gBQ /Users/USERNAME/.ssh/id_rsa (RSA) 

In the upper-right corner of any page, click your profile photo, then click Settings.

1. Open Terminal.
2. Start SSH agent in the background.

$ eval "$(ssh-agent -s)" > Agent pid 59566 

$ ssh-add -l > 2048 a0:dd:42:3c:5a:9d:e4:2a:21:52:4e:78:07:6e:c8:4d /Users/USERNAME/.ssh/id_rsa (RSA) 

If you’re using OpenSSH 6.8 or newer:

$ ssh-add -l -E md5 > 2048 MD5:a0:dd:42:3c:5a:9d:e4:2a:21:52:4e:78:07:6e:c8:4d /Users/USERNAME/.ssh/id_rsa (RSA) 

In the upper-right corner of any page, click your profile photo, then click Settings.

If you don’t see your public key in GitHub, you’ll need to add your SSH key to GitHub to associate it with your computer.

Warning: If you see an SSH key you’re not familiar with on GitHub, delete it immediately and contact us through the GitHub Support portal for further help. An unidentified public key may indicate a possible security concern. For more information, see «Reviewing your SSH keys.»