After disabling weak ssh ciphers I cannot ssh in at all

Question

My goal is to disable weak ssh ciphers on a linux machine (specifically Lubuntu 14.10--yes, old, there are hardware compatibility reasons that it cannot be changed right now).

First thing, I checked that I can indeed ssh into the machine with a variety of ciphers. For example ssh USER@HOST -c aes256-cbc and ssh USER@HOST -c aes256-ctr prompt me for my password and let me in.

I've added the following to the bottom of my /etc/ssh/sshd_config file.

# Cryptographic Policy
# See https://www.ssh.com/academy/ssh/sshd_config#cryptographic-policy
Ciphers aes128-ctr,aes192-ctr,aes256-ctr  
HostKeyAlgorithms ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-rsa,ssh-dss  
KexAlgorithms ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha256  
MACs hmac-sha2-256,hmac-sha2-512

Now I'd like these changes to take effect, and I read everywhere that I should restart the sshd service. I assume that this must be the service that listens for ssh connections or something like that. I don't seem to have one running, though. It's not in the list of services. When I try and restart I get this:

$ service sshd restart
sshd: unrecognized service

So, I just rebooted the machine.

Even without this service running, the lines I added are doing something because after updating the config file and rebooting I am unable to ssh in at all using any cipher. It refuses the connection instead of giving me the anticipated "no matching ciphers found" (for a cipher that is supposedly disabled, now).

$ ssh USER@HOST -c aes256-cbc
ssh: connect to host <IP REDACTED> port 22: Connection refused
$ ssh USER@HOST -c aes256-ctr
ssh: connect to host <IP REDACTED> port 22: Connection refused

If I remove those lines and reboot, I can ssh in again as before.

It seems to me like adding these lines to the sshd_config file are breaking ssh. The fact that I cannot restart sshd potentially because it is not even running is odd. Perhaps I am misunderstanding what it is I am doing. Or, could the issue be that I'm using this old version?

$ ssh -V
OpenSSH_6.6.1p1 Ubuntu-8, OpenSSL 1.0.1f 6 Jan 2014

Thanks in advance for your insight. I hope what I've written is clear, and certainly I am happy to provide more details if needed.

---- UPDATE ----

Thank you for your answers and comments. From these I have figured out that for this machine I should not restart sshd, the service I should restart is called ssh. I was able to restart the service and put the changes made to /etc/ssh/sshd_config into effect by running sudo service ssh restart. This is more convenient than rebooting, and as you have all pointed out, less risky.

After restarting ssh I have the same behavior as after rebooting from before: all connections refused. My guess now is that Shadur is right, a typo, or one or more of the ciphers or algorithms I've asked it to use are unaccepted by this version.

---- UPDATE 2 ---- It works if I take out the HostKeyAlgorithms option. It seems like this was not a configuration option for OpenSSH 6.6. I think this commit may be where it was added.

$ ssh USER@HOST -c aes256-cbc
Unable to negotiate with <IP REDACTED> port 22: no matching cipher found. Their offer: aes128-ctr,aes192-ctr,aes256-ctr
$ ssh USER@HOST -c aes256-ctr           
USER@HOST's password: 
Welcome to Ubuntu 14.10 (GNU/Linux 3.16.0-23-generic i686)

Answer 1

Your critical mistake was rebooting when you weren't sure the service would come back up, but let's deal with the situation as is.

You mention hardware; I'm hoping this means you have physical access to the machine in a pinch so you can log on to a console.

Once you do (or someone else manages in your stead, if the machine is hosted elsewhere), I'm fairly sure you'll find that the name of the service is ssh rather than sshd, which means that service ssh status should give you an overview like the following:

shadur@periapsis:~$ service ssh status
● ssh.service - OpenBSD Secure Shell server
     Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: enabled)
     Active: active (running) since Thu 2022-04-21 21:45:37 CEST; 12h ago
       Docs: man:sshd(8)
             man:sshd_config(5)
    Process: 1357 ExecStartPre=/usr/sbin/sshd -t (code=exited, status=0/SUCCESS)
   Main PID: 1362 (sshd)
      Tasks: 4 (limit: 19080)
     Memory: 7.2M
        CPU: 5.703s
     CGroup: /system.slice/ssh.service
             ├─ 1362 "sshd: /usr/sbin/sshd -D [listener] 2 of 10-100 startups"
             ├─42848 "sshd: [accepted]"
             ├─42903 "sshd: root [priv]"
             └─42904 "sshd: root [net]"

Followed by a number of log entries detailing the last few things the sshd process had to say.

Alternately, you can check with journalctl -u ssh.service and see what the log output was.

My guess would be that you had a typo somewhere or referenced an encryption method that said older version of ssh doesn't know about.

For future reference, sshd -t or sshd -T will do a dry-run test of the configuration and spit out errors so that you don't have to risk restarting your sshd process when you're not sure it will come back up.