Problem:
- sshd does not appear to start on system boot, but runs fine when started from a terminal with
/etc/init.d/ssh start
Update Dec 2010: Thanks to Jeremie here. Change the following in /etc/init.d./ssh
to stop sshd starting before the network is ready:
Change:
# Required-Start: $remote_fs $syslog
to:
# Required-Start: $remote_fs $syslog $network
Merci Jeremie!
Cause and Solution:
- A
ListenServer
directive in/etc/ssh/sshd_config
is making sshd attempt to listen on a not-yet extant address. Change the directive toListenServer 0.0.0.0
(NB: if you don’t have an /etc/init.d/ssh
, you can get one from here)
I had a problem with a machine I am using as a samba fileserver. It would seem that the sshd process was not running at startup, so I would have to log into Gnome and run /etc/init.d/ssh start
manually, which was a pain in the arse.
A quick search turned nothing up, except “make sure openssh-server is installed”, which in my case it was. I was about to post to the Ubuntu forums, but first I had a quick look at the syslog (which sshd prints to), where I saw entries like the following:
Jun 27 13:18:56 hermes init: ssh main process (802) terminated with status 255
Jun 27 13:18:56 hermes init: ssh main process ended, respawning
Jun 27 13:18:56 hermes init: ssh main process (806) terminated with status 255
Jun 27 13:18:56 hermes init: ssh main process ended, respawning
Jun 27 13:18:56 hermes init: ssh main process (810) terminated with status 255
Jun 27 13:18:56 hermes init: ssh main process ended, respawning
Jun 27 13:18:56 hermes init: ssh main process (814) terminated with status 255
Jun 27 13:18:56 hermes init: ssh main process ended, respawning
Jun 27 13:18:56 hermes init: ssh main process (818) terminated with status 255
Jun 27 13:18:56 hermes init: ssh main process ended, respawning
Jun 27 13:18:56 hermes init: ssh main process (822) terminated with status 255
Jun 27 13:18:56 hermes init: ssh main process ended, respawning
Jun 27 13:18:56 hermes init: ssh main process (826) terminated with status 255
Jun 27 13:18:56 hermes init: ssh respawning too fast, stopped
My thinking is that sshd was trying to start up before the network interfaces were configured, which was causing it to fail as it had a ListenAddress
directive in /etc/ssh/sshd_config
.
Commenting out the specific ListenAddress
directive and adding ListenAddress 0.0.0.0
to let sshd listen on any address solved the problem. The fileserver has only 1 IP address anyway.
Thank you so much Robert, this post saved me!
Thanks. It helped start my sshd on Novell Linux 11
Many thanks, i’ve looking for a solution over an hour and this helped me in 30 sec!
Thanks, this tip was usefull to solve my problem.
Thanks, this tip was useful to solve my problem.
Glad it’s been helping everyone, it was a royal pain for me!
Thank you Robert!
Regards,
Dmitry
While this works great for most cases, it was not the right answer for me: I needed to Listen on a specific interface for ssh connections and not on others. The above forces the problem by running sshd from init.d scripts, which are there for compatibility since upstart (karmic? jaunty? not sure).
The upstart job for ssh (/etc/init/ssh.conf) – at least in lucid – is completely independent of init.d scripts. It is set up to start on ‘filesystem’, which did not work and caused restarts, as above, until upstart got tired of respaning and gave up (based on limits specified in the ssh job). So I changed the ‘start on’ to ‘(filesystem and net-device-up IFACE=eth0)’, which caused ssh to be started after my interface was up. The ‘net-device-up’ event is sent from /etc/network/if-up.d/upstart script, of course.
Presto! no more driving across town after a reboot 🙂
Also, note that there is an openssh-server script in /etc/network/if-up.d, which restarts sshd when new interfaces come up, but this is all kinds of flaky, since the timing of mutiple restarts is unpredictable. Something like ‘watershed’ is needed…
Hi,
I recently also experienced this issue on my Ubuntu 10.04 LTS Server (64-Bit).
The above mentioned did not help, though. But I found a different solution. Maybe it will help the one or other:
I noticed that openssh-server has been updated with my last aptitude upgrade:
openssh-server 1:5.3p1-3ubuntu4 -> 1:5.3p1-3ubuntu5
Since the update the sshd process didn’t start anymore.
I could fix it by editing /etc/init/ssh.conf:
Since the update, the last line in the script was:
exec /usr/sbin/sshd -D
Before it was:
exec /usr/sbin/sshd
(notice, without the -D argument)
I simply removed the -D argument and restarted sshd (well, I actually had to reboot the machine, because I didn’t have any other access to it, besides the Parallels Administration Tool provided by my hoster…)
I’m just wondering why that -D argument got into my config file?!
I’m running an up-to-date Ubuntu 10.10 with a static IP address – the posted solution at the top of this page did not start ssh for me, but the solution by Sergey on 09 Feb 2011 did (ssh.conf~ and “<" are the old file):
$/etc/init: diff ssh.conf~ ssh.conf
7c7
start on filesystem and net-device-up IFACE=eth0
That diff output didn’t post properly, so here it is again, the change to /etc/init/ssh.conf:
OLD:
start on filesystem
NEW:
start on filesystem and net-device-up IFACE=eth0
Pingback: DIY NAS Installing Ubuntu and OpenSSH (Remote Access) | Swift World
that’s it! Thank you so much!
—> # Required-Start: $remote_fs $syslog $network
Pingback: Ubuntu HowTo: SSH Daemon doesn't start normally way - TECHPRPR
Pingback: SSH Daemon doesn't start normally way - Boot Panic