similar to: find canonic host name [SECURITY VULNERABILITY]

I am concerned about the code under the comment /* Find canonic host name. */ in ssh.c. This replaces the hostname entered by the user with the cannonical name determined by getaddrinfo, causing the new name to be used henceforth. This includes connecting to the host, and finding its public key in a known_hosts file. getaddrinfo seems (on Debian GNU/Linux 2.2, GNU libc 2.1.3) to look up

Hey all, I came across a security news article, referenced by http://www.linux.org/news, at http://www.techworld.com/security/news/index.cfm?NewsID=3668 talking about an SSH weakness involving the known_hosts file. I apologize if this issue has already been addressed, but the mailing list archives didn't turn up anything when i tried searching for something relevant. So; not to knee-jerk or

If I want to specify for LAN addresses that I don't want to deal with host keys, how do I do that? Understanding the risks, knowing almost everyone will say not to do this - it's a horrible idea, but deciding I want to do it anyway. Tired of having to remove entries from known_hosts with the multiple VM's I have that often change fingerprints, and am willing to live with the risks.

https://bugzilla.mindrot.org/show_bug.cgi?id=2285 Bug ID: 2285 Summary: Say NOT updated instead of updated Product: Portable OpenSSH Version: 6.6p1 Hardware: Other URL: http://bugs.debian.org/764269 OS: Linux Status: NEW Severity: trivial Priority: P5 Component:

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

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

https://bugzilla.mindrot.org/show_bug.cgi?id=3083 Bug ID: 3083 Summary: Passing tilde (HOME) in file option results in cryptic error Product: Portable OpenSSH Version: 8.1p1 Hardware: ix86 OS: Linux Status: NEW Severity: enhancement Priority: P5 Component: ssh-keygen

Hello & thanks for reading. I'm having a problem configuring known_hosts from scripts so an accept key yes/no prompt doesn't appear. I'm using this command to detect if the server is known and add it to known_hosts: if ! ssh-keygen -F ${IP_ADDR} -f ~/.ssh/known_hosts > /dev/null 2>&1; t hen ssh-keyscan -p ${PORT} ${IP_ADDR} >> ~/.ssh/known_hosts; fi This works

On Sun, Oct 04, 2020 at 10:50:32PM +1100, Damien Miller wrote: > On Sun, 4 Oct 2020, Matthieu Herrb wrote: > > > On Sun, Oct 04, 2020 at 09:24:12PM +1100, Damien Miller wrote: > > > On Sun, 4 Oct 2020, Damien Miller wrote: > > > > > > > No - I think you've stumbled on a corner case I hadn't anticipated. > > > > Does your configuration

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

On Sun, 4 Oct 2020, Matthieu Herrb wrote: > Hi, > > on OpenBSD-current I now get this when connecting to an existing > machine for which I have both ecdsa an ed25519 keys in my existing > known_hosts (but apparently ed25519 keys where added only for the name > previsously by ssh): > > Warning: the ED25519 host key for 'freedom' differs from the key for > the

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

I dug through the list archives to see if this had come up before, and I see that a bug <http://bugzilla.mindrot.org/show_bug.cgi?id=393> was submitted and subsequently closed (basically rejected) in 2002. The basic issue, for those of you who don't feel like following the bug URL, is that when one has ssh servers behind a NAT, each of which responds to a different port on the NAT IP,

Hi guys, I'm working on a project which concern SSH and there is something i don't understand about server authentication. So I explain my problem: - When you authorize only RSA keys in the sshd_config on the server, you need to have the RSA public key of this server in the known_hosts file of the client. This is absolutely normal. - When you authorize only DSA keys in the sshd_config

On Wed, 5 Feb 2020, Phil Pennock wrote: > On 2020-02-06 at 10:29 +1100, Damien Miller wrote: > > * sshd(8): allow the UpdateHostKeys feature to function when > > multiple known_hosts files are in use. When updating host keys, > > ssh will now search subsequent known_hosts files, but will add > > updated host keys to the first specified file only. bz2738 >

I have confirmed this behavior from OpenSSH 6.6 in OS X (from MacPorts) and 6.6 in Ubuntu. I have set up a SSH Certificate authority, and as such I put in the following line at the top of my known_hosts file @cert-authority *.mydomain.com ssh-rsa <public key> Below this are all my hashed entries for various other hosts that I?ve contacted over the years. Every once in a while I?ll

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, Oct 04, 2020 at 09:24:12PM +1100, Damien Miller wrote: > On Sun, 4 Oct 2020, Damien Miller wrote: > > > No - I think you've stumbled on a corner case I hadn't anticipated. > > Does your configuration override CheckHostIP at all? No. > > > > What are the known_hosts entries for the hostname and IP? > > Also, do you use HashKnownHosts? or do

Hi folks, maybe I am too blind to see, but would it be possible to avoid extra entries in known_hosts, if the remote host has a signed public key matching a @cert-authority line? Something like Host * HashKnownHosts unsigned This could help to keep the known_hosts file small and yet get all the unsigned public keys in. Just a suggestion, of course. Regards Harri