Сервер SSH не работает (респауны до остановки)

Balsamiq Mockups - приложение, которое время от времени используется Марком и командой дизайнеров.

Это не бесплатно, но это кросс-платформенный (через Java) и предоставляет гораздо больше возможностей, чем Pencil.

12
задан 16 January 2011 в 17:12

84 ответа

Вы должны проверить, что произошло до того, как SSH начал барахтаться в syslog. Если сетевая подсистема умерла, это может объяснить, почему sshd начал сбой.

Я также проверил бы /var/log/auth.log. Это журнал sshd, и это может дать вам лучшее сообщение об ошибке.

7
ответ дан 25 May 2018 в 23:27
  • 1
    Благодаря! Я нашел много записей в файле auth.log, и я обновил свой вопрос. – Khaled 16 January 2011 в 17:12
  • 2
    reload должно быть действительным действием. Он должен инициировать внутренний перезапуск (и, похоже, он попытался это и просто застрял). Повторите перезагрузку и проверьте, не застрял ли она снова. – Oli♦ 16 January 2011 в 20:13
  • 3
    действительно, перезагрузка должна быть действительной, но есть ошибка. См. Мой ответ для получения дополнительной информации. – SpamapS 22 January 2011 в 03:38

Вы должны проверить, что произошло до того, как SSH начал барахтаться в syslog. Если сетевая подсистема умерла, это может объяснить, почему sshd начал сбой.

Я также проверил бы /var/log/auth.log. Это журнал sshd, и это может дать вам лучшее сообщение об ошибке.

7
ответ дан 25 July 2018 в 22:36

Вы должны проверить, что произошло до того, как SSH начал барахтаться в syslog. Если сетевая подсистема умерла, это может объяснить, почему sshd начал сбой.

Я также проверил бы /var/log/auth.log. Это журнал sshd, и это может дать вам лучшее сообщение об ошибке.

7
ответ дан 26 July 2018 в 23:02

Вы должны проверить, что произошло до того, как SSH начал барахтаться в syslog. Если сетевая подсистема умерла, это может объяснить, почему sshd начал сбой.

Я также проверил бы /var/log/auth.log. Это журнал sshd, и это может дать вам лучшее сообщение об ошибке.

7
ответ дан 31 July 2018 в 10:44

Вы должны проверить, что произошло до того, как SSH начал барахтаться в syslog. Если сетевая подсистема умерла, это может объяснить, почему sshd начал сбой.

Я также проверил бы /var/log/auth.log. Это журнал sshd, и это может дать вам лучшее сообщение об ошибке.

7
ответ дан 31 July 2018 в 11:49

Вы должны проверить, что произошло до того, как SSH начал барахтаться в syslog. Если сетевая подсистема умерла, это может объяснить, почему sshd начал сбой.

Я также проверил бы /var/log/auth.log. Это журнал sshd, и это может дать вам лучшее сообщение об ошибке.

7
ответ дан 2 August 2018 в 04:03

Вы должны проверить, что произошло до того, как SSH начал барахтаться в syslog. Если сетевая подсистема умерла, это может объяснить, почему sshd начал сбой.

Я также проверил бы /var/log/auth.log. Это журнал sshd, и это может дать вам лучшее сообщение об ошибке.

7
ответ дан 4 August 2018 в 20:06

Вы должны проверить, что произошло до того, как SSH начал барахтаться в syslog. Если сетевая подсистема умерла, это может объяснить, почему sshd начал сбой.

Я также проверил бы /var/log/auth.log. Это журнал sshd, и это может дать вам лучшее сообщение об ошибке.

7
ответ дан 6 August 2018 в 04:06

Вы должны проверить, что произошло до того, как SSH начал барахтаться в syslog. Если сетевая подсистема умерла, это может объяснить, почему sshd начал сбой.

Я также проверил бы /var/log/auth.log. Это журнал sshd, и это может дать вам лучшее сообщение об ошибке.

7
ответ дан 6 August 2018 в 04:08

Вы должны проверить, что произошло только до SSH начал барахтаться в syslog . Если сетевая подсистема умерла, это могло бы объяснить, почему sshd начал сбой.

Я также проверил бы /var/log/auth.log . Это журнал sshd , и это может дать вам лучшее сообщение об ошибке.

7
ответ дан 7 August 2018 в 22:07

Вы должны проверить, что произошло только до SSH начал барахтаться в syslog . Если сетевая подсистема умерла, это могло бы объяснить, почему sshd начал сбой.

Я также проверил бы /var/log/auth.log . Это журнал sshd , и это может дать вам лучшее сообщение об ошибке.

7
ответ дан 10 August 2018 в 10:21

Вы должны проверить, что произошло только до SSH начал барахтаться в syslog . Если сетевая подсистема умерла, это могло бы объяснить, почему sshd начал сбой.

Я также проверил бы /var/log/auth.log . Это журнал sshd , и это может дать вам лучшее сообщение об ошибке.

7
ответ дан 13 August 2018 в 16:46
  • 1
    Благодаря! Я нашел много записей в файле auth.log , и я обновил свой вопрос. – Khaled 16 January 2011 в 17:12
  • 2
    reload должно быть действительным действием. Он должен запускать внутренний перезапуск (и, похоже, он попытался это и просто застрял). Повторите перезагрузку и проверьте, не застрял ли она снова. – Oli♦ 16 January 2011 в 20:13
  • 3
    действительно, перезагрузка должна быть действительной, но есть ошибка. См. Мой ответ для получения дополнительной информации. – SpamapS 22 January 2011 в 03:38

У меня была такая же проблема на моей коробке 12.04. То есть те же симптомы. Увы, это всегда случалось, когда я ввел предложение ListenAddress с адресами inet и inet6 в sshd_config. Короче говоря, это, по-видимому, является симптомом искаженного sshd_config - хотя в файлах журналов ничего не сказано.

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

То, что я нахожу вообще очень полезно в любых таких случаях - запустить sshd, не давая ему демонизировать. Проблема в моем случае заключалась в том, что ни syslog, ни auth.log не показали ничего значимого.

Когда я начал с терминала, я получил:

# $(which sshd) -Ddp 10222
/etc/ssh/sshd_config line 8: address family must be specified before ListenAddress.

Гораздо лучше! Это сообщение об ошибке позволило мне понять, что не так, и исправить.

NB: по крайней мере, на Ubuntu $(which sshd) - лучший способ удовлетворить требование sshd абсолютного пути. В противном случае вы получите следующую ошибку: sshd re-exec requires execution with an absolute path. [F14] делает sshd прослушиванием этого альтернативного порта, переопределяя конфигурационный файл - это значит, что он не сталкивается с потенциально запущенными экземплярами sshd. Обязательно выберите свободный порт здесь.

Этот метод много раз помогал мне в поиске проблем, будь то проверки подлинности или другие типы. Чтобы получить действительно подробный вывод в stdout, используйте $(which sshd) -Ddddp 10222 (обратите внимание на добавленный dd, чтобы увеличить многословие). Для большей проверки отладки man sshd.

16
ответ дан 25 May 2018 в 23:27
  • 1
    Твой прямой призыв только спас мой бекон. У меня была ошибка в файле sshd_config (сгенерированном от шеф-повара), который я смог решить, используя эту технику. СПАСИБО за то, что нашли время, чтобы опубликовать его всем. – Peter Laird 24 March 2013 в 10:35

Это похоже на ошибку # 687535, которая недавно была исправлена ​​в natty, и была добавлена ​​как maverick, так и lucid в качестве предлагаемого обновления.

https: //bugs.launchpad. net / ubuntu / lucid / + source / openssh / + bug / 687535

Я бы посоветовал всем пойти туда, попробовать тестовый пример (поиск TEST CASE) и опубликовать результаты как до, так и после установка предлагаемого исправления. Это поможет команде SRU решить, что проверка была выполнена, и опубликовать ее как обновление.

4
ответ дан 25 May 2018 в 23:27

В /etc/ssh/sshd_config убедитесь, что все опции yes и no в нижнем регистре. Например, если вы установили PermitRootLogin No, ssh не запустится. Это действительно должно быть PermitRootLogin no.

2
ответ дан 25 May 2018 в 23:27

У меня была аналогичная проблема с изображением Ubuntu 11.10 на Linode после перезапуска. Служба ssh создаст в syslog:

Mar 18 06:31:33 servername kernel: init: ssh main process ended, respawning
Mar 18 06:31:33 servername kernel: init: ssh main process (3419) terminated with status 255
Mar 18 06:31:33 servername kernel: init: ssh main process ended, respawning
Mar 18 06:31:33 servername kernel: init: ssh main process (3422) terminated with status 255
Mar 18 06:31:33 servername kernel: init: ssh respawning too fast, stopped

Это тестовая коробка, и у нее было около 60 дней безотказной работы, поэтому где-то по пути я установил что-то, что было добавлено к нижней части sshd_config:

ClientAliveInterval 60
ClientCountAliveMax 60

Комментирование этих строк позволило запустить ssh.

1
ответ дан 25 May 2018 в 23:27

Ubuntu ssh не запускается, и syslog дал «init: ssh main process (2044), завершенный статусом 255»

/ usr / sbin / sshd -Ddp 10222

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

0
ответ дан 25 May 2018 в 23:27

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

root@imt:~# sshd
sshd re-exec requires execution with an absolute path
ssh localhost
ssh: connect to host localhost port 22: Network is unreachable

Путь в порядке в соответствии с документом, поэтому я запускаю вручную sshd.

[ f2]

/ var / run / sshd.

root@imt:~# ls -ld /var/run/sshd
drwsrwsrwt 2 root root 40 Jan  5 12:58 /var/run/sshd

root@imt:~# chmod 755 /var/run/sshd

, тогда его штраф. запустите ssh localhost и проверьте.

root@imt:~# ssh localhost 
The authenticity of host 'localhost (127.0.0.1)' can't be established.
RSA key fingerprint is 64:93:fd:ab:4c:f9:7b:8a:86:60:22:f7:56:fa:ea:cc.
Are you sure you want to continue connecting (yes/no)? yes
-1
ответ дан 25 May 2018 в 23:27
  • 1
    Хотя это полезное руководство, это явно не то, что привело к неправильной работе OP sshd, как вы можете видеть из самых разных сообщений об ошибках в своих журналах. -1 – David Foerster 11 January 2016 в 13:30

У меня была аналогичная проблема с изображением Ubuntu 11.10 на Linode после перезапуска. Служба ssh создаст в syslog:

Mar 18 06:31:33 servername kernel: init: ssh main process ended, respawning Mar 18 06:31:33 servername kernel: init: ssh main process (3419) terminated with status 255 Mar 18 06:31:33 servername kernel: init: ssh main process ended, respawning Mar 18 06:31:33 servername kernel: init: ssh main process (3422) terminated with status 255 Mar 18 06:31:33 servername kernel: init: ssh respawning too fast, stopped

Это тестовая коробка, и у нее было около 60 дней безотказной работы, поэтому где-то по пути я установил что-то, что было добавлено к нижней части sshd_config:

ClientAliveInterval 60 ClientCountAliveMax 60

Комментирование этих строк позволило запустить ssh.

1
ответ дан 25 July 2018 в 22:36

В /etc/ssh/sshd_config убедитесь, что все опции yes и no в нижнем регистре. Например, если вы установили PermitRootLogin No, ssh не запустится. Это действительно должно быть PermitRootLogin no.

2
ответ дан 25 July 2018 в 22:36

У меня была такая же проблема на моей коробке 12.04. То есть те же симптомы. Увы, это всегда случалось, когда я ввел предложение ListenAddress с адресами inet и inet6 в sshd_config. Короче говоря, это, по-видимому, является симптомом искаженного sshd_config - хотя в файлах журналов ничего не сказано.

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

То, что я нахожу вообще очень полезно в любых таких случаях - запустить sshd, не давая ему демонизировать. Проблема в моем случае заключалась в том, что ни syslog, ни auth.log не показали ничего значимого.

Когда я начал с терминала, я получил:

# $(which sshd) -Ddp 10222 /etc/ssh/sshd_config line 8: address family must be specified before ListenAddress.

Гораздо лучше! Это сообщение об ошибке позволило мне понять, что не так, и исправить.

NB: по крайней мере, на Ubuntu $(which sshd) - лучший способ удовлетворить требование sshd абсолютного пути. В противном случае вы получите следующую ошибку: sshd re-exec requires execution with an absolute path. [F14] делает sshd прослушиванием этого альтернативного порта, переопределяя конфигурационный файл - это значит, что он не сталкивается с потенциально запущенными экземплярами sshd. Обязательно выберите свободный порт здесь.

Этот метод много раз помогал мне в поиске проблем, будь то проверки подлинности или другие типы. Чтобы получить действительно подробный вывод в stdout, используйте $(which sshd) -Ddddp 10222 (обратите внимание на добавленный dd, чтобы увеличить многословие). Для большей проверки отладки man sshd.

16
ответ дан 25 July 2018 в 22:36
  • 1
    Твой прямой призыв только спас мой бекон. У меня была ошибка в файле sshd_config (сгенерированном от шеф-повара), который я смог решить, используя эту технику. СПАСИБО за то, что нашли время, чтобы опубликовать его всем. – Peter Laird 24 March 2013 в 10:35

Это похоже на ошибку # 687535, которая недавно была исправлена ​​в natty, и была добавлена ​​как maverick, так и lucid в качестве предлагаемого обновления.

https: //bugs.launchpad. net / ubuntu / lucid / + source / openssh / + bug / 687535

Я бы посоветовал всем пойти туда, попробовать тестовый пример (поиск TEST CASE) и опубликовать результаты как до, так и после установка предлагаемого исправления. Это поможет команде SRU решить, что проверка была выполнена, и опубликовать ее как обновление.

4
ответ дан 25 July 2018 в 22:36

Ubuntu ssh не запускается, и syslog дал «init: ssh main process (2044), завершенный статусом 255»

/ usr / sbin / sshd -Ddp 10222

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

0
ответ дан 25 July 2018 в 22:36

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

root@imt:~# sshd sshd re-exec requires execution with an absolute path ssh localhost ssh: connect to host localhost port 22: Network is unreachable

Путь в порядке в соответствии с документом, поэтому я запускаю вручную sshd.

root@imt:~# /usr/sbin/sshd /var/run/sshd must be owned by root and not group or world-writable

/ var / run / sshd.

root@imt:~# ls -ld /var/run/sshd drwsrwsrwt 2 root root 40 Jan 5 12:58 /var/run/sshd root@imt:~# chmod 755 /var/run/sshd

, тогда его штраф. запустите ssh localhost и проверьте.

root@imt:~# ssh localhost The authenticity of host 'localhost (127.0.0.1)' can't be established. RSA key fingerprint is 64:93:fd:ab:4c:f9:7b:8a:86:60:22:f7:56:fa:ea:cc. Are you sure you want to continue connecting (yes/no)? yes
-1
ответ дан 25 July 2018 в 22:36
  • 1
    Хотя это полезное руководство, это явно не то, что привело к неправильной работе OP sshd, как вы можете видеть из самых разных сообщений об ошибках в своих журналах. -1 – David Foerster 11 January 2016 в 13:30

У меня была аналогичная проблема с изображением Ubuntu 11.10 на Linode после перезапуска. Служба ssh создаст в syslog:

Mar 18 06:31:33 servername kernel: init: ssh main process ended, respawning Mar 18 06:31:33 servername kernel: init: ssh main process (3419) terminated with status 255 Mar 18 06:31:33 servername kernel: init: ssh main process ended, respawning Mar 18 06:31:33 servername kernel: init: ssh main process (3422) terminated with status 255 Mar 18 06:31:33 servername kernel: init: ssh respawning too fast, stopped

Это тестовая коробка, и у нее было около 60 дней безотказной работы, поэтому где-то по пути я установил что-то, что было добавлено к нижней части sshd_config:

ClientAliveInterval 60 ClientCountAliveMax 60

Комментирование этих строк позволило запустить ssh.

1
ответ дан 26 July 2018 в 23:02

В /etc/ssh/sshd_config убедитесь, что все опции yes и no в нижнем регистре. Например, если вы установили PermitRootLogin No, ssh не запустится. Это действительно должно быть PermitRootLogin no.

2
ответ дан 26 July 2018 в 23:02

У меня была такая же проблема на моей коробке 12.04. То есть те же симптомы. Увы, это всегда случалось, когда я ввел предложение ListenAddress с адресами inet и inet6 в sshd_config. Короче говоря, это, по-видимому, является симптомом искаженного sshd_config - хотя в файлах журналов ничего не сказано.

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

То, что я нахожу вообще очень полезно в любых таких случаях - запустить sshd, не давая ему демонизировать. Проблема в моем случае заключалась в том, что ни syslog, ни auth.log не показали ничего значимого.

Когда я начал с терминала, я получил:

# $(which sshd) -Ddp 10222 /etc/ssh/sshd_config line 8: address family must be specified before ListenAddress.

Гораздо лучше! Это сообщение об ошибке позволило мне понять, что не так, и исправить.

NB: по крайней мере, на Ubuntu $(which sshd) - лучший способ удовлетворить требование sshd абсолютного пути. В противном случае вы получите следующую ошибку: sshd re-exec requires execution with an absolute path. [F14] делает sshd прослушиванием этого альтернативного порта, переопределяя конфигурационный файл - это значит, что он не сталкивается с потенциально запущенными экземплярами sshd. Обязательно выберите свободный порт здесь.

Этот метод много раз помогал мне в поиске проблем, будь то проверки подлинности или другие типы. Чтобы получить действительно подробный вывод в stdout, используйте $(which sshd) -Ddddp 10222 (обратите внимание на добавленный dd, чтобы увеличить многословие). Для большей проверки отладки man sshd.

16
ответ дан 26 July 2018 в 23:02
  • 1
    Твой прямой призыв только спас мой бекон. У меня была ошибка в файле sshd_config (сгенерированном от шеф-повара), который я смог решить, используя эту технику. СПАСИБО за то, что нашли время, чтобы опубликовать его всем. – Peter Laird 24 March 2013 в 10:35

Это похоже на ошибку # 687535, которая недавно была исправлена ​​в natty, и была добавлена ​​как maverick, так и lucid в качестве предлагаемого обновления.

https: //bugs.launchpad. net / ubuntu / lucid / + source / openssh / + bug / 687535

Я бы посоветовал всем пойти туда, попробовать тестовый пример (поиск TEST CASE) и опубликовать результаты как до, так и после установка предлагаемого исправления. Это поможет команде SRU решить, что проверка была выполнена, и опубликовать ее как обновление.

4
ответ дан 26 July 2018 в 23:02

Ubuntu ssh не запускается, и syslog дает «init: ssh main process (2044), завершенный статусом 255»

/ usr / sbin / sshd -Ddp 10222

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

0
ответ дан 26 July 2018 в 23:02

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

root@imt:~# sshd sshd re-exec requires execution with an absolute path ssh localhost ssh: connect to host localhost port 22: Network is unreachable

Путь в порядке в соответствии с документом, поэтому я запускаю вручную sshd.

root@imt:~# /usr/sbin/sshd /var/run/sshd must be owned by root and not group or world-writable

/ var / run / sshd.

root@imt:~# ls -ld /var/run/sshd drwsrwsrwt 2 root root 40 Jan 5 12:58 /var/run/sshd root@imt:~# chmod 755 /var/run/sshd

, тогда его штраф. запустите ssh localhost и проверьте.

root@imt:~# ssh localhost The authenticity of host 'localhost (127.0.0.1)' can't be established. RSA key fingerprint is 64:93:fd:ab:4c:f9:7b:8a:86:60:22:f7:56:fa:ea:cc. Are you sure you want to continue connecting (yes/no)? yes
-1
ответ дан 26 July 2018 в 23:02
  • 1
    Хотя это полезное руководство, это явно не то, что привело к неправильной работе OP sshd, как вы можете видеть из самых разных сообщений об ошибках в своих журналах. -1 – David Foerster 11 January 2016 в 13:30

Другие вопросы по тегам:

Похожие вопросы: