similar to: curve25519

Dear OpenSSH developers, I've worked this week on an alternative key exchange mechanism, in reaction to the whole NSA leaks and claims over cryptographic backdoors and/or cracking advances. The key exchange is in my opinion the most critical defense against passive eavesdropping attacks. I believe Curve25519 from DJB can give users a secure alternative to classical Diffie-Hellman (with fixed

It should be compatible with the original patch. However I think that the shared secret should be encoded as a string, too. What does libssh do? > Am 02.11.2013 um 05:46 schrieb Damien Miller <djm at mindrot.org>: > >> On Fri, 1 Nov 2013, Markus Friedl wrote: >> >> Here are three versions (patch against openbsd cvs) >> >> 1) repace nacl w/libsodium,

Here are three versions (patch against openbsd cvs) 1) repace nacl w/libsodium, so i could test 2) curve25519-donna 3) Matthew's public domain reference implementation. i'd vote for #3 -------------- next part -------------- Am 30.10.2013 um 07:27 schrieb Damien Miller <djm at mindrot.org>: > On Tue, 24 Sep 2013, Aris Adamantiadis wrote: > >> Dear OpenSSH

Am 02.11.2013 um 11:38 schrieb Aris Adamantiadis <aris at 0xbadc0de.be>: > RFC4251 describes mpint to be multi-size and with positive values having > MSB clear, so it's clearly incompatible with raw string. > > Since you both agreed on the curve25519 implementation to use, I'll work > today on Markus' patch to make the changes Damien wanted. What do you want to

Hi, mancha and me debugged a problem with OpenSSH 7.3p1 that was reported on the #openssh freenode channel. Symptoms were that this message was popping on the console during a busy X11 session: kex protocol error: type 7 seq 1234 I managed to reproduce the problem, it is related to the SSH_EXT_INFO packet that is send by the server every time it is sending an SSH_NEWKEYS packet, hence after

https://bugzilla.mindrot.org/show_bug.cgi?id=2376 Bug ID: 2376 Summary: Add compile time option to disable Curve25519 Product: Portable OpenSSH Version: 6.8p1 Hardware: Sparc OS: Solaris Status: NEW Severity: enhancement Priority: P5 Component: Build system Assignee:

See attached: (1) patch against 7.9p1, tested with openssl 1.1.0j and openssl 1.1.1a on linux/i386; passes regression test and connects to unpatched sshd without problems; I hacked a bit regress/unittests/kex, and benchmarked do_kex_with_key("curve25519-sha256 at libssh.org", KEY_ED25519, 256); Before: 0.3295s per call After: 0.2183s per call That is, 50% speedup; assuming

On 25.01.24 14:09, Kaushal Shriyan wrote: > I am running the below servers on Red Hat Enterprise Linux release 8.7 > How do I enable strong KexAlgorithms, Ciphers and MACs On RHEL 8, you need to be aware that there are "crypto policies" modifying sshd's behaviour, and it would likely be the *preferred* method to inject your intended config changes *there* (unless they

Get the following error: root at x065:[/data/prj/openbsd/openssh/openssh-7.7p1/openbsd-compat]make ??????? xlc_r -I/opt/include -O2 -qmaxmem=-1 -qarch=pwr5 -q64 -I. -I.. -I../../src/openssh-7.7p1/openbsd-compat -I../../src/openssh-7.7p1/openbsd-compat/.. -I/opt/include -DHAVE_CONFIG_H -c ../../src/openssh-7.7p1/openbsd-compat/strndup.c

Hello. I am running OpenSSH 7.9p1 on my client and server. ssh-keyscan shows the server has ssh-rsa, ssh-ed25519, and ecdsa-sha2-nistp256 host keys. My /etc/ssh/ssh_known_hosts file contains the server's ssh-ed25519 host key. When I try to SSH to the server I get this error: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!

On 30/06/2023 09:56, Damien Miller wrote: > It's very hard to figure out what is happening here without a debug log. > > You can get one by stopping the listening sshd and running it manually > in debug mode, e.g. "/usr/sbin/sshd -ddd" Or starting one in debug mode on a different port, e.g. "-p99 -ddd"

On Sat, 26 May 2018, Christian Weisgerber wrote: > On 2018-05-25, Yegor Ievlev <koops1997 at gmail.com> wrote: > > > The defaults for HostKeyAlgorithms option are: [...] > > Why does OpenSSH prefer older and less secure > > (https://safecurves.cr.yp.to/) ECDSA with NIST curves over Ed25519? > > I asked Markus and Damien about this in the past but honestly

Il giorno gio 22 nov 2018 alle ore 21:24 Stuart Henderson <stu at spacehopper.org> ha scritto: > > On 2018/11/22 19:55, owl700 at gmail.com wrote: > > Hi, I have compatibility issues with the latest version of > > openssh-server and an old dropbear client, the dopbear client stops at > > preauth > > > > ov 22 14:34:03 myhostname sshd[3905]: debug1: Client

Hi Kaushal, I maintain a set of SSH hardening guides for various platforms, including RHEL 8. You can find them here: https://ssh-audit.com/hardening_guides.html - Joe -- Joseph S. Testa II Founder & Principal Security Consultant Positron Security On Thu, 2024-01-25 at 18:39 +0530, Kaushal Shriyan wrote: > Hi, > > I am running the below servers on Red Hat Enterprise

if I understand http://git.libssh.org/projects/libssh.git/commit/?id=4cb6afcbd43ab503d4c3d3054b96a1492605ea8d correctly, then the shared secret is encoded as a bignum, probably because the rest of the code assumes it's a bignum (e.g. for key derivation, etc). however, the DH public keys are always encoded as strings (both in my patches and in the libssh.org code). Am 02.11.2013 um 07:57

On 23/04/2018 11:49, Michael Felt wrote: > On 21/04/2018 16:21, Michael Felt wrote: > > > Question: I have not dug into the tests yet. Will copy to a "local" > directory, and not build out of tree and see if that fixes it (as it > does for many other packages). However, just in case it does not - how > can I fast-forward the tests to the "agent" tests?

Darren Tucker <dtucker at zip.com.au> writes: > On Tue, Nov 8, 2016 at 1:02 PM, Harry Putnam <reader at newsguy.com> wrote: > [...] >> gv harry> ssh -vv 2x >> >> OpenSSH_7.3p1-hpn14v11, OpenSSL 1.0.2j 26 Sep 2016 > > this is a third-party modified version of OpenSSH. Can you reproduce > the problem with a stock OpenSSH from the source from

I added an EXPLICIT AuthenticationMethods publickey,keyboard-interactive + UsePam yes to sshd_config. Now, at connect attempt I get Password: Verification code: Password: Verification code: Password: ... I.e., It's asking for Password, not accepting pubkey AND when given the password (which is correct), and the GA VerificationCode, it simply repeats the credentials request.

there are more implications to changing key algorithms than KEX algorithms. If a change is made to the specification, then it might invalidate all the keys that are out there, this isn't the case with any other negotiated algorithm, On Sun, 27 May 2018, Yegor Ievlev wrote: > I don't think we should wait for a RFC in order to use stronger > crypto. We already prefer Curve25519 for

On Mon, 28 May 2018, Yegor Ievlev wrote: > Can we prefer RSA to ECDSA? For example: > HostKeyAlgorithms > ssh-rsa,ssh-ed25519,ecdsa-sha2-nistp521,ecdsa-sha2-nistp384,ecdsa-sha2-nistp256 not without a good reason