On Sat, Jul 20, 2019 at 2:54 PM Daniel Shahaf <d.s_at_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.
Received on 2019-07-20 21:22:29 CEST