Skip to main content
Bumped by Community user
Bumped by Community user
added 537 characters in body
Source Link

---- EDITEDUPDATE ----

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)

---- EDITED ----

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 ----

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)
added 657 characters in body
Source Link

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 shssh 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.

---- EDITED ----

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.

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 sh 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.

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.

---- EDITED ----

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.

Source Link

After disabling weak ssh ciphers I cannot ssh in at all

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 sh 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.