RFC: fix #6686: Debian: enable ssh.service and make it work reliably on armbian-firstrun

[alexl83]

Description

ssh.service activation fails on first boot due to a race condition with armbian-firstrun (missing host keys at ssh.service startup)

By changing armbian-firstrun.service to run After=ssh.service SBC is always reachable reliably via ssh, even on first run, so that it can be configured headlessly by remote login

It also reverts commit IDs: #911c756083164c32051d533ca3f2de488f202130 and #30c47f6f6cebd75f5c28866918fea093b8c82b44 disabling ssh.socket - this fixes SSH Deamon behavious to honour ListenAddress directive when set via sshd_config

Jira reference number [AR-2356]

How Has This Been Tested?

• Compiled and first-run vanilla armbian Bookworm-Edge
• Compiled and first-run vanilla Armbian Trixie-Edge
• Simulated additional first-run(s) via systemd enable armbian-firstrun.service and touch /root/.not_logged_in_yet(Bookworm-Edge && Trixie-Edge)

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• My changes generate no new warnings

[igorpecovnik]

lgtm

[EvilOlaf]

Is this still being worked on?
I noticed ssh fail to start at boot with a vendor Bookworm CLI image built from yesterday on a Radxa Zero 3E.
I'll try to extract more debug info once I found an USB-C to A adapter so I can connect a keyboard to.

[alexl83]

Is this still being worked on? I noticed ssh fail to start at boot with a vendor Bookworm CLI image built from yesterday on a Radxa Zero 3E. I'll try to extract more debug info once I found an USB-C to A adapter so I can connect a keyboard to.

Is this still being worked on? I noticed ssh fail to start at boot with a vendor Bookworm CLI image built from yesterday on a Radxa Zero 3E. I'll try to extract more debug info once I found an USB-C to A adapter so I can connect a keyboard to.

Hi @EvilOlaf I tested a couple weeks ago a vanilla Bookworm image and couldn't reproduce; let me test again and get back to you :)

[alexl83]

I'm running a bookworm-vendor image built from trunk a couole hrs ago - orangepi5-plus
ssh starting at each boot, cable connected to eth0 - now going through armbian-firstrun and cannot see any network issue

Tomorrow I'll try the same config on my nanopi-r5c - will report any issue

Should you be able to pull some log data, it could be helpful in pinpointing root cause

[ColorfulRhino]

This PR: #3774 wants to run armbian-firstrun before ssh.service 🤔 (including some other ssh changes)

Which is better? 😄

[alexl83]

This PR: #3774 wants to run armbian-firstrun before ssh.service 🤔 (including some other ssh changes)

Which is better? 😄

Can't say, but if it's more complete/compatible we should consider it
It seems to take for granted some network stuff like systemd-resolved, perhaps it might need some tweaking to adapt it to new logic (systemd-network for minimal cli - networkmanager for the rest)
I only have a nanopi and a a bunch of orangepis, so my fix could not be as universal as I think(/want)

[ColorfulRhino]

It seems to take for granted some network stuff like systemd-resolved, perhaps it might need some tweaking to adapt it to new logic (systemd-network for minimal cli - networkmanager for the rest)

No no, disregard everything that is not ssh related 😄 The other stuff in this PR is unrelated.

I have just discovered that linked PR and am trying to see if some of the stuff is beneficial.

[alexl83]

Can't say to be honest: what I understood experimentally is that a few weeks ago ssh on boot (Trixie) was failing 30%-60% of the times - when armbian-firstrun was started before it - no issue on bookworm

When this issue appeared, trixie ssh init file changed in order to pull nss-user-lookup.target in After statement. literally only difference I could find.
I tested both firstrun specifically set as Before ssh and achieved consistent 100% start failure of ssh, then any issue disappeared (in my case) when ordered firstrun service start After ssh.service

Reproduced same results on bookworm - trixie - and called it a day - pushing this PR - current vs edge kernels made no difference (ubuntu manages sshd with a socket strategy - different than debian)

At the time I only tested on orangepi5-plus, orangepizero3 and orangepizero2w

[ColorfulRhino]

I haven't run into any issues so far, but I'll test 👍

[alexl83]

I haven't run into any issues so far, but I'll test 👍

Great, thanks - perhaps the key might be related to some specific boards tweaks

[EvilOlaf]

Alright. Finally got there.

tl;dr: never mind
Everything works as expected. Was an issue on my part. Apologies for confusion.

[alexl83]

Alright. Finally got there.

tl;dr: never mind Everything works as expected. Was an issue on my part. Apologies for confusion.

No biggie Werner, it's been better to double check