Letting start sshd in an early stage on ARM devices

[Dr. Rolf Jansen]

Last week I had the first official presentation of my ADC/DAC-project with a BeagleBone Black running FreeBSD 12.0-ALPHA5.

I experienced a problem with the NFS client, which was sort of home made problem, because in the hurry I forgot to deactivate the mount-directive of a nfs share in fstab, and when I started the BBB before the presentation, it was not connected to it's home-network and it hang at that point. I built it into a very tight box and there was no place anymore for the FTDI serial connector, and since sshd is usually loaded as one of the last services, I was effectively locked out of the BBB. Fortunately, I overcame the problem by simulating the nfs share with my notebook and after restart, I was able to fix the fstab right before the actual presentation began, so nobody saw that I had a problem - anyway, I would prefer to never become that nervous again. 

My question is now, why is sshd set to start so very late in the booting process? If we want to put autonomous ARM devices somewhere into the field, then any hick-up in the startup sequence would leave us out-locked.

For testing purposes, I changed the sshd rc script by replacing the line starting with # REQUIRE: ... by:

   # REQUIRE: ipfw
   # BEFORE: mountcritremote

Now, sshd starts right after ipfw has been set up, and in case the BBB hangs, e.g. in the course of mounting a nfs share, I am still able to login via ssh and fix most of the issues.

I would like to leave it like this (at least on the headless ARM devices). Are there any risks or hidden problems which I might experience, when having sshd running very early in the boot sequence? Of course after any FreeBSD update, I would need to check the sshd rc script.

Best regards

Rolf