search for: stricthostkeychecking

...-------------------------------------------------------------------------- CC| |alex at testcore.net Version|5.9p1 |6.2p1 --- Comment #1 from alex at testcore.net --- Also encountered this (on 6.2p1-1) and found that the StrictHostKeyChecking option is entirely non-functional: Set this up in ~/.ssh/config: host 192.168.*,10.* StrictHostKeyChecking no But it has no effect when ssh'ing to any boxes in the defined networks. If a key is present in known_hosts file, but the host itself has changed, it craps out with the "WARNING...

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 Assignee: unassigned-bugs at mindrot.org...

On 03/15/2019 12:49 AM, Jeremy Lin wrote: > [...] connecting to hosts where the host key > changes frequently. I realize this is a fairly niche use case [...] Doesn't StrictHostKeyChecking=no do what is wanted?

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

Hi. With SCP, it seems like the option precedence is ignored. Although this seems to work well with SSH. $ scp -oStrictHostKeyChecking=no hs21-dev04:/tmp/1 hs21-dev02:/tmp/2 The authenticity of host 'hs21-dev04 (192.168.12.11)' can't be established. RSA key fingerprint is ec:0f:eb:b2:fa:6f:50:ef:89:64:01:5e:c9:cc:54:20. Are you sure you want to continue connecting (yes/no)? $ ssh -oStrictHostKeyChecking=no hs21-d...

...ss) 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 "StrictHostKeyChecking", and it seems to be impossible to specify multiple alternative hostkeys for a virtual host in "knows_hosts" (it would make sense however IMHO). Using the same host keys for both machines is not what I would like to do (assuming it would help), and I don't want to disable &qu...

...ssage was accurate and went looking for a truncation in the actual path name used and ended up barking up the wrong tree.) (In reply to Christoph Anton Mitterer from comment #4) [..] > It *still* happens, that SSH automatically adds a key, i.e.: > $ echo > ~/.ssh/known_hosts > $ ssh -o StrictHostKeyChecking=no someHost > Warning: Permanently added the ECDSA host key for IP address > '2e01:2a6:b9:3823::2:1' to the list of known hosts. > (changed the IP/name for privacy reasons). Err, that's exactly what StrictHostKeyChecking=no is supposed to do: "If this flag is set to &quo...

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: ssh As...

...n 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 set, there is no prompting for confirmation if the connection should be allowed to proceed; I'm unsure if this is by design or not (as presented host key and known host key match), but I'd argue this violates POLA. Attached are two na?ve patches to portable (cloned from anongit at mind...

...t;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 StrictHostKeyChecking=no someHost > Warning: Permanently added the ECDSA host key for IP address > '2e01:2a6:b9:3823::2:1' to the list of known hosts. > (changed the IP/name for privacy reasons). Did you have an existing, valid hostkey with a different algorithm for that host? I suspect it's due t...

Hello, the ssh_config man page for StrictHostKeyChecking contains a misleading sentence. The description of the option ends with "The host keys of known hosts will be verified automatically in all cases.". This sounds to me like no matter the value of StrictHostKeyChecking the host keys are verified; "verified" meaning "don't...

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

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 illegal value for StrictHostKeyChecking, an ip address target...

...erify > it. This goes for both protocols 1 (RSA host key) and 2 (DSA host key). I > remember that older versions used to display a warning and the > fingerprint and ask if I still wanted to connect (yes/no). openssh will show the fingerprint and ask (yes/no) if the host key is unknown (if StrictHostKeyChecking is set to ask, of course). if the hostkey has changed and StrictHostKeyChecking != no (the default is 'ask') then the ssh will exit. you can now remove the offending key, reconnect, and check the fingerprint given by the client (since the host key is now unknown). however, in future open...

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 Priority: P2 Component: ssh AssignedTo: unassigned-bugs at mindrot...

...g-how-is-it-working?noredirect=1#comment31511341_20952689 In summarise: In the first instance I can create a SSH connection, and and execute a remote git clone (via SSH), the Agent Forwarding works, and I am not prompted for credentials: ssh vagrant at 127.0.0.1 -p 2222 \ -o Compression=yes \ -o StrictHostKeyChecking=no \ -o LogLevel=FATAL \ -o StrictHostKeyChecking=no \ -o UserKnownHostsFile=/dev/null \ -o IdentitiesOnly=yes \ -i /Users/bryanhunt/.vagrant.d/insecure_private_key \ -o ForwardAgent=yes \ "/bin/sh -c 'git clone git at bitbucket.org:bryan_picsolve/poc_docker.git /home/vagrant/poc_dockera&...

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 > > '2e01:2a6:b9:3823::2:1' to the list of known hosts. > > (changed the IP/name for privacy reasons). First, I just tried it again with 6.7p1. > Did you have an existing, valid hostkey with...

How come "StrictHostKeyChecking ask" doesn't cause Ssh to ask me if I'm OK with a host key having changed and, assuming I say yes, go ahead and update known_hosts? It looks like the program gratuitously runs me through the exercise of editing known_hosts and starting over. Kudos for having the message tell me exact...

...Version|6.2p1 |6.7p1 --- Comment #4 from Christoph Anton Mitterer <calestyo at scientia.net> --- 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 StrictHostKeyChecking=no someHost Warning: Permanently added the ECDSA host key for IP address '2e01:2a6:b9:3823::2:1' to the list of known hosts. (changed the IP/name for privacy reasons). - the name truncation no longer happens, but only since the message is now a different one... so isn't that issue any...

https://bugzilla.mindrot.org/show_bug.cgi?id=2525 Bug ID: 2525 Summary: Please add an alias such as -o Insecure for -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no Product: Portable OpenSSH Version: 6.7p1 Hardware: amd64 OS: Linux Status: NEW Severity: trivial Priority: P5 Component: ssh Assignee: unassigned-bugs at mindrot.org Reporter: mjevans1983...