Итак, я проделывал один и тот же процесс снова и снова, и каждый раз работал отлично, но на конкретном сервере это просто не сработает.
Я пробовал любые письменные предложения в Интернете + serverfault, но ничего не работает.
Вскоре мне нужно клонировать репозиторий git на другом сервере с исходного сервера, но соединение ssh не будет работать. Я пытался исправить, но ничего не помогло.
Даже без ключа возникают такие же ошибки:
ssh -p **** -vvv git@*host.domain*
OpenSSH_4.3p2, OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to *host.domain* [***.***.***.***] port ****.
debug1: connect to address ***.***.***.*** port ****: Connection timed out
ssh: connect to host *host.domain* port ****: Connection timed out
Кроме того, после поиска исправлений в Интернете я заметил кое-что странное: я не могу перезапустить ssh, поскольку он обычно появляется с sudo service ssh restart, только с sudo service sshd restart. Не уверен, есть ли что-нибудь актуальное.
Если время ожидания соединения истекло, а не было немедленно отклонено, это, скорее всего, проблема брандмауэра. Очевидно, я не могу знать, какие устройства находятся между вашим клиентом и сервером, поэтому этот ответ ограничен брандмауэром на самом сервере.
Если вы не возражаете временно отключить брандмауэр хоста, вы можете проверить это, выполнив
# iptables-save > /tmp/ipt # iptables -F ...try your ssh connection again... # iptables-restore < /tmp/ipt
Если это исправит, вам нужно будет посмотреть на вывод iptables -nvL чтобы выяснить, какое правило блокирует ваше соединение.
Если у вас все еще есть проблемы, возможно, sshd сам по какой-то причине разрывает соединение. Вы можете попробовать запустить на сервере
# tcpdump host [address of client] and port 22
пока вы пытаетесь подключиться, чтобы узнать, действительно ли поступает трафик. Если вы ничего не видите, пока пытаетесь подключиться, и вы выполнили iptables -F, вполне вероятно, что какое-то промежуточное устройство отвечает за сброс трафика.
Временно разместите в своем /etc/sysctl.conf на указанном сервере следующая строка
net.ipv4.tcp_window_scaling = 0
который отключает масштабирование окна TCP. Попробуйте это, особенно если tcpdump (как было предложено Flup) показывает, что происходит обмен первыми тремя пакетами, которые инициируют TCP-соединение.
Между вашим сеансом и хостом на другой стороне может быть несколько брандмауэров. Вы можете подтвердить, что порт, о котором идет речь, доступен.
Один из способов сделать это - запустить nmap.
nmap host.domain
Результат будет выглядеть так:
Starting Nmap 5.51 ( http://nmap.org ) at 2013-03-13 07:32 EDT
Nmap scan report for host.domain (10.10.10.10)
Host is up (0.00023s latency).
rDNS record for 10.10.10.10: host.domain
Not shown: 998 closed ports
PORT STATE SERVICE
22/tcp open ssh
111/tcp open rpcbind
MAC Address: E0:DB:55:00:00:01 (Unknown)
Nmap done: 1 IP address (1 host up) scanned in 1.21 seconds
В этом примере вы можете видеть, что два порта открыты, и один из них - 22, порт, обычно связанный с ssh.
Это позволит вам подтвердить, что существует путь от вашего сервера к другому хосту.
Более подробную информацию можно найти на сайте веб-сайт nmap
Кроме того, sshd - это имя демона ssh и скрипта, который управляет демоном sshd, который находится в /etc/init.d. В служебной команде используются имена скриптов из /etc/init.d в redhat, centos и подобных дистрибутивах, следовательно:
service sshd restart
На СЕРВЕРЕ править / и т.д. / ssh / ssh_config
вставить следующее:
Host *
ServerAliveInterval 300
ServerAliveCountMax 2
Это отправит каждые 300 секунд сигнал сохранения активности максимум 2 раза. Если хотите, чтобы он был в комплекте Infiniti ServerAliveCountMax до 0
Если вы хотите остаться в живых ОТ клиента,
делать то же самое, но без "Хост *"