Headless installation (w/o monitor and keyboard, over ssh)

Should one of the official install images provide a headless installation by default?

  • Yes

    Votes: 5 50.0%

  • No

    Votes: 5 50.0%

  • Don't know

    Votes: 0 0.0%

  • I don't care

    Votes: 0 0.0%
  • Total voters
    10
  • This poll will close: .
Mjölnir

Mjölnir

I'm going to make a headless installation on my "new" (used) home server, a semi-professional NAS box for SOHO that I "shot" in an auction on the internet. I'll follow the instructions of 2-3 guides that can be found easily on the net, the only difference beeing that I'll use DHCP instead of a fixed IP number. I.e. I have to change some settings on the install image/medium, that's it, no big deal. There's also mfsBSD, maybe I'll ttry that. It installs FBSD-14.2, then I can upgrade.

IMHO one of the official install images provided by FreeBSD should make a headless install by default. E.g. the mini-memstick.img would be a good candidate. I think there's a need for that, since nowadays not just computer hobbyists have their own small home server. Also many ordinary people have a NAS box for backups or to share data between their plethora of laptops, smartphones and tablets or a multimedia server. It would be great to provide a FreeBSD headless install image for those who are interested, since the word has spread that FreeBSD is a superior choice. I've been asked more than once by people that I'd never expected they would ask such topic.

Do you have any experience with a headless installation? What are the pitfalls?
 
Why DHCP and no fixed IP number?
Because the typical home or office network already has a DHCP server running, and we can't know the network number in advance. DHCP is the most flexible solution, and it will work in 99.999% of all use cases.
 
But how do you want to tell the thing where to install to? I must be missing something.

Do you want to make an install medium that just wipes the disk and installs FreeBSD without questions?
 
No, it should get an IP via DHCP and then start an sshd(8) server, not more. It runs in a ramdisk (md(4)) and does not touch anything (expecially not the disks). Then you can log in via ssh(1) and run bsdinstall(8) (motd(5) will tell this). My hope is that eventually after 1-2 years of testing, the result of this thread will be a "headless community version" of the FBSD install image :) Like I wrote there's already mfsBSD, and IIUC there will be only very few changes on the install medium filesystem to get this done. IMHO it's just plugging together what's already there, in the right way. BUT -- as always -- there are 1000's of pitfalls that can go wrong and I'd like to have it reliable and robust and cover 99% of use-cases.
 
A more powerful version could start a VNC or RDP server or a lighttpd (tiny HTTP server) for graphical login. Then fancy images could be shown with instructions how to backup the previous OS etc. pp. So that ordinary people can install FBSD on their headless home server. Via smartphone, no bigger display needed :) IMHO this must be possible, so let's do it.
 
There is so much that can go sideways before sshd has been started. Maybe an ssh-like console in addition to the traditional and serial consoles. Like an sshd built into loader(8). This comes with the caveat, how to implement this securely.

The console could be a piece of code running outside of the kernel, that the kernel sees as a virtual device. As running outside of the kernel it would use RAM not mapped by the kernel. A good example of this might be Linux's kdump facility.
 
Mjölnir said:
No, it should get an IP via DHCP and then start an sshd(8) server, not more. It runs in a ramdisk (md(4)) and does not touch anything (expecially not the disks). Then you can log in via ssh(1) and run bsdinstall(8) (motd(5) will tell this). My hope is that eventually after 1-2 years of testing, the result of this thread will be a "headless community version" of the FBSD install image :) Like I wrote there's already mfsBSD, and IIUC there will be only very few changes on the install medium filesystem to get this done. IMHO it's just plugging together what's already there, in the right way. BUT -- as always -- there are 1000's of pitfalls that can go wrong and I'd like to have it reliable and robust and cover 99% of use-cases.
Click to expand...

All you need is a finished FreeBSD install on a USB stick that is configured to do dhcp on the right interface for the target machine.
 
cracauer@ said:
All you need is a finished FreeBSD install on a USB stick that is configured to do dhcp on the right interface for the target machine.
Click to expand...
Yes exactly. And what is the "right" network interface? I know it's easy to set up when you know it's just for this one machine, today. But I'd like to create a more universal solution.
Pitfall #1 ifconfig_default="DHCP" in rc.conf does not what I'd like it to do. You need to have ifconfig_xxx0="DHCP" for the network device where the sshd(8)() should run, but we can not know in advance which network interface names (drivers/kernel modules) live on the target machine. This means we need a script to enumerate the devices, and maybe a simple logic to pick the one that is most likely the right one. Im thinking of professional servers which have a management network iface; this is usually a "weak" one, i.e. it can do let's say 100 Mbps while the other ifaces are more capable.

Up to now I followed this recipe, but I think I should try mfsBSD (it's documented in /usr/local/share/doc/freebsd/en/articles/remote-install/), maybe they already have the missing pieces, or most of them. This mfsBSD is a two-step approach, while my 1st quick shot was a one-step solution (and seems to fail). Maybe there could be an enhancement to rc(8)() so that it understands ifconfig_default?
 
cy@ said:
There is so much that can go sideways before sshd has been started. Maybe an ssh-like console in addition to the traditional and serial consoles
Click to expand...
Yes. If the machine has that (most do), it would be silly to disable these. All I want is that when your home/SOHO server box is placed in the broom closet, you're not forced to carry a display and keyboard and plug them in when you want to install FBSD onto that box.

And all that could go wrong before starting sshd is not specific to this use case. All that could equally go wrong in a normal installation procedure. So I don't have to do anything special about it, unless it's caused by the differences I'm about to do in the install procedure.
cy@ said:
.Like an sshd built into loader(8). This comes with the caveat, how to implement this securely.
[...]
The console could be a piece of code running outside of the kernel, that the kernel sees as a virtual device. As running outside of the kernel it would use RAM not mapped by the kernel. A good example of this might be Linux's kdump facility.
Click to expand...
Hm. This looks more like LOM topic which would need to be implemented in the boot loader, and that's not what I want to cover. Instead, I want to create a solution with existing building blocks, for standard consumer-grade hardware. If it works for professional server-grade hw, too, good, but that's not my primary focus.
 
Fun fact: With a read-onlxy filesystem, the dash and underscore on my USB keyboard are disabled. But after mount -uw / I have them... Isn't that funny?!
bakul said:
You always need a console in case something goes wrong as it might. if you have a serial console you can install easily.
Click to expand...
Right. I want to create a solution for the 99/100 days when the network devices can come up and everything goes fine until that happens. And then the start script in the install medium starts sshd() instead of bsdinstall on the console, so you can do a headless install by login in via SSH and write "bsdinstall" -- that's s/th even a noob can do.
 
I've contemplated a script that figures out there is no useful rc.conf or network, set up all interface with dhcp. Checks that ssh has no keys and then creates them and installs a ssh key for root and then starts up sshd in a limited role with a config and logs all in /tmp. In the past I've done parts of that but not all of it. That sort of thing could be useful for others.
 
A live memstick system is no option? I made a FreeBSD system that boots into RAM, adds a wheel user with ssh access from the local network and starts sshd, No problem to log in and dd an OS image to the local disk or run any non-graphical installation program.
It needs CLI autologin configuration on ttyv0 to prepare everything without logging in as admin.
 
No, you need a package with a gui to create a headless lisp install script. Then using the default image , you create the script & run it.
-Questions like , MBR or UEFI , place of UEFI partition
-UFS or ZFS
-etc ...
 
Ok, that was easy. I followed this recipe and with just a few changes in the install image I can log in as root w/o password. It is ifconfig_DEFAULT in uppercase, I forgot that... I guess what I did must be more or less the same like thogard did in his script, e.g. I had to service sshd keygen manually, and this must be patched into the right place (TODO for anyone interested to help) so it runs automagically. I'll apply some minor polishing like e.g. reduce the boot timeout from 10 -> 3 and then post a
patch(1) file here that you may kindly test and give feedback.

Maybe now it's time to think about some basic security? Does a password make sense when it's written all over the net? Can or shall we easily create a OTP, maybe based on the time of day, that is only valid for let's say 5-10 minutes, and an attacker can not know when we're going to use it? Or is that nonsense, because the gangster could easily wait & listen if the network is already compromized?
 
Alain De Vos said:
Sorry , ssh is secure over the internet. Nothing public. Unless Putin or ICE is watching :)
Click to expand...
But when the password is available on the internet, say it is "FreeBSD-15-STABLE" or the like, or no password at all (empty), it's not secure (an attacker can login). I'd say if it's easy to add some basic hardening, we should do it. Else, since FTM my focus is an installer for SOHO use in a closed network that should be clean, I don't want to use a sledgehammer to crack a nut.
 
While I prepare the preliminary patch(1) file version 0.1 (MILESTONE 1: Usable with basic UNIX knowledge AND a UNIX machine to prepare the image (apply the patch)), anyone interested in this topic can
1. dive into the rc(8) scripts of the install image and figure out how to NOT start bsdinstall(8) on the console:
/usr/libexec/bsdinstall/runconsoles /usr/libexec/bsdinstall/startb...
is running. Instead we want that to run on our ssh(1) login, preferably dont start it before we login. And then
2. since we already have the network interface configured via DHCP, how to disable this step in bsdinstall(8)
Thx in advance!
P.S. I forgot: I'm using an install image of FreeBSD-15.0-STABLE (March, 12th IIRC). Usually there are no major differences in bsdinstall(8) to the preceding major version, but this time there are!
 
Another advantage of this other than just as an installer is to have SSH in the installed OS before mounting the 'real' filesystems. This would allow passwords to unlock encrypted filesystems to be provided over SSH (with key login) by a hidden automated system somewhere in your infrastructure that would be unlikely to be stolen. E.g. a Raspberry Pi with WiFi hidden under a floor or over ceiling tiles. If thieves steal the servers they won't get access to the encrypted filesystems until they put them back. I have used Mandos on Linux to do this but it would be great to have this capability on FreeBSD with encrypted ZFS.

 
Mjölnir said:
Should one of the official install images provide a headless installation by default?
Click to expand...
I “voted” no. How often do you need to (re‑)install FreeBSD per (headless) machine? This isn’t VVindoh’s, you know. For once in your life you can hook up the box to a keyboard and display. Go for some fully‑automatic installation if you’re deploying FreeBSD to 100s of computers.​
Mjölnir said:
[…] What are the pitfalls?
Click to expand...
Faulty hardware. Especially if you’re on a budget. I recommend to minimize the number of potential points of failure.​
cracauer@ said:
Do you want to make an install medium that just wipes the disk and installs FreeBSD without questions?
Click to expand...
Well, heck yeah, this is FreeBSD land! Shipped with systemdisease cleansing. Hahaha.​
 
Mjölnir said:
... and
3. Where do we have to patch service sshd keygen into the boot sequence?
Click to expand...
Having this in a FreeBSD 14.2 custom /etc/rc:
Code: 
[ -f /etc/ssh/ssh_host_dsa_key ] || /usr/bin/ssh-keygen -t dsa -f $TARGET_DIR/etc/ssh/ssh_host_dsa_key -N '' > /dev/null
[ -f /etc/ssh/ssh_host_rsa_key ] ||  /usr/bin/ssh-keygen -t rsa -f $TARGET_DIR/etc/ssh/ssh_host_rsa_key -N '' > /dev/null
[ -f /etc/ssh/ssh_host_ecdsa_key ] ||  /usr/bin/ssh-keygen -t ecdsa -f $TARGET_DIR/etc/ssh/ssh_host_ecdsa_key -N '' > /dev/null
[ -f /etc/ssh/ssh_host_ed25519_key ] ||  /usr/bin/ssh-keygen -t ed25519 -f $TARGET_DIR/etc/ssh/ssh_host_ed25519_key -N '' > /dev/null
But it doesn't work with the default rc.d system. Just execute these commands somewhere before sshd.
 
Mjölnir said:
Yes exactly. And what is the "right" network interface? I know it's easy to set up when you know it's just for this one machine, today. But I'd like to create a more universal solution.
Pitfall #1 ifconfig_default="DHCP" in rc.conf does not what I'd like it to do. You need to have ifconfig_xxx0="DHCP" for the network device where the sshd(8)() should run, but we can not know in advance which network interface names (drivers/kernel modules) live on the target machine. This means we need a script to enumerate the devices, and maybe a simple logic to pick the one that is most likely the right one. Im thinking of professional servers which have a management network iface; this is usually a "weak" one, i.e. it can do let's say 100 Mbps while the other ifaces are more capable.
Click to expand...

Apart from DEFAULT, nothing prevents you to spam as many ifconfig_xxx0 entries as you like in the same /etc/rc.conf, in preparation for different interfaces the target machine might have.
 
You must log in or register to reply here.
Back
Top