No such file or directory linux ssh

bash: /home/user/.ssh/authorized_keys: нет такого файла или каталога

Создайте ключ ssh:
Команда:

Перемещение ключа на авторизованный ключ:
Команда:

/.ssh/authorized_keys являются ключами других компьютеров, к которым вы подключены / доверяете, а не своим собственным ключом.

Вы должны создать .ssh каталог и authorized_keys файл в первый раз.

Создайте .ssh каталог:

Установите правильные разрешения:

Создайте authorized_keys файл:

Установите правильные разрешения:

Разрешения важны! Это не будет работать без правильных разрешений!

Теперь вы можете добавить открытый ключ к authorized_keys файлу:

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

Как упомянул тердон, вы также можете просто использовать эту команду:

Это поместит ваш id_rsa.pub (в ваш

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

Если вам был отправлен открытый ключ по электронной почте для установки на удаленный сервер:

1) SSH на сервер. Я использовал PuTTY на Windows.

2) Настройте ключ:

Точно скопируйте ключ и вставьте его в новую строку в окне редактора. Убедитесь, что он занимает одну строку и сохраните.

Поскольку у меня недостаточно репутации, я добавляю это сюда. В дополнение к ответу Louis Matthijssen, если вы все еще не можете войти через ssh как созданный вами пользователь, например

это может быть связано с отсутствием разрешения владельца, которое необходимо добавить в папку /home/username/.ssh. У меня была такая же проблема, и вы можете дать это разрешение как:

Это может произойти просто потому, что вы создавали каталог и устанавливали права доступа как root , а не как имя пользователя, с которым вы хотите получить доступ к серверу.

Источник

Thread: Error when trying to log in using SSH: /bin/bash: No such file or directory

Thread Tools

Display

Error when trying to log in using SSH: /bin/bash: No such file or directory

I have a dedicated server running Ubuntu Server 12.04 64-bit. For a little more than a week now, I have been unable to log into it using SSH. The output I get is:

Note how the «System information» hasn’t been updated since Sat Jul 14 21:49:44 CDT 2012 (which is probably about when this problem started).

The websites hosted on this server (using Apache, PHP and MySQL) are still running fine, and I can still do things on it with Virtualmin/Webmin/Usermin.

Using Webmin’s built-in Java-based file manager, I have determined that /bin/bash does indeed exist, and that its permissions are 755 (allowing reading and execution by all users) and that the permissions for the /bin directory are 6755 (allowing reading and listing by all users).

I have also tried uploading the bash executable from my home desktop (also running Ubuntu 12.04 64-bit) to my home directory on the server and setting the shell to that by editing /etc/passwd, but that resulted in the same «No such file or directory» error for the bash path in my home directory.

Attempting to have SSH execute a command on the server rather than a login shell also yields the same error:

Trying to log in as other users also didn’t work.

Frankly, I’m at a loss.

If anyone has any ideas, please let me know! Thanks in advance.

Last edited by BlueZenith; July 24th, 2012 at 06:09 PM .

Источник

Не подключается по ssh c ключом с одного из компьютеров

Я пробую подключаться по ssh на удалённый сервер с рабочей машины. Установлена убунта 16.04, настраиваю подключение с авторизацией по ключу. Результат — после запуска команды ssh myservername в консоли ничего не происходит. При этом с другого компьютера всё работает. Но на нём винда. Работает также и с телефона. И только на убунте я не могу настроить.

Вот содержимое файла

Вот что получаю в консоли по команде ssh -v myservername

Что-то он у вас не видит ключа судя по логу, но вообще тут хорошо бы и логи на удаленном сервере посмотреть.

А что MTR говорит? Можешь еще с помощью wireshark дамп снять.
У меня с подобными симптомами провайдер доступ до хоста лочил. Просто прилетал RST.

Ааа! Кажется я понял в чём дело. У меня же этот комп в интернет ходит через прокси. Видимо ssh клиент не подхватывает настройки прокси. И да, небольшое, но печальное уточнение. У меня тут нет рута. Так что все соверы что-то доустановить, увы, не пригодны.

Вот меня тоже мучает подозрение, что он не видит ключа. Но как же так? Ключ есть, владелец — тот же пользователь, под которым я ssh запускаю. Права у владельца все есть на файл. Даже командой cat /home/USER/.ssh/id_rsa файл ключа могу прочитать. Даже не знаю, куда ещё копать?

Права на /home/USER/.ssh должны быть 700 (rwx——), на /home/USER/.ssh/id_rsa 600 (rw——-), все так?

А что за прокси? ssh может работать с проксями, нужно смотреть в сторону опции proxy command .

Да, права на файл и папку именно такие. Спасибо, смотрю в сторону опции proxy command. Пока что с наскока ничего не получилось. Копаюсь глюбже 🙂

заменить на id_ecdsa или id_ed25519

у тебя, кстати, тут написано

key_load_public: No such file or directory

Как заменить? Тупо файл переименовать и ссылку в конфиге на него и всё?

нет, сделать ssh-keygen

До проверки наличия Identity-файла еще не дошло, при неправильных правах на файле — будет ругань в логе.
После строки debug1: Local version string SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.4 должно показать версию ssh-сервера на удаленной стороне, а у вас — Connection timed out
Что показывает telnet при подключении к удаленной стороне на указанный в конфиге порт?
Должно быть что-то типа этого, со строкой SSH-X.X-чего-тоо_там с_какой-то_ОС :

telnet не показывает никакого ответа. Хотя я нашел разные онлайновые тулзы для запуска команды telnet, так через них показывает именно то, что вы указали.

В общем, зарезали у меня всё капитально. Ничего не работает. Вдвойне обидно, что раньше у меня стояла винда и proxifier на ней. И всё работало без малейших проблем. А теперь вот поставили линукс, и я уже ничего не понимаю. Такое чувство, что работать должно, но я элементарно не могу пролезть через прокси. Причём что всё остальное я настроил на работу с прокси. Всякие там apt-get, git, браузеры, сетественно. А вот ssh и telnet — никак не могу.

Что за прокси (протокол)

Что именно за прокси (socks,http)? Как пробовали обойти? Есть ли рут на сервере?

Прокси http. Рута нет. Могу попросить админа что-то сделать, но для эксперементов мне рута не дадут. Нужно уже знать что делать, когда просить рут. Как пробовал обойти? Ну как писали выше, опцией proxy command. Ещё в .bashrc прописаны настройки прокси, но не знаю для чего.

Плохо гуглили

если не получится пиши подробно что как делаешь

Неожиданно мне дали права sudo. Воспользовавшись этим, я установил Corkscrew, настроил, и всё взлетело. Всем спасибо за помощь.

Источник

Устранение неполадок SSH: ошибки оболочки

В первой статье этой серии вы узнали о том, как и в каких ситуациях вы можете попробовать исправить ошибки SSH. Остальные статьи расскажут, как определить и устранить следующие ошибки:

• Проблемы с подключением к серверу: здесь вы узнаете, как исправить ошибки подключения к серверу.
• Ошибки протокола: в этой статье вы узнаете, что делать, если сбрасываются клиентские соединения, клиент жалуется на шифрование или возникают проблемы с неизвестным или измененным удаленным хостом.
• Ошибки аутентификации: поможет устранить проблемы с парольной аутентификацией или сбросом SSH-ключей.

Установив соединение SSH, вы получаете доступ к удалённой среде оболочки. Это руководство поможет исправить самые распространённые ошибки, которые могут возникнуть на данном этапе.

Требования

• Убедитесь, что можете подключиться к виртуальному серверу через консоль.
• Проверьте панель на предмет текущих проблем, влияющих на работу и состояние сервера и гипервизора.

Основные ошибки

Не открывается домашний каталог

Иногда в системе нарушаются права собственности и доступа, и это вызывает проблемы с доступом к домашнему каталогу. Появляется ошибка:

Could not chdir to home directory /home/user: Permission denied
Error
Could not chdir to home directory /home/user: Input/output error
Error
Could not chdir to home directory /home/user: No such file or directory

Ошибки могут возникнуть, если домашний каталог не существует, неправильно указаны его права собственности или у пользователя нет доступа. Также это случается, если повреждена файловая система в домашнем каталоге.

Учётная запись недоступна

У некоторых пользователей системы отключена оболочка входа. При запросе оболочка не будет отвечать. Это вызовет ошибку:

This account is currently not available.

Это случается, если:

• Запрашиваемый пользователь не предназначен для рутинной работы, потому доступ к командной оболочке отключен.
• Пользовательской оболочке присвоен параметр nologin, true или false. В этом случае вы можете обновить пользовательскую оболочку.

Ресурс временно недоступен

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

Вы получите такую ошибку:

ssh: connect to host example.com port 22: Resource temporarily unavailable

Проблемы с ресурсами довольно сложно устранить; во многом методы будут зависеть от типа вашего сервера.

Устранение неполадок

Проверка домашнего каталога

Чтобы проверить права доступа и собственности на домашний каталог, нужно подключиться к серверу через консоль как пользователь root. Убедитесь, что каталог /home существует (для этого можно использовать утилиту stat).

Если каталог существует в системе, убедитесь, что пользователь имеет права доступа (минимум 700) и права собственности на него.

Примечание: Имеются в виду права обычного пользователя, а не root.

Обновление оболочки

Откройте консоль, войдите как пользователь root или sudo.

Просмотрите файл /etc/passwd или запросите данные с помощью getent.

getent passwd user

В выводе команды найдите /usr/sbin/nologin:

Чтобы обновить оболочку, используйте команду usermod и укажите рабочую оболочку, например, /bin/bash.

usermod -s /bin/bash user

Снова запустите getent.

Теперь попробуйте снова получить доступ к оболочке пользователя.

Устранение проблем с ресурсами

Устранение проблем с ресурсами – очень специфическая ситуация.

Если источником конфликта ресурсов являются сетевые запросы (например, атака на веб-приложение), вы можете отключить сервис или заблокировать трафик на брандмауэре с помощью веб-консоли. Так вы сможете оценить влияние ситуации, выбрать стратегию смягчения последствий, а также рассмотреть возможность масштабирования вашего приложения.

Если вы не можете войти в систему через веб-консоль, последний вариант –перезагрузить сервер. В зависимости от причины нехватки ресурса вы либо сразу попадёте в ту же среду, либо успеете получить доступ к консоли до того, как случится ошибка Unable to fork process при попытке запустить команду. После перезагрузки очень важно поймать момент и использовать веб-консоль или SSH-соединение с сервером, прежде чем они перестанут отвечать.

Если у вас не получается самостоятельно устранить ошибки оболочки SSH, обратитесь за помощью к службе поддержки своего хостинг-провайдера.

Источник

ssh после обновления

После обновления при попытке зайти по ssh-y, выдаёт вот такое: Эти файлы (точнее один из них) требуется создавать ТОЛЬКО если вы используете аутентификацию по ключу, причём именно заданного типа (RSA, DSA или ECDSA).

Очевидно, ругань на отсутствующие ключи возникла из-за бага в новой версии OpenSSH.
У меня то же самое, только ключ RSA имеется, поэтому он ругается на отсутствие остальных

Это если при создании ключа Вы закодировали его, введя еще и passphrase. Внимательно прочитайте, какие вопросы задаются при создании новой пары ключей.

kurych
Это если при создании ключа Вы закодировали его, введя еще и passphrase. Внимательно прочитайте, какие вопросы задаются при создании новой пары ключей.

arcanis, если вы не поняли мой прошлый пост, разжевываю ещё более прямо – ругань клиента OpenSSH после обновления говорит НЕ о необходимости для ВАС что-то делать, а исключительно о БАГЕ новой версии самого клиента OpenSSH, который на самом деле НЕ должен ругаться на отсутствие ключей, которые всё равно не используются!

Что за дурацкая привычка – считать каждый новый глюк нововведением, если он приводит к выдаче требовательных сообщений :))

Natrio
arcanis, если вы не поняли мой прошлый пост, разжевываю ещё более прямо – ругань клиента OpenSSH после обновления говорит НЕ о необходимости для ВАС что-то делать, а исключительно о БАГЕ новой версии самого клиента OpenSSH, который на самом деле НЕ должен ругаться на отсутствие ключей, которые всё равно не используются!

Что за дурацкая привычка – считать каждый новый глюк нововведением, если он приводит к выдаче требовательных сообщений :))

Volldemar
пытался создавать эти файлы вручную, никакого результата, как должны создавать эти файлы и чем?

/.ssh/id_rsa новое поведение уже никак не проявляется.
Если ключи не нужны, а мусор оскверняет чувство прекрасного, то можно запускать ssh с ключем «-q» (например, создать alias ssh=»ssh -q»)

kurych
Считаю, это не то, что бы баг, а просто лишние диагностические сообщения сыпятся.

Volldemar
пытался создавать эти файлы вручную, никакого результата, как должны создавать эти файлы и чем?

Как видите, «диагностические» сообщения действительно лишние – юзеры воспринимают их как руководство к действию и делают попытки создавать неиспользуемые ключи. Нафига? Тамагоча требует! :))

Если привыкли авторизоваться по ключам, то при наличии только

/.ssh/id_rsa новое поведение уже никак не проявляется.

Источник