ghe writes:
>>Have you tried commands of this sort? # systemctl enable sshd.service # systemctl start sshd.service # systemctl status sshd.service >From asking it to start at boot: Failed to save action : Systemd service ssh cannot be created unless a command is given Trying the suggested commands: Failed to enable unit: Unit file sshd.service does not exist. Failed to start sshd.service: Unit sshd.service not found. Unit sshd.service could not be found.
Now that are some "good" error messages :) My next step would be to check were the unit is gone (might save the time to create one). On my system (not Rapsbian, but Debian 10.2 "Buster"), one can use these commands: $ systemctl | grep ssh ssh.service loaded active running OpenBSD Secure Shell server If `ssh.service` is present in `systemctl` output, it might be interesting to give the enable/start/status sequence another try with `sshd.service` replaced by `ssh.service`? $ dpkg -L openssh-server [...] /etc/init.d/ssh [...] /lib /lib/systemd /lib/systemd/system /lib/systemd/system/rescue-ssh.target /lib/systemd/system/ssh.service /lib/systemd/system/ssh.socket /lib/systemd/system/ssh@.service [...] This indicates that the actual unit name is `ssh.service` although on my system, `systemctl status sshd.service` (with additional `d`) works just as well :) It would be interesting to see, if the files are also present on the system which produces the error messages mentioned above. If no `.service` files can be identified this way, it would be interesting to check the version and origin of the `openssh-server` package like this (with the output from my system included as an example): $ apt-cache policy openssh-server openssh-server: Installed: 1:7.9p1-10+deb10u1 Candidate: 1:7.9p1-10+deb10u1 Version table: *** 1:7.9p1-10+deb10u1 500 500 http://security.debian.org buster/updates/main amd64 Packages 500 file:/fs/e01/normal/debianmirror/cnt buster/main amd64 Packages 100 /var/lib/dpkg/status HTH Linux-Fan
Attachment:
pgprmntlSdTQU.pgp
Description: PGP signature