As you mentioned there are several options for accessing ChromeOS devices depending on what your goal is. The easiest is to enable SSH in Crostini and set up a port forward using the new options in the latest ChromeOS releases. The second easiest is Crouton which requires Developer mode, but can still maintain a lot of the system security features. The last, hardest, and least "secure" is to configure the "host" ChromeOS run an SSH server, but this requires removing a lot of the security protections that make Chromebooks a really solid development platform.
There are probably a lot of posts covering SSH into Crostini or Crouton, so I'll just go over the "hard" option and will try to come back and update with a few links to the others as I come across consistently working and best practice posts for those.
HARD MODE aka YOLO:
If you want to SSH into the actual host operating system you need to enable the SSH service by switching into Developer Mode (wipes all data during the conversion). You can choose the option to enable "Debugging options" during the post reset set up, but I've found that this actually causes some issues later, so I'd recommend to just connect to the internet and log in like you normally would.
NOTE: Switching to Developer Mode sets a firmware flag and even doing
a Powerwash or Recovery from USB doesn't change the system from
Developer Mode back to the normal mode. You have to press Space at the
Developer mode warning or run a specific command from the Crosh shell
after logging in to change the Developer Mode setting, and doing so
triggers a wipe of all data for security purposes.
If you want to SSH into your ChromeOS host operating system you need to disable the rootfs read-only protection, note that this reduces the security of your system significantly, and making an incorrect change or deleting the wrong file (or a broken script or malware abusing your access) could cause ChromeOS to stop booting, forcing you to use a USB Recovery or perform a Powerwash which deletes all your user data.
After disabling the rootfs protection you can enable the SSH service by following the directions from the ChromeOS source.
There are 3 options, with the first being the Debugging that I recommend skipping, the second being the best IMO because you can disable password SSH and remove the "test keys" that aren't secure since they are publicly known, and the third requires running the sshd manually after each reboot, which probably isn't what you want if you need remote/unattended access to your Chromebook/Chromebox. Though for the 3rd option you may be able to avoid using the "test keys" as long as you can set the file permissions correctly for the authorized_keys
file and store it under /usr/local/
which ChromeOS doesn't touch during updates.
https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/master/chromeos-base/chromeos-sshd-init/files/openssh-server.conf.README#25
Copyright 2015 The Chromium OS Authors. All rights reserved.
Use of this source code is governed by a BSD-style license that can be
found in the LICENSE file.
------------------------------
Instructions for enabling sshd
------------------------------
Normally base images will not automatically start sshd on boot. If sshd is
needed, below are a few recommended ways to start it, from simplest to most
complicated.
1. OOBE debugging features.
This is the easiest way to enable sshd, but if OOBE has already been bypassed
the machine will have to be powerwashed first to get back to OOBE.
Enabling the OOBE debugging features will cause sshd to start automatically
on each boot, and both password and test key access will be enabled.
For more information on OOBE debugging features, see
dev.chromium.org/chromium-os/how-tos-and-troubleshooting/debugging-features.
2. Run a helper program.
An executable named dev_features_ssh is available to enable sshd. Rootfs
verification must be removed first or the helper program will have no effect.
This will cause sshd to start automatically on each boot with test key
access. Password access can optionally be enabled after rootfs verification
has been removed.
# Remove rootfs verification.
$ /usr/share/vboot/bin/make_dev_ssd.sh --remove_rootfs_verification
$ reboot
# Install sshd startup files.
$ /usr/libexec/debugd/helpers/dev_features_ssh
# Allow password access (optional).
$ passwd
3. Manually start sshd.
This is the least convenient option, but doesn't require OOBE or rootfs
verification removal, so can be used without changing the system too much.
Unlike the above methods, this will not auto-start sshd on boot.
Additionally, password access is not possible without rootfs verification
removal, so test keys must be used to SSH into the device.
# Create host keys (only needs to be done once).
$ mkdir -p /mnt/stateful_partition/etc/ssh
$ ssh-keygen -f /mnt/stateful_partition/etc/ssh/ssh_host_rsa_key -N '' -t rsa
$ ssh-keygen -f /mnt/stateful_partition/etc/ssh/ssh_host_ed25519_key -N '' -t ed25519
# Open firewall and start sshd (must be done on every boot).
$ iptables -A INPUT -p tcp --dport 22 -j ACCEPT
$ /usr/sbin/sshd \
-oAuthorizedKeysFile=/usr/share/chromeos-ssh-config/keys/authorized_keys