similar to: known_hosts vulnerability?

http://techworld.com/opsys/news/index.cfm?NewsID=3064 The fact that they talk about Notes (the client) rather than Domino (the server) suggests that they may be running the Notes client (as I and many others do) under Linux, and the only way I know of to do this is to use Wine. David

Hi list members, just tried to get some old records out of my known_hosts, which is 'HashKnownHosts yes'. Is there a way to unhash host names and/or IPs? Google tells about, how to add hosts, but not the opposite, may be I miss some thing. Is this does not work at all, is there a best practice for cleaning old hosts and keys out? Thanks, Martin! -- Martin GnuPG Key Fingerprint, KeyID

Is there any way to remove old entries from the known_hosts file? With the hashed 'names' one can't easily see which entries are which. I have around 150 lines in my known hosts but in reality I only ssh to a dozen or so systems. All the redundant ones are because I have a mixed population of Raspberry Pis and such on my LAN and they get rebuilt fairly frequently and thus, each time,

http://bugzilla.mindrot.org/show_bug.cgi?id=910 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |foomzilla at fuhm.net ------- Additional Comments From djm at mindrot.org 2005-04-21 18:16 ------- *** Bug 454 has been marked as a

https://bugzilla.mindrot.org/show_bug.cgi?id=2560 Bug ID: 2560 Summary: sshd: Description of hashed known_hosts file does not make sense and format is outdated Product: Portable OpenSSH Version: -current Hardware: Other OS: Linux Status: NEW Severity: enhancement Priority: P5

http://bugzilla.mindrot.org/show_bug.cgi?id=910 mindrot at askneil.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mindrot at askneil.com ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the

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

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

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

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

Brian Candler wrote: > Chris Green wrote: > > ... redundant ones are because I have a mixed population of > > Raspberry Pis and such on my LAN and they get rebuilt fairly > > frequently and thus, each time, get a new entry in known_hosts. > ...many useful tips... > To disable host key checking altogether for certain domains and/or networks, > you can put this in

Hi, for a test lab, I'm trying to write a small shell script that will eradicate all information regarding a special host from the known_hosts file. Unfortunately, it is quite non-trivial to find out what ssh doesn't like with a host. ssh says which line in known_hosts has the offending key, but ssh-keygen -R doesn't take a line number. Am I using an undocumented interface when I

The .ssh/known_hosts table cannot handle reaching different sshd servers behind a NAT router. The machines are selected by having the SSHDs respond to differnt ports. A second request would be to allow known_hosts checking solely on the dns name, wildcarding the IP address. This would be useful to avoid continuously warning the user every time you connect to a machine with a changing IP address

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

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

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 >

On Tue, 29 Sep 2020 at 23:16, Nico Kadel-Garcia <nkadel at gmail.com> wrote: [...] > I gave up on $HOME/.ssh/known_hosts a *long* time ago, because if > servers are DHCP distributed without static IP addresses they can wind > up overlapping IP addresses with mismatched hostkeys You can set CheckHostIP=no in your config. As long as the names don't change it'll do what you

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,