cannot re-enable sshd after systemd mask

Question

After disabling sshd, I'm having issues re-enabling/starting it via systemctl.

I'm sure I've hosed something, but this is what I did:

• ~fresh xubuntu 16.04.2 install
• apt install openssh-server
  • probably had to manually enabled it; I don't remember
  • kept default config file as-is (accessing over local LAN only)
• (ssh'd in successfully to scp over data from a previous machine)
• attempted to disable sshd, as I didn't intend to use it further
  • systemctl stop sshd && systemctl disable sshd && systemctl mask sshd
  • (did I do something wrong here?)
• now I need ssh access again, so I am trying to enable:
  • systemctl unmask sshd - outputs that it removed the /dev/null symlink
  • systemctl enable sshd Failed to execute operation: No such file or directory

Searching for solutions, I didn't find much besides what (I think) I already tried. I have re-installed apt remove openssh-server && apt install openssh-server, but I am getting the same result.

An systemctl status sshd shows:

sshd.service
 Loaded: not-found (Reason: No such file or directory)
 Active: inactive (dead)

I'm not familiar with systemctl. Help would be greatly appreciated!!

Solution

It appears that sshd is an "alias" of sorts for ssh.service; when you install openssh-server, symlink(s) are set up mapping this.

However, when you systemctl disable sshd those symlinks are deleted, and are NOT restored with an enable.

The solutions is to systemctl enable ssh.service

Comments

[some bits flipped]

I notice that running /usr/sbin/sshd (no paramaters) results in the daemon running, listening on port 22, and I can now ssh in. systemctl status sshd returns the same as aobve (not-found, dead)

[some bits flipped]

and that systemctl enable ssh.service removes the No such file error from systemctl status sshd superuser.com/questions/1069621/… ... sounds between these two comments I have some bookkeeping to fix and all will be well. I'm striking out finding any concise descriptions for this, though.