starting ssh early in boot

It's nice that as of Solaris 9, ssh is included in Solaris. We've always started it late, though. That's a conscious decision made by the ssh team to include dependencies which mean that it won't start until all local and network services any user might need, including remote filesystems, are available.

This is great for interactive environments with many home directories stored on the network. Your users don't end up with spurious and surprising home directory not available messages if you try to log in too early during the boot process. But, if you've got a server stranded in a co-lo many miles away, this might not be what you want. You may want ssh to start up as soon as the root filesystem and basic networking are available, and be available if you boot to single-user mode. Here's how for Solaris 10 and similar releases (no guarantee of fitness for more recent bits):

  • Remove the ssh dependencies on services you don't need. The full dependency list for ssh is:

       $ svcs -d ssh
       STATE          STIME    FMRI
       online         Dec_19   svc:/network/loopback:default
       online         Dec_19   svc:/network/loopback:default
       online         Dec_19   svc:/network/physical:default
       online         Dec_19   svc:/system/filesystem/usr:default
       online         Dec_19   svc:/system/cryptosvc:default
       online         Dec_19   svc:/system/filesystem/local:default
       online         Dec_19   svc:/system/utmp:default
       online         Dec_19   svc:/system/filesystem/autofs:default

    Since I said I wanted just the network and the root filesystem to be available (oh, yeah, and the crypto services we need to do proper encryption), I'll delete everything else. That means I first look at the dependency property group names:

       # svccfg -s ssh listpg
       config_data     dependency
       cryptosvc       dependency
       net             dependency
       fs-local        dependency
       fs-autofs       dependency
       net-loopback    dependency
       net-physical    dependency
       utmp            dependency

    Dependencies are helpfully named here and have type dependency, so I'm not looking much futher to see the ones to delete. Deleting the dependency on utmpd is a little risky, but I'm willing to live with the risk to commands like last(1). So, I go ahead and delete the property groups which configure those dependencies.

       # svccfg -s ssh delpg fs-local
       # svccfg -s ssh delpg fs-autofs
       # svccfg -s ssh delpg utmp
       # svcadm refresh ssh
       # svcs -d ssh
       STATE          STIME    FMRI
       online         Dec_19   svc:/network/loopback:default
       online         Dec_19   svc:/network/loopback:default
       online         Dec_19   svc:/network/physical:default
       online         Dec_19   svc:/system/cryptosvc:default
       online         Dec_19   svc:/system/filesystem/local:default

None of this is endorsement to go around deleting dependencies willy-nilly on your system. All of them are there for a reason, and deleting them without understanding their purpose is guaranteed to lead to pain. If you have any problems with a service where you've deleted dependencies, the first step is to put them back! There are no places in which we've added dependencies to services for fun. Some of the dependencies you might see that seem superfluous are the ones that we added only after finding some very subtle breakage without them.



Posted by gerrge on September 12, 2006 at 01:46 PM PDT #

Who cares unless it would run on a Mac Book Pro ?

Posted by Wayne on September 26, 2006 at 10:52 PM PDT #

Thanks for the tips... and your example is right on the money, for me. I frequently don't need/want autofs, so I have always disabled it on new installs, except if I know I need it. Having sshd depend on autofs seems a bit myopic on the developers' part ... seems the developers assume everyone runs their systems the way Sun does. Automounts, etc. Personally, I'd want sshd to be running even if I'm using automounts and autofs is not running. Better to get in and not have my HOME directory, than to not have any way in to the system than the console. Now I have to fix this & recreate my flash archive. -- David Strom

Posted by David Strom on October 04, 2006 at 12:59 AM PDT #

How would this affect first boot after a flar install? I've got a system built from a .flar created from a system with the above mentioned changes (removing dependencies). It appears that it attempts to start ssh before the host keys are generated. The ssh svc log shows:

[ Aug 14 17:09:03 Executing start method ("/lib/svc/method/sshd start") ]
Could not load host key: /etc/ssh/ssh_host_rsa_key
Could not load host key: /etc/ssh/ssh_host_dsa_key
Disabling protocol version 2. Could not load hostkey or GSS-API mechanisms
sshd: no hostkeys available -- exiting.
[ Aug 14 17:09:03 Method "start" exited with status 1 ]

I'm not sure what service runs the key generation process. I haven't had a chance to delve into it yet. Any hints?

Posted by Jay Morgan on August 14, 2007 at 07:30 AM PDT #

SunOS rebel 5.10 Generic_118833-33 sun4u sparc SUNW,Ultra-60

The ssh example worked for me, but I have another problem and I think that smf has made things easier for people who know a lot more than I do, but is burying things that I might have fixed. I created a zfs pool problem "A", and for performance reasons (which may have related to problem "B"), I ripped it out. Afterward I still had performance problems and was getting messages "Jun 21 09:11:54 rebel ramdisk: [ID 374231 kern.notice] root: existing property missing." and # ramdiskadm shows no instances of a ramdisk. When things like that were started in the rc directories, I had some idea of what I was looking at, but the man pages don't show where is called from and now I am faced with installing the OS all over to fix something that should be fixable with less effort. Perhaps this is too simple if you know what you are doing but I have been through both the ramdisk, and the ramdiskadm pages and not found anything that helps, and neither does svcs -xv (no listing with the word ram in it). It is not that I can't fix it, a reinstall will do that, it is that after working on it for several days I am no better off than I was when I started.

Posted by Harrison Picot on June 23, 2009 at 01:27 PM PDT #

"If you have any problems with a service where you've deleted dependencies, the first step is to put them back!"

What's the most convenient way to go back to the previous configuration state? svccfg export to backup the original configuration before playing with it and svccfg import to restore it afterwards?

Posted by Sebastian Kayser on February 10, 2010 at 01:20 AM PST #

This is just awesome! One of our servers would only bring ssh up after 7 minutes (from when it started pinging) and now it's up after 5 seconds. That way I don't need to start pulling my hair off. Thanks!

Posted by Giovanni on March 12, 2010 at 04:31 AM PST #

Post a Comment:
  • HTML Syntax: NOT allowed

Liane Praza


« April 2014