[Solved] sshd Does Not Run At System Startup (Ubuntu)


  • 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:


# Required-Start:       $remote_fs $syslog 


# 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 to ListenServer

(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 to let sshd listen on any address solved the problem. The fileserver has only 1 IP address anyway.

Connect to a WPA/WPA2 Secured Network In Linux

This turned out to be dead easy, although it took a bit of futzing around due to my own slowness. The situation arose during an a failed upgrade of my dad’s machine to Ubuntu 10.04 (aka Lucid Lynx). I’m sensing a pattern here; I don’t think there has been an upgrade that has gone smoothly on that machine. To be fair I think there may be problems with just about every component apart from the hard drive, but you think I would realise that upgrading that machine is a Bad Idea. Anyway, the solution:

A combination of wpa_supplicant and wpa_passphrase will do the trick.

  1. Get a root prompt. Either sudo su, or boot to single user (recovery) mode. Just don’t do that, select netroot, then get bored and hit Alt-F1 for a console 1. For some reason, that makes the machine very unhappy and so your wireless hardware probably will complain about device busy in step 2. So don’t do that.
  2. Run iwlist scanning, and check your card can see the wireless network in question
  3. If it can, run wpa_passphrase [your-wireless-network-name] > wpa.conf
    (eg wpa_passphrase pegasus > wpa.conf). The prompt will wait for you to enter a passphrase. Do this and hit enter.
  4. Run wpa_supplicant. Replace wext with the correct wireless driver (which is probably wext, but run wpa_supplicant --help to check) and wlan0 with your wireless interface
  5. wpa_supplicant -Dwext -iwlan0 -c/root/wpa.conf
  6. If that works, you should see text to the effect of “successfully associated”. If not, try again with a different driver, make sure your passphrase is correct, and make sure your wireless interface is working properly.
  7. Hit Ctrl+c, then the up arrow, then add a -B (for background) onto the end of the last command, thus: wpa_supplicant -Dwext -iwlan0 -c/root/wpa.conf -B
  8. Run dhclient -r to release any DHCP leases you have.
  9. Run dhclient wlan0 to get a new IP address. Substitute wlan0 for your wireless interface, of course.

You should now be connected. This is a handy trick for any Linux user unaccustomed to connecting to wireless networks from the command line – let’s face it, network-manager has spoiled us rotten. But when an upgrade fails and won’t leave you with a functioning graphics driver (grr) and you need some packages, this is the way to do it.

Ubuntu 9.10 Karmic Upgrade Problem Fixed (mountall/init)

(Jump to the bonus section on sorting a removed Gnome panel)

I finally got round to doing the Jaunty->Karmic upgrade on a troublesome machine. Well, re-doing. I made an abortive attempt to install it on this particular exhibit of electronic arthritis back before I left for Barcelona, which ended in me reinstalling 9.04.

Anyway, for one reason or another the upgrade failed or was interrupted and so I was left with a machine that would not boot. Well, it would do a good chunk of the boot process, but fail at an init item (init_bottom, I think). mountall was exiting with code 127, complaining:

process mountall (787) exited with code 127:
undefined symbol: udev_monitor_filter_add_match_subsystem_devtype

Quite a mouthful, in other words. Even booting into “recovery mode” didn’t give me a working console. Next step: try a liveCD. The same problem was reported by niroht of the ubutuforums here. However, his explanation is a bit brief, and misses out a couple gotchas.

So, you’ve got a problem with mountall, and you’ve also got a 9.10 liveCD. Here’s how to sort it:

  1. Boot from the livecd
  2. Call up a terminal (gnome-terminal or xterm).
  3. Chroot your usual install partition. GParted, under “Administration” can help you determine what this is. Mine was /dev/sda3. What I did was:
    • sudo su
    • mkdir /newroot
    • mount /newroot /dev/sda3
    • chroot /newroot <- chrooting my install parition
    • mount /proc <- important! not mounting /proc causes all sorts of problems.

    Now you’re chrooted and ready to continue. I have a separate /boot partition as well, but I updated this later to save faffing at this stage.

  4. Sort the botched upgrade! I ran first dpkg --configure -a, then to be sure, apt-get -f install. Finally, I ran apt-get dist-upgrade, which upgraded a *lot* of packages (~700 I think).

Now, if your /boot prtition resides on the same partition, you’re done here. If not, you have to mount it and copy the new kernel images and updated menu.lst. Strictly speaking, this should be possible to set up when doing the chroot above, but I couldn’t remember how to do it at the time. Make sure if you are merging the menu.lst that the contents are correct – check the UUIDs or partition references are correct!

Bonus! Restore the default gnome-panel if you accidentally delete

So once I was done with the fixed upgrade I booted, and got a slightly messed up top Gnome panel. Two volume icons, and no network icon. In my attempt to sort it, I clicked cack-handedly and removed the entire panel. Rather than repopulate it manually, I followed the advice of another ubuntuforums thread:

gconftool-2 --shutdown
rm -rf ~/.gconf/apps/panel
pkill gnome-panel

And that was the panel restored to default!

* (Previously listed as “undev_mknitor_filter_add_match_sebsystem_devtype”, as it appeared on the screen. Part of the electronic arthritis is (I think) in the graphics card, which causes all sorts of odd things to happen to the pre-boot text. Must photo it sometime.)

Broadcom 4318 Working Under Ubuntu Hardy Heron 8.04 (Ndiswrapper)

In my dad’s PC is a wireless card – a Linksys WRT54GS I think. Anyway it uses the Broadcom BCM 4318 chipset, as seen by a quick lspci:

richard@hades:~$ lspci | grep roadc
00:0a.0 Network controller: Broadcom Corporation BCM4318 [AirForce One 54g]
802.11g Wireless LAN Controller (rev 02)

Unfortunately the new b43 / b43-fwcutter package (installed from / by ‘restricted drivers’) stopped this working. I’m not sure why exactly; it’s possibly because it was designed for a later chipset (I’ve heard 04 for one of the chipsets), but in any case this is moot. It doesn’t work at the moment. This affects PCI cards, some internal laptop wireless cards, and some removable wireless cards.

Now, the card worked under Gutsy using ndiswrapper. So, that’s what I tried to get this working. There is a post at the Ubuntu forums that details how to do this. I’m going to briefly reproduce the procedure here because quite a lot of people are interested in getting their card woking, but thanks to Mazza558 for the info.

1) Remove the b43-fwcutter package
sudo aptitude remove b43-fwcutter

2) Reinstall ndiswrapper

sudo apt-get install ndisgtk

b) Download and install wireless driver
WMP54GS Driver
wget http://roberthallam.com/wmp54gs.tgz
tar -xzf wmp54gs.tgz
ndiswrapper -i wirelessdriver/WMP54GS.inf

3) Create bash script to fix wireless
sudo gedit /etc/init.d/wirelessfix.sh
Into the file, put:

modprobe -r b44
modprobe -r b43
modprobe -r b43legacy
modprobe -r ssb
modprobe -r ndiswrapper
modprobe ndiswrapper
modprobe b44

Save it, then change the permissions to 755:
cd /etc/init.d/ && sudo chmod 755 wirelessfix.sh

And finally execute:
sudo update-rc.d wirelessfix.sh defaults

And then you can reboot and have working wireless, or just (as root) execute the commands you put into the wirelessfix.sh file.

NB: To get a root bash prompt in Ubuntu, execute:

sudo bash

Enjoy your wireless, on whatever card card you have!

Update: Ed points out quite rightly that can be somewhat hard to update using an internet connection if you don’t have a working wireless card. A situation not unlike what good is a phone call… if you’re unable to speak? In any case, you have a number of options, some of which may or may not be possible:

  1. Plug a cable into your ethernet port
  2. Use an old Ubuntu 7.10 Gutsy Gibbon CD to update from. This should Just Work, that is you put it in the CD drive and you will be asked if you want to use it as a repository source (or similar). If not, the
    command is your friend
  3. Download the .deb files manually elsewhere. Get both ndiswrapper-common and ndiswrapper-utils-1.9 (links to mirrors, not direct). Note that ndiswrapper-utils-1.9 has a couple dependencies like perl which you should have, but may not. Save them to a USB flash drive or whatever. Then use dpkg to install the deb files. Or:
    [insert USB drive and cd to it]

    [move USB drive to target machine, open a terminal and cd to the drive]
    dpkg -i ndiswrapper-common_1.50-1ubuntu1_all.deb
    dpkg -i ndiswrapper-utils-1.9_1.50-1ubuntu1_i386.deb

And you should be good to go, even if you are without an internet connection!

Back to Ubuntu

So I’m suppose to be revising for the Big Testâ„¢ that I’ve got tomorrow, but instead I decided to reboot in Ubuntu. And by gosh, I’d forgotten how nice it looks. And this is still the 7.04 version! Sounds are nice too – it’s probably just subjective perception, but playing music sounds nicer too, although I’d still like to get my hands on an equaliser and turn the bass down a bit. Yes, I could see myself using this for a while, especially as there aren’t as many game distractions on here…

Why did I ever leave?