Liane Praza's Weblog

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.