Join Log in
Score:0
avatar Ubuntu

issue sshd_config / systemctl restart

my flag
Fred L.

one of my workstation (previously it was a 22.04.1 server edition but according to NUC compatibility list last BIOS and dbx EUFI Database uggrade force me to downgrade to workstation as Server edition is looping on kernel panic (NUC 10i7FNH BIOS: 59 UEFI dbx: 267. detail here:

sudo fwupdmgr get-devices

NUC10i7FNH
│
├─SSD 970 EVO Plus 2TB:
│     Summary:            NVM Express solid state drive
│     Current version:    2B2QEXM7
│     Vendor:             Samsung (NVME:0x144D)
├─System Firmware:
│ │   Summary:            UEFI ESRT device
│ │   Current version:    59
│ │   Minimum Version:    59
│ │   Vendor:             Intel(R) Client Systems (DMI:Intel Corp.)
│ │   Update State:       Success
│ └─UEFI dbx:
│       Summary:          UEFI revocation database
│       Current version:  267
│       Minimum Version:  267
│       Vendor:           UEFI:Linux Foundation
│       Install Duration: 1 second
└─Thunderbolt host controller:
      Summary:            Unmatched performance for high-speed I/O
      Current version:    42.00
      Vendor:             Intel Corporation (THUNDERBOLT:0x8086, TBT:0x8086)

This "multi homed headless workstation" is configured with bonds and vlans via netplan, and it is supposed to run sshd listening on some (not all) of its interfaces.

192.16.0.150/24 (for admin only from admin vlan) port 22
10.0.1.150/24 (key users from lab 1 vlan) port 22
10.0.2.150/24 (key users from lab 2 vlan) port 22
10.0.3.150/24 (key users from lab 3 vlan) port 22
10.0.4.150/24 (key users from lab 4 vlan) port 22
other vlans (storage, backup, data/application, etc.) are supposed to be without users that need to get  a ssh connection.

After sshd installation and without customisation of sshd_config everything is ok all interfaces get their sshd listener even those that are supposed to deliver storage/backup or application flow...

I've run several tests (with or without port setting).

Test with port setting:

ListenAddress 192.168.0.200:22
ListenAddress 10.0.1.200:22
ListenAddress 10.0.2.200:22
ListenAddress 10.0.3.200:22
ListenAddress 10.0.4.200:22

Test without port setting:

ListenAddress 192.168.0.200
ListenAddress 10.0.1.200
ListenAddress 10.0.2.200
ListenAddress 10.0.3.200
ListenAddress 10.0.4.200

All of the tests I've run with explicit ListenerAddress specified got the same issue. systemctl notice a degraded service: sshd when system is started (after boot or reboot) with a failed status, but a systemctl restart ssh.service fix the issue til next reboot.

sudo systemctl status | head -n 5

● hell
    State: degraded
     Jobs: 0 queued
   Failed: 1 units
    Since: Thu 2022-12-08 19:40:14 CET; 9min ago

sudo systemctl status ssh.service

× ssh.service - OpenBSD Secure Shell server
     Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: enabled)
     Active: failed (Result: exit-code) since Thu 2022-12-08 19:40:15 CET; 9min ago
       Docs: man:sshd(8)
             man:sshd_config(5)
    Process: 853 ExecStartPre=/usr/sbin/sshd -t (code=exited, status=0/SUCCESS)
    Process: 866 ExecStart=/usr/sbin/sshd -D $SSHD_OPTS (code=exited, status=255/EXCEPTION)
   Main PID: 866 (code=exited, status=255/EXCEPTION)
        CPU: 15ms

déc. 08 19:40:15 hell sshd[866]: error: Bind to port 22 on 10.0.4.150 failed: Cannot assign requested address.
déc. 08 19:40:15 hell sshd[866]: error: Bind to port 22 on 10.0.3.150 failed: Cannot assign requested address.
déc. 08 19:40:15 hell sshd[866]: error: Bind to port 22 on 10.0.2.150 failed: Cannot assign requested address.
déc. 08 19:40:15 hell sshd[866]: error: Bind to port 22 on 10.0.1.150 failed: Cannot assign requested address.
déc. 08 19:40:15 hell sshd[866]: error: Bind to port 22 on 192.168.0.150 failed: Cannot assign requested address.
déc. 08 19:40:15 hell sshd[866]: fatal: Cannot bind any address.
déc. 08 19:40:15 hell systemd[1]: ssh.service: Main process exited, code=exited, status=255/EXCEPTION
déc. 08 19:40:15 hell systemd[1]: ssh.service: Failed with result 'exit-code'.
déc. 08 19:40:15 hell systemd[1]: Failed to start OpenBSD Secure Shell server.
déc. 08 19:46:17 hell systemd[1]: ssh.service: Unit cannot be reloaded because it is inactive.

sudo systemctl restart ssh.service

sudo systemctl status ssh.service

● ssh.service - OpenBSD Secure Shell server
     Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: enabled)
     Active: active (running) since Thu 2022-12-08 19:49:59 CET; 15s ago
       Docs: man:sshd(8)
             man:sshd_config(5)
    Process: 4248 ExecStartPre=/usr/sbin/sshd -t (code=exited, status=0/SUCCESS)
   Main PID: 4249 (sshd)
      Tasks: 1 (limit: 76717)
     Memory: 1.7M
        CPU: 12ms
     CGroup: /system.slice/ssh.service
             └─4249 "sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups"

déc. 08 19:49:59 hell systemd[1]: Starting OpenBSD Secure Shell server...
déc. 08 19:49:59 hell sshd[4249]: Server listening on 10.0.4.150 port 22.
déc. 08 19:49:59 hell sshd[4249]: Server listening on 10.0.3.150 port 22.
déc. 08 19:49:59 hell systemd[1]: Started OpenBSD Secure Shell server.
déc. 08 19:49:59 hell sshd[4249]: Server listening on 10.0.2.150 port 22.
déc. 08 19:49:59 hell sshd[4249]: Server listening on 10.0.1.150 port 22.
déc. 08 19:49:59 hell sshd[4249]: Server listening on 192.168.0.150 port 22.

Can someone explain what the problem is?

501
1 + 2
Andrew Lowther avatar
jp flag
Andrew Lowther
I would guess ssh starts before the IPs have been set. Some solutions to this at https://unix.stackexchange.com/a/442199/439421
0
Reply
my flag
Fred L.
Hi Andrew, Thanks a lot for the link and English improvement you did on my ask. I read the solution and it sound good. I will try it tomorrow am. It is currently 1.48am so it is time to execute a shutdown -P now
0
Reply
Score:0
avatar Ubuntu
my flag
Fred L.

thanks a lot Andrew I've applied 1st option noticed into your url.

mkdir /etc/systemd/system/sshd.service.d

cat > /etc/systemd/system/sshd.service.d/network-online.conf <<EOF
[Unit]
After=network-online.target
EOF

systemctl daemon-reload

It's OK!

satan@hell:~$ sudo systemctl status ssh
● ssh.service - OpenBSD Secure Shell server
     Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: enabled)
    Drop-In: /etc/systemd/system/sshd.service.d
             └─network-online.conf
     Active: active (running) since Fri 2022-12-09 18:19:43 CET; 11min ago
       Docs: man:sshd(8)
             man:sshd_config(5)
    Process: 1447 ExecStartPre=/usr/sbin/sshd -t (code=exited, status=0/SUCCESS)
   Main PID: 1454 (sshd)
      Tasks: 1 (limit: 76717)
     Memory: 7.7M
        CPU: 134ms
     CGroup: /system.slice/ssh.service
             └─1454 "sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups"

déc. 09 18:19:43 hell systemd[1]: Started OpenBSD Secure Shell server.
déc. 09 18:19:43 hell sshd[1454]: Server listening on 10.0.2.150 port 20022.
déc. 09 18:19:43 hell sshd[1454]: Server listening on 10.0.1.150 port 10022.
déc. 09 18:19:43 hell sshd[1454]: Server listening on 192.168.0.150 port 22.
déc. 09 18:21:39 hell sshd[1489]: Accepted password for satan from 192.168.0.200 port 53816 ssh2
déc. 09 18:21:39 hell sshd[1489]: pam_unix(sshd:session): session opened for user satan(uid=1000) by (uid=0)
déc. 09 18:23:45 hell sshd[1672]: Accepted password for satan from 192.168.0.200 port 37374 ssh2
déc. 09 18:23:45 hell sshd[1672]: pam_unix(sshd:session): session opened for user satan(uid=1000) by (uid=0)
déc. 09 18:30:09 hell sshd[3681]: Accepted password for satan from 10.0.4.200 port 53132 ssh2
déc. 09 18:30:09 hell sshd[3681]: pam_unix(sshd:session): session opened for user satan(uid=1000) by (uid=0)

Thank you!

+ 0
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.