similar to: [Bug 3725] New: Unclear error when configuring 'ed25519' as HostKeyAlgorithms

Displaying 20 results from an estimated 2000 matches similar to: "[Bug 3725] New: Unclear error when configuring 'ed25519' as HostKeyAlgorithms"

2020 Feb 06
3
Call for testing: OpenSSH 8.2
On 2020-02-05 at 20:39 -0500, Phil Pennock wrote: > On 2020-02-06 at 10:29 +1100, Damien Miller wrote: > > OpenSSH 8.2p1 is almost ready for release, so we would appreciate testing > > on as many platforms and systems as possible. This is a feature release. > > > * The RFC8332 RSA SHA-2 signature algorithms rsa-sha2-256/512. These > This actually affects me:
2014 Apr 10
0
nistp256 preferred over ed25519
Hello, Maybe I'm asking an already answered question, if yes I'm sorry to bother you. Why in default HostKeyAlgorithms settings is ecdsa-sha2-nistp256-cert-v01 at openssh.com preferred over ssh-ed25519-cert-v01 at openssh.com ? For example in default settings for KexAlgorithms the curve25519-sha256 at libssh.org is preferred over ecdh-sha2-nistp256. Fedor Defaults in openssh-6.6p1
2020 Sep 16
2
ssh-ed25519 and ecdsa-sha2-nistp256 host keys
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!
2020 Sep 16
2
ssh-ed25519 and ecdsa-sha2-nistp256 host keys
Here you go: OpenSSH_7.9p1, OpenSSL 1.1.1d 10 Sep 2019 debug1: Reading configuration data /home/ryantm/.ssh/config debug1: /home/ryantm/.ssh/config line 4: Applying options for * debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 13: Applying options for * debug2: resolving "{REDACTED}" port 22 debug2: ssh_connect_direct debug1: Connecting to
2020 May 03
10
[Bug 3157] New: known_hosts @cert-authority with legacy plain key entry drops incorrect set of HostKeyAlgorithms
https://bugzilla.mindrot.org/show_bug.cgi?id=3157 Bug ID: 3157 Summary: known_hosts @cert-authority with legacy plain key entry drops incorrect set of HostKeyAlgorithms Product: Portable OpenSSH Version: 8.1p1 Hardware: All OS: Mac OS X Status: NEW Severity: normal Priority:
2024 Jul 07
13
[Bug 3708] New: Tracking bug for OpenSSH 9.9
https://bugzilla.mindrot.org/show_bug.cgi?id=3708 Bug ID: 3708 Summary: Tracking bug for OpenSSH 9.9 Product: Portable OpenSSH Version: -current Hardware: Other OS: All Status: NEW Keywords: meta Severity: enhancement Priority: P5 Component: Miscellaneous Assignee:
2020 Mar 02
4
Question about host key algorithms
$ ssh -Q HostKeyAlgorithms Unsupported query "HostKeyAlgorithms" $ ssh -V OpenSSH_7.4p1, OpenSSL 1.0.2u 20 Dec 2019 On Mon, Mar 2, 2020 at 2:24 PM Christian Hesse <list at eworm.de> wrote: > Luveh Keraph <1.41421 at gmail.com> on Mon, 2020/03/02 14:07: > > When I do ssh -Q key, where ssh is the OpenSSH 7.4p1 client, I get the > > following output: > >
2024 Sep 11
3
[Bug 3733] New: "forced command options do not match" after key error
https://bugzilla.mindrot.org/show_bug.cgi?id=3733 Bug ID: 3733 Summary: "forced command options do not match" after key error Product: Portable OpenSSH Version: 9.8p1 Hardware: amd64 OS: Linux Status: NEW Severity: normal Priority: P5 Component: sshd Assignee:
2020 Mar 02
3
Question about host key algorithms
When I do ssh -Q key, where ssh is the OpenSSH 7.4p1 client, I get the following output: ssh-ed25519 ssh-ed25519-cert-v01 at openssh.com ssh-rsa ssh-dss ecdsa-sha2-nistp256 ecdsa-sha2-nistp384 ecdsa-sha2-nistp521 ssh-rsa-cert-v01 at openssh.com ssh-dss-cert-v01 at openssh.com ecdsa-sha2-nistp256-cert-v01 at openssh.com ecdsa-sha2-nistp384-cert-v01 at openssh.com ecdsa-sha2-nistp521-cert-v01 at
2016 Dec 23
5
[Bug 2650] New: UpdateHostKeys ignores RSA keys if HostKeyAlgorithms=rsa-sha2-256
https://bugzilla.mindrot.org/show_bug.cgi?id=2650 Bug ID: 2650 Summary: UpdateHostKeys ignores RSA keys if HostKeyAlgorithms=rsa-sha2-256 Product: Portable OpenSSH Version: 7.4p1 Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 Component: ssh
2018 May 27
2
Strange crypto choices
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
2018 May 25
5
Strange crypto choices
The defaults for HostKeyAlgorithms option are: ecdsa-sha2-nistp256-cert-v01 at openssh.com, ecdsa-sha2-nistp384-cert-v01 at openssh.com, ecdsa-sha2-nistp521-cert-v01 at openssh.com, ssh-ed25519-cert-v01 at openssh.com, ssh-rsa-cert-v01 at openssh.com, ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521, ssh-ed25519,ssh-rsa Why does OpenSSH prefer older and less secure
2018 May 27
2
Strange crypto choices
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
2009 Jul 09
0
[PATCH] Allow binding to a local port (OpenSSH 5.2)
OpenSSH supports the -b bind_address argument for binding to a local IP address when connecting to a remote host. It's however currently not possible to specify a local port to bind to, something I've found useful at several occasions. Below is an unified diff that introduces the [-B bind_port] option to ssh(1) and a ssh_config(5) style option "BindPort bind_port". This allows
2018 Nov 01
8
[Bug 2924] New: Order a limited host keys list in client based on the known hosts
https://bugzilla.mindrot.org/show_bug.cgi?id=2924 Bug ID: 2924 Summary: Order a limited host keys list in client based on the known hosts Product: Portable OpenSSH Version: 7.7p1 Hardware: Other OS: Linux Status: NEW Keywords: patch Severity: enhancement Priority:
2019 Feb 22
4
Possible bug: SSH doesn't prefer host keys listed in SSHFP records while connecting.
Steps to reproduce: 1. Run a SSH server with default configuration and point a domain to it. 2. Add SSHFP record to the domain, but only for Ed25519 key. 3. Attempt to connect with VerifyHostKeyDNS set to yes, but the rest of settings set to defaults. 4. OpenSSH defaults to ECDSA instead of Ed25519 and refuses connection because there is no ECDSA fingerprint in SSHFP records. A stopgap solution
2019 Oct 17
0
DSA key not accepted on CentOS even after enabling
PubkeyAcceptedKeyTypes=+ssh-dss You also need that ^^ in their client if they are running on el8 machine as well .. i needed to put it in my ~/.ssh/config when connecting FROM an el8 machine to somewhere else. On 10/17/19 9:27 AM, Gianluca Cecchi wrote: > Hello, > I have some users that connect to a server with their DSA key that is of > type ssh-dss. > I'm migrating (installing
2001 May 18
0
PATCH: implement delay (sleep) after last tunnelled connection exits
Here is a patch to implement a handy new feature proposed by John Hardin <johnh at aproposretail.com>. This is his description of the feature: New option for OpenSSH: Delay before exit. Command line option: -S delay Config file option: sleep {delay} Purpose: Wait the specified number of seconds after last traffic before dropping the connection and exiting. If ports are forwarded, this
2019 Oct 17
2
DSA key not accepted on CentOS even after enabling
Hello, I have some users that connect to a server with their DSA key that is of type ssh-dss. I'm migrating (installing as new) the server where they connect to CentOS 8 + updates. I was not able to connect with the keys to this new server even after having added, as found in several internet pages, this directive at the end of /etc/ssh/sshd_config of the CentOS 8 server: # Accept also DSA
2016 Nov 08
2
one host only: ssh_dispatch_run_fatal
Darren Tucker <dtucker at zip.com.au> writes: > On Tue, Nov 8, 2016 at 3:30 PM, Harry Putnam <reader at newsguy.com> wrote: > [...] >> After having 7.3p1 & 6.8p1 fail with same wording... I tried 6.7p1 and >> find it fails with what looks like the same problem but has slightly >> different wording. > > I set up the same versions (server:OpenSSH_6.6p1,