Не подключается по ssh ubuntu permission denied
Обновлено: 08.07.2024
Ваш файл конфигурации из шага 2 должен иметь примерно следующее:
Вы можете добавить IdentitiesOnly yes , чтобы убедиться, что ssh использует ] IdentityFile и никаких других ключевых файлов во время аутентификации, что может вызвать проблемы и не рекомендуется.
Устранение неполадок
- используйте параметр «-vvv»
- Убедитесь, что на сервере есть ваш PUBLIC ключ (.pub ).
- Убедитесь, что ваш файл IdentiyFile указывает на ваш ЧАСТНЫЙ ключ.
- Убедитесь, что ваш каталог .ssh имеет 700 прав, а файлы внутри - 600 прав.
- tail -f / var / log /auth.log (на сервере) и отслеживать ошибки при попытке входа в систему
- Если у вас много файлов ключей, попробуйте IdentitiesOnly yes , чтобы ограничить аутентификацию с использованием одного указанного ключа .
Следующий метод может работать, если у вас есть независимый доступ к machineA и machineB (например, с machineC).
Если ssh-copy-id не работает, аутентификацию по паролю можно отключить. Ниже приводится обходной путь .
Наличие открытого ключа machineA в авторизованных ключах machineB (то есть
/ .ssh / authorized_keys) позволит вам использовать ssh с machineA. Это также относится к scp.
После генерации пар ключей с помощью: ssh-keygen
На machineA выполните cat
ssh-rsa AAAAB3NzaSGMFZW7yB anask @ mahineA
Скопируйте распечатанный ключ ( ⌘ Команда + C или CRTL + ), затем 1110330910] добавьте его в файл
/ .ssh / authorized_keys на machineB .
Например, выполните следующее на machineB :
echo 'ssh-rsa AAAAB3NzaSGMFZW7yB anask @ mahineA '>>
Если все остальное не удалось, убедитесь, что ваш логин принадлежит к AllowedGroup ssh. То есть ваши пользователи являются членами группы, показанной в следующей строке в / etc / ssh / sshd_config на сервере:
В моем случае проблема была вызвана копированием каталога .ssh со старой машины. Оказалось, что моя старая конфигурация SSH использовала ключи DSA, которые с тех пор устарели . Переход на новую пару ключей, на этот раз на основе RSA, решил проблему для меня.
Также работает на Ubuntu 16.04.
Проблема находится в файле sshd_config
Вот решение ULTIMATE:
Зарегистрируйтесь как root для своего сервера Ubuntu
Теперь перейдите в самый низ и измените значение с " нет "на" да ".
Это должно выглядеть так:
Измените на нет, чтобы отключить туннелированные пароли в открытом виде
, чтобы они вступили в силу.
Теперь вы можете просто ввести ключ, используя следующую команду со своего ЛОКАЛЬНОГО компьютер (он же ноутбук и т. д.)
Итак, чтобы открыть новое окно терминала и НЕ входить на сервер, просто используйте эту команду:
ssh-copy-id john @ serverIPAddress
(замените john своим именем пользователя) .
вам должно быть хорошо идти
Некоторые люди, которым интересно, возможно, настроили доступ по ssh к быть ключом только для учетной записи root, затем создал нового пользователя и не осознал, что ему нужно
ssh root @ your-ip-address
rsync --archive --chown = [user]: [user]
/. ssh / home / [user]
Затем попробуйте еще раз. Замените [user] своей новой учетной записью.
Это обычное дело при настройке нового сервера в DigitalOcean, когда вы использовали ssh-ключи при настройке.
У меня была такая же проблема, как описано в вопросе.Результат выполнения ssh -vvv -i id_rsa [youruser] @ [yourLinode] на клиентской машине был аналогичен описанному в вопросе. Я проверил все разрешения для файлов и каталогов, как было рекомендовано в других ответах, и они были правильными.
Оказалось, что при копировании сгенерированного файла id_rsa.pub на серверную машину в виде файла ]
username / .ssh / authorized_keys , Я бы случайно пропустил слово ssh-rsa с самого начала. Добавление его решило проблему.
Это то, что у меня сработало, исправление не мое, но я бы предпочел записать его здесь на случай, если кто-то другой имеет ту же проблему.
Сохраните файл и перезапустите ssh
ssh теперь должен работать, запрашивая пароль
У меня была такая же проблема при копировании открытого ключа обычного пользователя (например, johndoe) из системы cPanel Centos на сервер Ubuntu на AWS. Как было предложено gertvdijk выше, я проверил /var/log/auth.log и, конечно же, он сказал В аутентификации отказано: неправильное владение или режимы для каталога / home / johndoe . Оказалось, что я ошибочно 777'ed / home / johndoe при попытке установить / home / johndoe / public_html в качестве корневого каталога документов виртуального хоста по умолчанию для apache2 (это также не требуется для этой задачи)
См. Также ответы здесь и здесь
Сервер должен иметь только открытый ключ в .ssh / authorized_keys , а клиент (компьютер, на котором вы работаем)должен иметь закрытый ключ (.pem, или, если используется SFTP с Filezilla, .ppk)
В этом руководстве мы рассмотрим, как разрешить или запретить доступ 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 к любому пользователю или группе, вам необходимо добавить / изменить следующие директивы в файле 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.
Everytime I'm trying to execute "ssh localhost" the following line is added to /var/log/auth.log:
Can anyone suggest anything please?
611 1 1 gold badge 5 5 silver badges 8 8 bronze badges4 Answers 4
After reading some good manuals I realized that the public key of ubuntu@ (e.g., /home/ubuntu/.ssh/id_dsa.pub) must be added to the user's /home/ubuntu/.ssh/authorized_keys file, which contains public keys for public key authentication)
40.3k 23 23 gold badges 67 67 silver badges 97 97 bronze badges 611 1 1 gold badge 5 5 silver badges 8 8 bronze badgesIf you're running Ubuntu on Windows Subsystem for Linux, there will not be a preinstalled public key or authorized keys list, so you'll need to generate your own.
If you don't already have openssh-server installed:
- sudo apt-get upgrade
- sudo apt-get update
- sudo apt-get install openssh-server
- sudo service ssh start
Then take the following steps to enable ssh ing to localhost:
Thank you for this. Helped my troubleshoot CentOS Lightsail Server.Apart from adding public key you may want to change a PasswordAuthentication from 'no' to 'yes' (it may be 'no' by default in a fresh installed ssh).
save and exit. Then reload ssh server
Note: PasswordAuthentication is not recommended from the security point, disable it and use SSH key if your server is exposed to the internet.
The debug message actually provides information about the root cause of the error.
To authenticate with public key, the client will send SSH_MSG_USERAUTH_REQUEST that contains its public key to the server. When receiving this message, the server will check if the public key has been authorized (usually against the authorized_keys file).
The client had several public keys created with different algorithms ( id_rsa.pub , id_dsa.pub , id_ecdsa.pub , id_ed25519.pub ). When authenticating, the client started by offering the server with the default public key id_rsa.pub and rotated through the remaining public keys when the server responded that it could not authorize the provided public key. Finally, when all the public keys failed to be authorized, the SSH client displayed Permission denied message.
The preauth label was shown to indicate the connection was closed before authentication process was completed.
You can refer to this article about the sequences of the messages exchanged between the client and server in SSH public key authentication.
На сервере это порт 2042. Если я указываю неправильный порт, то выводится "ssh: connect to host xx.xx.xx.xx port 22: Connection timed out". То есть порт можно уточнять в команде ssh, что я и делаю. Значит ошибка не в этом.
3) скопировал публичный ключ id_dsa.pubв домашнюю директорию на удалённый сервер
Вероятно по этой причине не работает, так как по умолчанию ssh ищет ключи в файле
/.ssh/authorized_keys а не в домашней директории. По этому либо копируй ключ правильно на сервер командой
либо на сервере редактируй конфиг sshd_conf, опция AuthorizedKeysFile
Уточню, что скопировал я ключ туда, куда сказал администратор. в директорию
/.ssh/
Доступа к конфигу на удалённом сервере не имею.
Статью по ссылке я читал. Всё практически выполняю как там написано, но ошибка, вероятно, в каких-то особых конфигах скрыта.
При настройках по умолчанию у тебя на клиентской стороне ключи должный быть в папке
$HOME/.ssh/
что-то типа id_dsa, id_dsa.pub
На стороне сервера публичные ключи хранятся в файле
$HOME/.ssh/authorized_keys
Администратор мне сообщил, что публичный ключ id_dsa.pub нужно поместить в
/.ssh/id_dsa. Но это не помогает.
Кстати, не очень понятно, как можно использовать команду ssh-copy-id, которая работает при помощи ssh, если сам ssh я ещё не настроил?
Я так сделал и мне вывелось: /usr/bin/ssh-copy-id: ERROR: No identities found
Кстати, не очень понятно, как можно использовать команду ssh-copy-id, которая работает при помощи ssh, если сам ssh я ещё не настроил?
Имеется в виду, что есть доступ на сервер и до копирования ключей в ssh работает авторизация по паролю.
Можно попробовать на сервере из папки .ssh сделать
cat id_dsa.pub >> authorized_keys
это добавит ключ в конец файла authorized_keys
Файл "authorization" с текстом "key id_dsa.pub" я также создал, как и требовал администратор. Это было сделано с самого начала.
Ещё интересный момент. Администратор сервера предложить скачать и скомпилировать из исходных кодов свою особую программу и использовать её для создания файла ключей и подключения по ssh? o_O Что это может значить? Особый безопасный шел?
Проблема решена с помощью программы PuTTY и генерирования ключей с помощью команды puttygen. Может кому пригодится, что ключи в openssh и putty это не одно и тоже.
Читайте также: