Linux создал пользователя не пускает по ssh

Устранение неполадок подключения по SSH в Linux

Неполадки, связанные с работой SSH совсем не редкость и возникают как по причине неправильных действий пользователей, таки из-за неправильно заданной конфигурации самой системы SSH. Но в любом случае, для устранения всевозможных неполадок, нужно уметь применять определённые методы, помогающие найти и исправить неполадку. В этой статье будут рассмотрены различные ситуации, в которых могут возникнуть ошибки c подключением по SSH, а также методы их устранения.

Неправильное имя хоста

При выполнении команды подключения по SSH на стороне клиента может быть получена ошибка:

Это значит, что имя хоста «hostname.com» не может быть сопоставлено с IP-адресом сервера SSH. Зачастую, это связано с работой DNS. В первую очередь, следует убедиться в правильности написания самого имени хоста. Также можно проверить разрешение этого хоста с помощью команды ping или сторонних сервисов. Если же во всех случаях наблюдается та же ошибка, можно попытаться подключиться, используя непосредственно IP-адрес:

Ошибка с истечением времени соединения

Такая ошибка происходит, когда сервер SSH не может ответить подключающемуся к нему клиенту в течение определённого промежутка времени:

Для исправления этой ошибки необходимо в первую очередь сделать следующее:

• проверить правильность имени и/или IP-адреса хоста сервера SSH;
• проверить, что указанный порт (22) доступен для подключения. В некоторых сетях он может быть заблокирован;
• проверить режим политики брандмауэра, политика которого по-умолчанию должна быть не DROP.

Отклонение соединения

Данная ошибка схожа с ошибкой истечения времени соединения и выглядит следующим образом:

Методы её устранения такие же, как и в случае, описанном в предыдущей главе, но дополнительно нужно проверить, что для подключения используется именно тот порт, который настроен на стороне сервера. Иногда, в целях безопасности его задают отличным от стандартного 22.

Настройка брандмауэра

Как известно, брандмауэры могут блокировать определённые порты и/или сетевые сервисы. Брандмауэров существует множество и в разных дистрибутивах Linux используются разные брандмауэры. Так, для Ubuntu это UFW, а для CentOS – FirewallD. Также можно использовать стандартный сервис iptables.

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

Если политика iptables по-умолчанию DROP (или REJECT), то необходимо для правил цепочки INPUT задать разрешение для порта, используемого для SSH.
Для брандмауэра FirewallD получить список используемых правил позволяет команда:

Для работы SSH в выводе должно быть правило «dhcpv6-client http ssh». Также необходимо проверить и порт, заданный для SSH. Для этого вместо опции «—list-services» нужно использовать «—list-ports».
Для брандмауэра UFW нужно выполнить:

Как видно, в списке должен присутствовать порт SSH, в данном случае 22. Он может быть и другим, в зависимости от того, что задано в настройках сервера SSH.

Проверка состояния сервера SSH

При получении ошибок подключения также не лишним будет проверить, запущен ли сам сервер SSH. Это можно сделать при помощи команды systemctl:

В случае, если демон SSH не работает, то в строке Active будет следующее:

Для запуска демона следует использовать команду:

Следует также обратить внимание на то, что обычно в дистрибутивах CentOS демон SSH называется sshd, а в Ubuntu – ssh.

Проверка порта для работы SSH

Чтобы проверить, какой порт настроен для использования сервером SSH, можно просмотреть соответствующий параметр в конфигурационном файле /etc/ssh/ssh_config . Для этого можно использовать команду grep для поиска по файлу:

Как видно из данного вывода, сервер SSH настроен на работу по стандартному порту 22. Параметр Port можно переопределять, но тогда необходимо внести изменения в соответствующие правила для брандмауэров, а также проинформировать клиентов о том, какой порт используется для подключения по SSH вместо стандартного.

Заключение

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

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Источник

Не пускает root-а через ssh! help!

Помогите решить такую проблему:

Зашел через putty на linux по ssh, но при вводе рутового пароля говорит что доступ закрыт. В поисках решения узнал, что рутом заходить нельзя ибо ето снимает сразу несколько слоев защиты, а для етого создается средствами sudo пользователь с правами рута. Так вот, создал юзера, добавил его в конфиг sudoerep как уполномоченного юзера в строку

# User privilege specification root admin ALL=(ALL) ALL

но ето ничего не дало. Потом создал ключи на клиентской тачке и скинул их на сервер в папку authorized_keys, тоже безрезультатно. Что я нетак сделал? Поделитесь опытом пожалуйста

Re: Не пускает root-а через ssh! help!

что-то у теюя в голове каша какая-то. если кратенько, то :
useradd vasya ; usermod -G wheel vasya ; passwd vasya
заходишь по ssh юзером vasya, потом делаешь su
а насчет sudo и ключей — это совсем другая песня.

Re: Не пускает root-а через ssh! help!

в /etc/ssh/sshd_config
раскомментировать
PermitRootLogin yes
перезапусить sshd

Re: Не пускает root-а через ssh! help!

ну-ну. первому anonymous-у — не советую так делать.

Re: Не пускает root-а через ssh! help!

сделал через su, пишет su toor su: incorrect password

Re: Не пускает root-а через ssh! help!

Почему?
Пусть человек решает подходит это для него, или нет, я просто поделился опытом по просьбе автора, предложил быстрое решение вопроса.

Re: Не пускает root-а через ssh! help!

уважаемый anonymus, я сделал так как вы сказали, т.е раскомментировать PermitRootLogin yes и перезапусить sshd, но результата никакого, хотелось бы узнать еще какието варианты решения

Re: Не пускает root-а через ssh! help!

Ну, у вас какой-то тяжелый случай 🙂
Сначала добейтесь, чтобы su работало, тогда может и удаленный вход заработает.
С паролями у вас все ок?
под пользователем удаленно заходите?
с консоли рутом заходите?
Что значит «никакого результата», а в логах (/var/log/messages) есль что-нить интересное?

Источник

Не включается доступ пользователя по ssh

Доброго времени суток!
Пытаюсь настроить доступ к машине не рутовыми пользователями, под root заходит, пусть их имя на сервере будет user1, user2.
Использовал в sshd_config директиву AllowUsers user1@192.168.0.* user2 при подключении выдается ошибка:

Кто тебе сказал что можно использовать * ?

Доступ зпрещен, мне кажется что user1@192.168.0.* не верный формат, хотя я не уверен, попробуй в качестве теста указать просто user1 или user1@192.168.0.100 например.

Пробовал, не помогает.

Можно *, я с чем-то другим попутал.

1) ssh -vv user@host
2) sudo journalctl -u sshd

Он (ssh) пароль запрашивает и потом выдает Permission denied?

Переключи sshd на сервере в debug и смотри почему он не пускает

ну я и написал чтоб глянул лог сервера

sudo journalctl $(which sshd)

ну я и написал чтоб глянул лог сервера

В обычном режиме там будет Permission Denied без объяснения, надо включить verbouse / debug mode

A ssh -vvv безполезен в 99.99% случаях.

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

), потом еще отключить из authotised_keys соманду gitosis-serve, ставил на сервак ее, потом выпилил, это будет сервер с git-репозиториями, как можно догадаться.
Проблема теперь в другом. Теперь для рута клиент просит пассфразу для ключа, а для других пользователей пароль на сервере, WTF?

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

Когда подключаюсь от рута он просит пассфразу для дешифровки ключа.
Когда подключаюсь от user1 просит пароль.
Куда тут копнуть можно?

Пробовал ssh-copy-id -i user1@host
Рутовый ключ на сервере не удалял
Не помогло
Так и так надо чтобы все полдбзователи подключались по ключу.

В общем, все из за моих косяков, под user1 не заходил потому что были права на его /

777, когда настраивал git — менял, поставил 755 теперь заходит по ключу, в принципе, вопрос закрыт, вот скину конфу sshd на сервере:

/.ssh).
2) ssh требователен к правам доступа в обоих системах.
3) Одна директива может помешать другой, например UsePAM yes мешает RSAAuthentication yes и PubkeyAuthentication yes

кот бы сомневался! sshd debug mode сразу показал бы тебе причину.

А я и не говорил, что я не накосячил, но сами по себе программы выполняются пошагово, значит и ошибки выявляются так же. Да и 98% проблем с компьютером возникают из за того, что кто-то сидит перед монитором.

3) Одна директива может помешать другой, например UsePAM yes мешает RSAAuthentication yes и PubkeyAuthentication yes

4.8. Дискуссии не на русском языке.

По-русски бы это звучало так: «я не понимаю что делают эти инструкции, но заметил, что если некоторые из них понатыкать в конфиг, то sshd начинает вести себя не так, как я ожидал».

По-русски ваши сообщения звучат так: я самый умный а все вокруг лохи, а ЛОР создан для того чтобы я повышал свою самооценку, ведь только я один умею читать документацию.

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

Источник

Устранение неполадок SSH: проблемы с подключением к серверу

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

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

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

Требования

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

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

Разрешение имени хоста

Большинство ошибок подключения возникает тогда, когда ссылка на хост SSH не может быть сопоставлена с сетевым адресом. Это почти всегда связано с DNS, но первопричина часто бывает не связана с DNS.

На клиенте OpenSSH эта команда:

может выдать ошибку:

ssh: Could not resolve hostname example.com: Name or service not known

В PuTTY может появиться такая ошибка:

Unable to open connection to example.com Host does not exist

Чтобы устранить эту ошибку, можно попробовать следующее:

• Проверьте правильность написания имени хоста.
• Убедитесь, что вы можете разрешить имя хоста на клиентской машине с помощью команды ping. Обратитесь к сторонним сайтам (WhatsMyDns.net, например), чтобы подтвердить результаты.

Если у вас возникают проблемы с разрешением DNS на любом уровне, в качестве промежуточного решения можно использовать IP-адрес сервера, например:

ssh user@111.111.111.111
# вместо
ssh user@example.com.

Истечение времени соединения

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

На клиенте OpenSSH следующая команда:

выдаст такую ошибку:

ssh: connect to host 111.111.111.111 port 22: Connection timed out

В PuTTY ошибка выглядит так:

Network error: Connection timed out

Чтобы исправить ошибку:

• Убедитесь, что IP-адрес хоста указан правильно.
• Убедитесь, что сеть поддерживает подключение через используемый порт SSH. Некоторые публичные сети могут блокировать порт 22 или пользовательские SSH-порты. Чтобы проверить работу порта, можно, например, попробовать подключиться к другим хостам через этот же порт. Это поможет вам определить, не связана ли проблема с самим сервером.
• Проверьте правила брандмауэра. Убедитесь, что политика по умолчанию – не DROP.

Отказ в соединении

Эта ошибка означает, что запрос передается на хост SSH, но хост не может успешно принять запрос.

На клиенте OpenSSH следующая команда выдаст ошибку:

ssh user@111.111.111.111
ssh: connect to host 111.111.111.111 port 22: Connection refused

В PuTTY ошибка появится в диалоговом окне:

Network error: Connection refused

Эта ошибка имеет общие с ошибкой Connection Timeout причины. Чтобы исправить её, можно сделать следующее:

• Убедиться, что IP-адрес хоста указан правильно.
• Убедиться, что сеть поддерживает подключение через используемый порт SSH. Некоторые публичные сети могут блокировать порт 22 или пользовательские SSH-порты. Чтобы проверить работу порта, можно, например, попробовать подключиться к другим хостам через этот же порт.
• Проверить правила брандмауэра. Убедитесь, что политика по умолчанию – не DROP, и что брандмауэр не блокирует этот порт.
• Убедиться, что сервис запущен и привязан к требуемому порту.

Рекомендации по исправлению ошибок подключения

Брандмауэр

Иногда проблемы с подключением возникают из-за брандмауэра. Он может блокировать отдельные порты или сервисы.

В разных дистрибутивах используются разные брандмауэры. Вы должны научиться изменять правила и политики своего брандмауэра. В Ubuntu обычно используется UFW, в CentOS – FirewallD. Брандмауэр iptables используется независимо от системы.

Читайте также:

Чтобы настроить брандмауэр, нужно знать порт сервиса SSH. По умолчанию это порт 22.

Чтобы запросить список правил iptables, введите:

Такой вывод сообщает, что правил, блокирующих SSH, нет:

Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination

Если в выводе вы видите правило или политику по умолчанию REJECT или DROP, убедитесь, что цепочка INPUT разрешает доступ к порту SSH.

Чтобы запросить список правил FirewallD, введите:

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

dhcpv6-client http ssh

Если вы настроили пользовательский порт SSH, используйте опцию –list-ports. Если вы создали пользовательское определение сервиса, добавьте опцию –list-services, чтобы найти SSH.

Чтобы проверить состояние UFW, введите:

Команда вернёт доступные порты:

Status: active
To Action From
— —— —-
22 LIMIT Anywhere
443 ALLOW Anywhere
80 ALLOW Anywhere
Anywhere ALLOW 192.168.0.0
22 (v6) LIMIT Anywhere (v6)
443 (v6) ALLOW Anywhere (v6)
80 (v6) ALLOW Anywhere (v6)

В списке должен быть порт SSH.

Проверка состояния сервиса SSH

Если вы не можете подключиться к серверу по SSH, убедитесь, что сервис SSH запущен. Способ сделать это зависит от операционной системы сервера. В более старых версиях дистрибутивов (Ubuntu 14.04, CentOS 6, Debian 8) используется команда service. Современные дистрибутивы на основе Systemd используют команду systemctl.

Метод проверки состояния сервиса может варьироваться от системы к системе. В более старых версиях (Ubuntu 14 и ниже, CentOS 6, Debian 6) используется команда service, поддерживаемая системой инициализации Upstart, а в более современных дистрибутивах для управления сервисом используется команда systemctl.

Примечание: В дистрибутивах Red Hat (CentOS и Fedora) сервис называется sshd, а в Debian и Ubuntu – ssh.

В более старых версия используйте команду:

service ssh status

Если процесс работает должным образом, вы увидите вывод, который содержит PID:

ssh start/running, process 1262

Если сервис не работает, вы увидите:

В системах на основе SystemD используйте:

systemctl status sshd

В выводе должна быть строка active:

sshd.service — OpenSSH server daemon
Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled)
Active: active (running) since Mon 2017-03-20 11:00:22 EDT; 1 months 1 days ago
Process: 899 ExecStartPre=/usr/sbin/sshd-keygen (code=exited, status=0/SUCCESS)
Main PID: 906 (sshd)
CGroup: /system.slice/sshd.service
├─ 906 /usr/sbin/sshd -D
├─26941 sshd: [accepted] └─26942 sshd: [net]

Если сервис не работает, вы увидите в выводе inactive:

sshd.service — OpenSSH server daemon
Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled)
Active: inactive (dead) since Fri 2017-04-21 08:36:13 EDT; 2s ago
Process: 906 ExecStart=/usr/sbin/sshd -D $OPTIONS (code=exited, status=0/SUCCESS)
Process: 899 ExecStartPre=/usr/sbin/sshd-keygen (code=exited, status=0/SUCCESS)
Main PID: 906 (code=exited, status=0/SUCCESS)

Чтобы перезапустить сервис, введите соответственно:

service ssh start
systemctl start sshd

Проверка порта SSH

Существует два основных способа проверить порт SSH: проверить конфигурационный файл SSH или просмотреть запущенный процесс.

Как правило, конфигурационный файл SSH хранится в /etc/ssh/sshd_config. Стандартный порт 22 может переопределяться любой строкой в этом файле, определяющей директиву Port.

Запустите поиск по файлу с помощью команды:

grep Port /etc/ssh/sshd_config

Если вы уже убедились, что сервис работает, теперь вы можете узнать, работает ли он на требуемом порте. Для этого используйте команду ss. Команда netstat –plnt выдаст аналогичный результат, но команду ss рекомендуется использовать для запроса информации сокета из ядра.

В выводе должно быть указано имя программы и порт, который она прослушивает. Например, следующий вывод сообщает, что сервис SSH прослушивает все интерфейсы и порт 22.

State Recv-Q Send-Q Local Address:Port Peer Address:Port
LISTEN 0 128 *:22 *:* users:((«sshd»,pid=1493,fd=3))
LISTEN 0 128 . 22 . * users:((«sshd»,pid=1493,fd=4))

Символ * и 0.0.0.0 указывает, что все интерфейсы сервера прослушиваются. Строка 127.0.0.1 значит, что сервис не является общедоступным. В sshd_config директива ListenAddress должна быть закомментирована, чтобы прослушивать все интерфейсы, или должна содержать внешний IP-адрес сервера.

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

Источник