Устранение неполадок 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, вы можете обратиться за помощью к службе поддержки своего хостинг-провайдера.

Port 22: connection refused при подключении по ssh?

ky0, фтп не подойдет потому что у меня окно компонентов виндовс не работает 😀
https://toster.ru/q/536279?e=6580255#clarification.

вот я и ищу разные способы

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

окно компонентов виндовс не работает

включение компонентов необходимых для настройки IIS

Как эти три вещи связаны и почему Вы считаете, что они связаны?

no kex alg означает, что клиент и сервер не смогли придти к единому знаменателю в мнении о том, каким шифром пользоваться. Обычно это происходит при попытке подключиться с современного компа к дремучему серверу и наоборот.

ssh: connect to host github.com port 22: Connection timed out

I am under a proxy and I am pushing in to git successfully for quite a while.
Now I am not able to push into git all of a sudden.
I have set the RSA key and the proxy and double checked them, with no avail and git is throwing me the error shown in the title of the page.

17 Answers 17

For my case none of the suggested solutions worked so I tried to fix it myself and I got it resolved.

For me I am getting this error on my AWS EC2 UBUNTU instance, what I did to resolve it was to edit the ssh config (or add it if it does not exist).

And I added the following

Then, run the command ssh -T git@github.com to confirm if the issue is fixed.

Sometimes, firewalls refuse to allow SSH connections entirely. If using HTTPS cloning with credential caching is not an option, you can attempt to clone using an SSH connection made over the HTTPS port. Most firewall rules should allow this, but proxy servers may interfere

Hopefully this helps anyone else who’s having the same issue I did.

/.ssh/config and change the way you connect to GitLab.com. In that case, see this article: about.gitlab.com/2016/02/18/… – lucascavalcante Dec 5 ’18 at 3:14

The reason could be the firewall modification as you are under a network.(In which case they may deliberately block some ports)
To double check if this is the reason . do

this should timeout. If that’s the case use http protocol instead of ssh this way
just change your url in the config file to http.
Here is how :-

change entry of

Basic URL Rewriting

Git provides a way to rewrite URLs using git config. Simply issue the following command:

Now, as if by magic, all git commands will perform a substitution of git:// to https://

inside the .ssh folder Create «config» file

Quick workaround: try switching to a different network

I experienced this problem while on a hotspot (3/4G connection). Switching to a different connection (WiFi) resolved it, but it’s just a workaround — I didn’t get the chance to get to the bottom of the issue so the other answers might be more interesting to determine the underlying issue

I faced the same problem and couldn’t find a working solution. I faced this problem while setting up a local server and the git couldn’t connect through my proxy network but my workstation could. This was the output when I ran the command ssh -vT git@github.com

So I tried using an SSH connection made over the HTTPS port by editing the config file

/.ssh/config but to no avail.

Finally, I found this article which solved and exposed the real problem.

This is my config file and now git works perfectly well through ssh!

Your output should look like:

You need to edit your

/.ssh/config file. Add something like the following:

I was having this same issue, but the answer I found was different, thought someone might come across this issue, so here is my solution.

I had to whitelist 2 IPs for port 22 , 80 , 443 , and 9418 :

In case these IP’s don’t work, it might be because they got updated, you can find the most current ones on this page.

For me, the problem was from ISP side. The Port number was not enabled by the Internet Service Provider. So asked them to enable the port number over my network and it started working.
Only to test: Connect to mobile hotspot and type ssh -T git@bitbucket.org or git pull.
If it works, then ask your ISP to enable the port.

The answer above gave me the information needed to resolve this issue. In my case the url was incorrectly starting with ssh:///

To check the url in your git config is correct, open the git config file :-

Check the url entry. It should NOT have ssh:/// at the start.

If your url is correct, then the next step would be to try the answer above that suggests changing protocol to http.

Changing the repo url from ssh to https is not very meaningful to me. As I prefer ssh over https because of some sort of extra benefits which I don’t want to discard. Above answers are pretty good and accurate. If you face this problem in GitLab, please go to their official documentation page and change your config file like that.

Restart computer solved it for me.
Git version: 2.27.0.windows.1
OS version: Windows 10 v1909

The main reason was the change from the proxy installed by the company recently, which has blocked other ssh connections other than those to the company domain.

I was able to connect successfully by following these steps:

1. Double checked that the issue is what I am assuming by ssh -T git@github.com

It should end up in a timeout.

1. Edited the local remote URL by

ssh config —local -e

The important point is that in the url you have to change at 2 places.

from git@ to https:// and from github:username to github/username

In the end verify by doing a git fetch

When I accidentally switched to a guest wifi network I got this error. Had to switch back to my default wifi network.

I had this issue for 2 hours and it turns out removing the «s» from https and just do:

git clone -b
http:

ISSUE: Step to produce issue: git clone git@github.com:sramachand71/test.git for the first time in the new laptop ERROR ssh: connect to host github.com port 22: Connection timed out fatal: Could not read from remote repository.

Please make sure you have the correct access rights and the repository exists. SOLUTION for the first time in the system to clone we need to give double quotes for the clone command. $ git clone «git@github.com:sramachand71/test.git» i face this issue in the system even after everything was correct but noticed at last that double quote is must for url «repository_url.git» for first time or new user in the system.

I had this issue on a server of mine that was set up with it’s regular IP and a failover IP. The failover IP did not point to the server at this time. I had to remove the failover IP from the server configuration in /etc/netplan/01-netcfg.yaml . Pointing the failover IP to that server would have probably solved the issue as well.

Not the answer you’re looking for? Browse other questions tagged git ssh or ask your own question.

Linked

Related

Hot Network Questions

Subscribe to RSS

To subscribe to this RSS feed, copy and paste this URL into your RSS reader.

site design / logo © 2021 Stack Exchange Inc; user contributions licensed under cc by-sa. rev 2021.4.16.39093

By clicking “Accept all cookies”, you agree Stack Exchange can store cookies on your device and disclose information in accordance with our Cookie Policy.