On Sat, Jul 20, 2019 at 2:54 PM Daniel Shahaf <d...@daniel.shahaf.name> wrote: > > Stefan Sperling wrote on Sat, 20 Jul 2019 09:51 +00:00: > > But as a user I find it infuriating when software I use contains > > artificial restrictions like this. We should assume our users know > > what they are doing. Subversion is not a web browser. > > I'm not entirely sure I'm convinced by this logic. Let's take OpenSSH for > example: > > [[[ > % ed .ssh/known_hosts > g/^hermes/d > s/^[^ ]*/hermes.apache.org/ > w > q > % ssh hermes.apache.org > @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ > @ 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 a host key has just been changed. > The fingerprint for the ECDSA key sent by the remote host is > SHA256:gJUlDrKOTnUQ/lAx6eM4Ylq6z/5ere2tJoLEgrfM++A. > Please contact your system administrator. > Add correct host key in /home/daniel/.ssh/known_hosts to get rid of this > message. > Offending ECDSA key in /home/daniel/.ssh/known_hosts:26 > remove with: > ssh-keygen -f "/home/daniel/.ssh/known_hosts" -R hermes.apache.org > ECDSA host key for hermes.apache.org has changed and you have requested > strict checking. > Host key verification failed. > zsh: exit 255 ssh hermes.apache.org > ]]] > > The error message does not give a way to continue the operation, but it > does tell you what command to run if you would like to proceed anyway. > This way, the buck stops with the user, but the program makes it quite > clear that this is an abnormal situation and caution should be > exercised. > > Should we do something similar (but without the all-caps? That's why > I proposed writing a command that takes a certificate on stdin and marks > it as trusted.
OpenSSH is an interesting example. The "known_hosts" file has been an active detriment to DHCP based environments, where the same machine may be rebuilt with the same hostname but a different IP address or different hostkeys, for decades. The easy solution is to discard the use of known_hosts, as documented all over the web, but summed up best by these entries in /etc/ssh/ssh_config or in $HOME/.ssh/config Host * StrictHostKeyChecking no UserKnownHostsFile /dev/null LogLevel ERROR This trick is most useful in environments where people use svn+ssh and the IP address of the Subversion server may change at unpredictable times. It's also very useful for Jenkins, and Ansible, tasks that may reach out to a Subversion server and don't want to have the known_hosts fuss on a regular basis. known_hosts, like SSL certificat signatures, has its security uses. But it has often proven a burden rather than a blessing.
