similar to: Misleading documentation for StrictHostKeyChecking

https://bugzilla.mindrot.org/show_bug.cgi?id=1993 --- Comment #9 from Christoph Anton Mitterer <calestyo at scientia.net> --- (replies to all your comments in one) Hey. Sorry for the delay. (In reply to Darren Tucker from comment #5) > > $ ssh -o StrictHostKeyChecking=no someHost > > Warning: Permanently added the ECDSA host key for IP address > >

https://bugzilla.mindrot.org/show_bug.cgi?id=1993 --- Comment #5 from Darren Tucker <dtucker at zip.com.au> --- (In reply to Christoph Anton Mitterer from comment #4) > Hi guys. > > With version: 6.7p1 > > > Regarding my initial report: > > It *still* happens, that SSH automatically adds a key, i.e.: > $ echo > ~/.ssh/known_hosts > $ ssh -o

https://bugzilla.mindrot.org/show_bug.cgi?id=1993 --- Comment #7 from Darren Tucker <dtucker at zip.com.au> --- (In reply to Darren Tucker from comment #6) > Created attachment 2635 [details] > Remove length limits on know host file name in log messages A slightly different version of the patch has been committed and will be in the 6.9 release. (When I first looked at this I assumed

https://bugzilla.mindrot.org/show_bug.cgi?id=3176 Bug ID: 3176 Summary: can't figure out how to test StrictHostKeyChecking accept-new Product: Portable OpenSSH Version: 8.3p1 Hardware: Other OS: Linux Status: NEW Severity: enhancement Priority: P5 Component: ssh

https://bugzilla.mindrot.org/show_bug.cgi?id=2663 Bug ID: 2663 Summary: [man] sshd_config(5) AuthenticationMethods segment clarification, proposal and questions Product: Portable OpenSSH Version: 7.2p2 Hardware: Other OS: Linux Status: NEW Keywords: low-hanging-fruit

https://bugzilla.mindrot.org/show_bug.cgi?id=1993 --- Comment #8 from Damien Miller <djm at mindrot.org> --- The hostkeys-00 at openssh.com extension has to be explicitly enabled via UpdateHostKeys=yes|ask The OP's question is the CheckHostIP option updating addresses for hostnames it already knows about. We could probably clarify the documentation for this behaviour, but if you want

Folks, I read the 5.7 release announcement and updated, to try out ECDSA. Most parts worked very smoothly. The inability to create SSHFP records is understandable, since IANA haven't allocated a code yet. One apparent bug: I think StrictHostKeyChecking=ask is broken for ECDSA. % ssh -o HostKeyAlgorithms=ecdsa-sha2-nistp256 localhost

Hello, I have a kind of problem: I need to connect to a virtual host (a f "floating" IP address) that is one of two physical hosts in a HA environment. Yesterday the virtual IP address was moved to another host. Today ssh refuses to connect, because the host key is different. Reading the documentation I found that there is no command line option (documented) to temporarily bypass

https://bugzilla.mindrot.org/show_bug.cgi?id=2400 Bug ID: 2400 Summary: StrictHostKeyChecking=no behaviour on HOST_CHANGED is excessively insecure Product: Portable OpenSSH Version: 6.8p1 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 Component:

OpenSSH 7.6 has just been released. It will be available from the mirrors listed at http://www.openssh.com/ shortly. OpenSSH is a 100% complete SSH protocol 2.0 implementation and includes sftp client and server support. Once again, we would like to thank the OpenSSH community for their continued support of the project, especially those who contributed code or patches, reported bugs, tested

https://bugzilla.mindrot.org/show_bug.cgi?id=1993 alex at testcore.net changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |alex at testcore.net Version|5.9p1 |6.2p1 --- Comment #1 from alex at testcore.net --- Also

ssh -oStrictHostKeyChecking=no scrub @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that the RSA host key has just

OpenSSH 7.6 has just been released. It will be available from the mirrors listed at http://www.openssh.com/ shortly. OpenSSH is a 100% complete SSH protocol 2.0 implementation and includes sftp client and server support. Once again, we would like to thank the OpenSSH community for their continued support of the project, especially those who contributed code or patches, reported bugs, tested

http://bugzilla.mindrot.org/show_bug.cgi?id=1209 Summary: StrictHostKeyChecking really needs a 4th option Product: Portable OpenSSH Version: 4.3p2 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: ssh AssignedTo: bitbucket at mindrot.org ReportedBy:

Long ago, when I wrote the ssh config file on my desktop box, ssh (which might have been the non-openssh one) took 3 possible values for the StrictHostKeyChecking option - yes, no & ask. Today, when I attempted to connect to a new machine, with no DNS entries (so using IP address) from my desktop box, ssh (now 2.3.0p1) SEGVed. Looks like there is some subtle interaction between having an

https://bugzilla.mindrot.org/show_bug.cgi?id=1993 Bug #: 1993 Summary: ssh tries to add keys to ~/.ssh/known_hosts though StrictHostKeyChecking yes is set Classification: Unclassified Product: Portable OpenSSH Version: 5.9p1 Platform: All OS/Version: All Status: NEW Severity: normal

Hi, the following patch to contrib/cygwin/ssh-host-config creates /etc/ssh_config and /etc/sshd_config according to the current default config files. Could somebody please check it in? Corinna Index: contrib/cygwin/ssh-host-config =================================================================== RCS file: /cvs/openssh_cvs/contrib/cygwin/ssh-host-config,v retrieving revision 1.3 diff -u -p

> On Sep 4, 2020, at 2:40 PM, Neil Nelson via llvm-dev <llvm-dev at lists.llvm.org> wrote: > >> If fptosi takes 0.9 -> 0, then that is not 'rounding' in any sense I'm aware of (IEEE754 or otherwise). >> Rounding (in the IEE754 sense) determines how a number is converted when it is halfway between two >> candidate results. (see round(), ceil(),

Hi, As far as I can tell, when working in an environment with many servers, there seem to be several ways for your client to authenticate the HostKeys of each: 1) Set StrictHostKeyChecking=no, and hope you don't get MITM'd the first time you connect to a server. 2) Use SSHFP records (which generally requires you to have DNSSEC fully deployed to be meaningful compared to #1, I think?)

Y'all, Currently (OpenSSH_7.1p1) no distinction is made between when an SSHFP RR is missing from the result set (rather then being empty), which can lead to confusing error messages, (the "normal" warn_changed_key() blurb is emitted) e.g. when the presented host key and known hosts both match but there is no matching RR. Further, if VerifyHostKeyDNS and StrictHostKeyChecking are