similar to: Ldap and host keys

On 2024-10-17 19:26, Nico Kadel-Garcia wrote: > > Thank you! Increasing the verbosity revealed a known_hosts entry linked > > to serverA's IP address (I had forgotten that I had connected to it by > > IP address at some point). Deleting this entry solved the problem; the > > new host key was stored in known_hosts when I connected to serverA > > again. > >

On Mon, Oct 14, 2024 at 5:33?AM Jan Eden via openssh-unix-dev <openssh-unix-dev at mindrot.org> wrote: redacted hostname and port ? sorry, should have mentioned that. > > > Anyway, in answer to your question. The "host key found matching a different > > name/address" is triggered when a key received from the server in an update > > already exists under a

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!

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

I've got a problem that I'm hoping the list can help with, otherwise ... Heres the problem, I've got OpenSSH 1.2.2p1 running on my Intel Linux box as the secure server. I can connect from another Intel Linux box using scp and it all seems to work fine. Another box tries to connect and it gets a warning about the host keysize not matching. I'm thinking this could be some byte

There's currently no way to express trust for an SSH certificate CA other than by manually adding it to known_hosts. This patch modifies the automatic key write-out behaviour on user verification to associate the hostname with the CA rather than the host key, allowing environments making use of certificates to update (potentially compromised) host keys without needing to modify client

On 2024-10-14 14:48, Damien Miller wrote: > On Sun, 13 Oct 2024, Jan Eden via openssh-unix-dev wrote: > > When I connect to serverA (`ssh -v -o UpdateHostKeys=yes serverA`) > > afterwards, known_hosts on the client is not updated. The output of the > > ssh command contains this: > > > > debug1: Host '[serverA.domain.internal]:22' is known and matches the

Hi, I created new host keys on serverA, updated sshd_config accordingly (adding the line below) and restarted ssh: cd /etc/ssh sudo ssh-keygen -f 2024_ssh_host_ed25519_key -t ed25519 -N '' sudo vi /etc/ssh/sshd_config # added line: HostKey /etc/ssh/2024_ssh_host_ed25519_key sudo service ssh restart When I connect to serverA (`ssh -v -o UpdateHostKeys=yes serverA`) afterwards,

On Sun, 13 Oct 2024, Jan Eden via openssh-unix-dev wrote: > Hi, > > I created new host keys on serverA, updated sshd_config accordingly > (adding the line below) and restarted ssh: > > cd /etc/ssh > sudo ssh-keygen -f 2024_ssh_host_ed25519_key -t ed25519 -N '' > > sudo vi /etc/ssh/sshd_config > # added line: HostKey /etc/ssh/2024_ssh_host_ed25519_key >

Well, SSHFP is supposed to only be used on DNSSEC-enabled domains. On Sat, Feb 23, 2019 at 9:59 PM Peter Stuge <peter at stuge.se> wrote: > > Yegor Ievlev wrote: > > It would make more sense to treat SSHFP records in the same way as > > known_hosts > > I disagree with that - known_hosts is nominally a client-local configuration. > > I think it's a very bad

On 17/06/20, Damien Miller (djm at mindrot.org) wrote: > > Firstly, given a host CA signing key on the sshagentca server, would an > > appropriately constructed host certificate added to a forwarded agent > > replace the necessity for a '@cert-authority' line in a user's known_hosts > > file? > > I'm not sure I want to add yet another path (the agent)

http://bugzilla.mindrot.org/show_bug.cgi?id=747 Summary: host authentication requires RSA1 keys Product: Portable OpenSSH Version: 3.7.1p1 Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Documentation AssignedTo: openssh-bugs at mindrot.org ReportedBy:

Well, known_hosts isn't exactly trusted input, since it's usually composed of the keys you first encounter, without any additional checking, as opposed to (hopefully) correctly signed SSHFP records. On Sat, Feb 23, 2019 at 10:22 PM Peter Stuge <peter at stuge.se> wrote: > > Yegor Ievlev wrote: > > > I think it's a very bad idea to have the client start treating

On Fri, Aug 28, 2015 at 8:48 AM, Bostjan Skufca <bostjan at a2o.si> wrote: > On 27 August 2015 at 05:01, Damien Miller <djm at mindrot.org> wrote: >> Yeah, it's unfortunately quite difficult to implement address matching >> in ~/.ssh/config because of the interplay of Host matching, Hostname >> directives, hostname canonicalisation*, proxy commands, hosts

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

Hi, and here's the next feature request, which sounds interesting. Also I think I won't need much extra code to add this feature. So what do you guys think? > `ssh' with its host key checking is incompatible with the use of > `redir' to map different ports on a gateway/firewall system to > different systems behind the firewall. > For instance, I redirect ports as

I''m in the process of automating the build of Oracle RAC nodes running on Linux but there''s one part I can''t quite get my head around. Oracle RAC requires that the oracle user on each node has an authorized_keys file containing the public keys of the oracle user on every other node. It also requires that the known_hosts file contains host keys for all other nodes to

As of version 3.0.2p1 and perhaps earlier localhost forwarded connections are checked in known_hosts. The difficulty is that if you have multiple forwards, only one of them will exist as a valid host key for localhost. All the others will be treated as a "Changed" key prompting reduced functionality including disallowing agent-forwarding. Depending on StrictHostKeyChecking being set,

https://bugzilla.mindrot.org/show_bug.cgi?id=2145 Bug ID: 2145 Summary: ssh-keygen -R doesn't work when there are entries for "proxycommand" keys Product: Portable OpenSSH Version: 6.2p1 Hardware: Other OS: Linux Status: NEW Severity: trivial Priority: P5

https://bugzilla.mindrot.org/show_bug.cgi?id=3627 Bug ID: 3627 Summary: openssh 9.4p1 does not see RSA keys in know_hosts file. Product: Portable OpenSSH Version: 9.4p1 Hardware: SPARC OS: Solaris Status: NEW Severity: major Priority: P5 Component: ssh