SSH: Couldn't agree a key algorithm (available: curve25519-sha256@libssh.org)

doktornotor

For putty, really use the daily builds ONLY. ECDSA and Ed25519 is there as well. The stable release is not usable.

johnpoz

Yeah I use the dev bulds.. But as of late I just use kitty which is a fork of putty that supports everything as of a few updates back. Or I just use the windows build of openssh.. This is really the easiest way to know for sure your going to have full support of all the ciphers and algo's that openssh is using.

https://www.mls-software.com/opensshd.html

jimp

Good news, ChaCha20 is coming to SecureCRT

You previously requested support for the ChaCha20-Poly1305 cipher for SSH2
sessions. This has been implemented in a pre-beta version of SecureCRT and SecureFX.

If you would be interested in trying it, please let me know which product(s) and
platform(s) you need.

Products:

SecureCRT
SecureCRT and SecureFX

Platforms:

Windows (64-bit)
Windows (32-bit)
Mac OS X (10.11 and later)
Linux (Ubuntu 16.x, 64-bit)
Linux (Ubuntu 16.x, 32-bit)
Linux (Ubuntu 14.x and 15.x, 64-bit)
Linux (Ubuntu 14.x and 15.x, 32-bit)
Linux (RHEL 7.0)

johnpoz

Yeah I just emailed her, says on my thread to contact her for access to the prebeta ;)

chrcoluk

yeah she emailed me about it some days back, no GCM still but at least CHACHA is something.

johnpoz

So got the new secure beta.. And finally

[LOCAL] : Available Remote Send Ciphers = chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
[LOCAL] : Selected Send Cipher = chacha20-poly1305@openssh.com
[LOCAL] : Available Remote Recv Ciphers = chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
[LOCAL] : Selected Recv Cipher = chacha20-poly1305@openssh.com

Now they just need to add GCM ;)

riahc3

@jimp:

FYI- We disabled some older, weaker, ssh key exchange algorithms. It won't be uncommon to find some older programs that use ssh directly or via things like libssh, that will need to be updated.

How do you reenable them?

johnpoz

Why would you need to re-enable them.. They have been disabled for a reason, ie not secure.. Update your client is the correct fix here..

riahc3

@johnpoz:

Why would you need to re-enable them.. They have been disabled for a reason, ie not secure.. Update your client is the correct fix here..

Thats awesome.

How do you reenable them?

(For the record, yes, I am fully aware that many companies in 2016-2017, made SHA1 deprecated)

kpa

You re-enable them by rolling your own custom version of pfSense where you enable them in the openssh configuration. Oh and forget any official support if you follow that route.

riahc3

@kpa:

You re-enable them by rolling your own custom version of pfSense where you enable them in the openssh configuration. Oh and forget any official support if you follow that route.

No.

From the posts in this thread, they were disabled not removed (ala PPTP). They should be able to be enabled (under your own responsability)

The issue for example is that PPTP was warned several months in advance that it was going to get removed. Maybe I missed it for SHA1 but…

The point is that this thread only talks about it is disabled, not removed so...

johnpoz

"How do you reenable them?"

You edit your sshd_conf to use the what you want.. But again I am going to stress they were disabled for a REASON!!!


[2.4.0-BETA][root@pfsense.local.lan]/etc/ssh: cat sshd_config 
# This file is automatically generated at startup
KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256
Port 22
Protocol 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_ed25519_key
Compression yes
ClientAliveInterval 30
PermitRootLogin yes
# Login via Key only
ChallengeResponseAuthentication no
PasswordAuthentication no
PubkeyAuthentication yes
UsePAM no
UseDNS no
LoginGraceTime 30s
VersionAddendum none
X11Forwarding no
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-ripemd160-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,hmac-ripemd160,umac-128@openssh.com
# override default of no subsystems
Subsystem       sftp    /usr/libexec/sftp-server

Notice the part that says this file created at startup.. So you would have to edit sshd script that does the creation. Or you could use the sshd_extra file pretty sure..

I can not stress this enough - do not lower the security of your sshd, up the security of the client your using to access it. Putty is FREE it works just fine, they have a securecrt client closed beta you can get that supports the chacha stuff. You can use just the mls windows version of openssh, which is what I use all the time.. also FREE

You should never lower your security to "make something work"… This is just bad security 101..

What I did notice from this thread since I connected in with ssh -v into pfsense is they are behind on their ssh.. they are running 7.2 while 7.5 is current.

debug1: Local version string SSH-2.0-OpenSSH_7.5
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.2
debug1: match: OpenSSH_7.2 pat OpenSSH* compat 0x04000000

riahc3

@johnpoz:

"How do you reenable them?"

You edit your sshd_conf to use the what you want.. But again I am going to stress they were disabled for a REASON!!!
[2.4.0-BETA][root@pfsense.local.lan]/etc/ssh: cat sshd_config 
# This file is automatically generated at startup
KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256
Port 22
Protocol 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_ed25519_key
Compression yes
ClientAliveInterval 30
PermitRootLogin yes
# Login via Key only
ChallengeResponseAuthentication no
PasswordAuthentication no
PubkeyAuthentication yes
UsePAM no
UseDNS no
LoginGraceTime 30s
VersionAddendum none
X11Forwarding no
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-ripemd160-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,hmac-ripemd160,umac-128@openssh.com
# override default of no subsystems
Subsystem       sftp    /usr/libexec/sftp-server
Notice the part that says this file created at startup.. So you would have to edit sshd script that does the creation. Or you could use the sshd_extra file pretty sure..

I can not stress this enough - do not lower the security of your sshd, up the security of the client your using to access it. Putty is FREE it works just fine, they have a securecrt client closed beta you can get that supports the chacha stuff. You can use just the mls windows version of openssh, which is what I use all the time.. also FREE

You should never lower your security to "make something work"… This is just bad security 101..

What I did notice from this thread since I connected in with ssh -v into pfsense is they are behind on their ssh.. they are running 7.2 while 7.5 is current.

debug1: Local version string SSH-2.0-OpenSSH_7.5
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.2
debug1: match: OpenSSH_7.2 pat OpenSSH* compat 0x04000000

Quoted in case of removal.

riahc3

@johnpoz:

I can not stress this enough - do not lower the security of your sshd, up the security of the client your using to access it. Putty is FREE it works just fine, they have a securecrt client closed beta you can get that supports the chacha stuff. You can use just the mls windows version of openssh, which is what I use all the time.. also FREE

You should never lower your security to "make something work"… This is just bad security 101..

Even though this is not my case why I asked how to enable it again and while I agree with you, you cannot have 1000 clients waiting to be updated and/or people that use older clients where there isnt development anymore, suddenly stop working. You need a solution now. That quickest solution (as much as a bandaid it is) is to enable the older standard (which is really irrelevent when the servers are internal non public facing and/or you have monitoring on your systems)

When you make sure that all clients are updated and compatible, THEN and ONLY then, can it be re disabled and use the newer and safer standard.

jimp

You re-enable them the same way you revert any change you don't want. Find the commits that made the change and revert them or manually change them back the way they were.

None of that banter belongs in this thread. Locking.