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)
  • Are you sure that your machine is using service and not systemctl? Try typing systemctl and see what it spits out.
    – dg99
    Apr 21, 2022 at 23:59
  • FWIW flavors of Ubuntu 14.10 would have used upstart rather than systemd - see for example Upstart or Systemd. Even where systemd is the default init, /usr/sbin/service is provided as a wrapper script for backward compatibility I think. It might just be a matter of sshd being the wrong service name - try service ssh restart or service ssh status for example. Apr 22, 2022 at 0:17
  • "So I just rebooted my machine" -- future advice? Don't do that, especially when you're not sure your remote access will come back up.
    – Shadur
    Apr 22, 2022 at 7:55
  • @steeldriver, ah thanks, this output makes more sense now for service ssh restart I think I get a rejected stop and start that were forwarded to upstart stop: Rejected send message, 1 matched rules; type="method_call", sender=":1.56" (uid=1000 pid=4591 comm="stop ssh ") interface="com.ubuntu.Upstart0_6.Job" member="Stop" error name="(unset)" requested_reply="0" destination="com.ubuntu.Upstart" (uid=0 pid=1 comm="/sbin/init"). From what I just read, it seems like I can use upstart directlly with stop ssh or start ssh which both tell me Unknown job: ssh. Apr 22, 2022 at 13:41
  • Ah ok, I get it now. It needs to be sudo service ssh restart and then I get output saying that ssh was stopped and started. Apr 22, 2022 at 13:53

1 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)
    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.

  • I did see ssh in the list of services and tried restarting it as well, but that didn't work. It sounds like I should pursue this. For me service ssh status tells me ssh start/running, process 1099, but nothing else. journalctl tells me No journal files were found. Thanks for the sshd -t trick. I do have access to this machine another way, but this will come in handy in the future. Apr 22, 2022 at 13:49

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .