Reword an awkward part of the manpage

This commit is contained in:
Juhani Krekelä 2018-09-08 20:59:22 +03:00
parent ef51f70342
commit 2242820951
2 changed files with 31 additions and 21 deletions

View File

@ -6,7 +6,7 @@ DATAROOTDIR?=$(PREFIX)/share
MANDIR?=$(DATAROOTDIR)/man MANDIR?=$(DATAROOTDIR)/man
BINS:=sshwot-export-known-hosts sshwot-filter sshwot-verify BINS:=sshwot-export-known-hosts sshwot-filter sshwot-verify
MANS:=sshwot-verify.1 MAN1S:=sshwot-verify.1
SSHWOT_EXPORT_KNOWN_HOSTS_MAIN:=src/main-export-known-hosts.py SSHWOT_EXPORT_KNOWN_HOSTS_MAIN:=src/main-export-known-hosts.py
SSHWOT_EXPORT_KNOWN_HOSTS_DEPS:=src/entry.py src/hashing.py src/process_known_hosts.py src/write_file.py SSHWOT_EXPORT_KNOWN_HOSTS_DEPS:=src/entry.py src/hashing.py src/process_known_hosts.py src/write_file.py
@ -39,15 +39,15 @@ sshwot-verify: $(SSHWOT_VERIFY_MAIN) $(SSHWOT_VERIFY_DEPS)
.PHONY: all install unininstall clean distclean buildclean .PHONY: all install unininstall clean distclean buildclean
install: $(BINS) $(MANS) install: $(BINS) $(MAN1S)
mkdir -p $(DESTDIR)$(BINDIR) mkdir -p $(DESTDIR)$(BINDIR)
install $(BINS) $(DESTDIR)$(BINDIR) install $(BINS) $(DESTDIR)$(BINDIR)
mkdir -p $(DESTDIR)$(MANDIR) mkdir -p $(DESTDIR)$(MANDIR)/man1
cp $(MANS) $(DESTDIR)$(MANDIR) cp $(MAN1S) $(DESTDIR)$(MANDIR)/man1
uninstall: uninstall:
rm $(DESTDIR)$(BINDIR)/sshwot-export-known-hosts $(DESTDIR)$(BINDIR)/sshwot-filter $(DESTDIR)$(BINDIR)/sshwot-verify rm $(DESTDIR)$(BINDIR)/sshwot-export-known-hosts $(DESTDIR)$(BINDIR)/sshwot-filter $(DESTDIR)$(BINDIR)/sshwot-verify
rm $(DESTDIR)$(MANDIR)/sshwot-verify.1 rm $(DESTDIR)$(MANDIR)/man1/sshwot-verify.1
clean: clean:
rm -rf build $(BINS) rm -rf build $(BINS)

View File

@ -9,7 +9,7 @@
.Op Fl p , Fl -port Ar port .Op Fl p , Fl -port Ar port
.Ar host .Ar host
.Ar fingerprint .Ar fingerprint
.Op Ar sshwot-file Op Ar sshwot-file .... .Op Ar sshwot-file...
.Sh DESCRIPTION .Sh DESCRIPTION
.Nm .Nm
searches through either the given sshwot files or the files located in the searches through either the given sshwot files or the files located in the
@ -25,8 +25,7 @@ finds a matching host and a matching fingerprint, it prints
.Dc .Dc
followed by the file name (without the followed by the file name (without the
.Li .sshwot .Li .sshwot
extension), the host and the comment that was given to that host and fingerprint extension), the host and the corresponding comment.
combination in that file.
.Pp .Pp
If it finds a matching host, but the fingerprint doesn't match, it prints If it finds a matching host, but the fingerprint doesn't match, it prints
.Do .Do
@ -42,22 +41,29 @@ will print
.Li [same fingerprint] .Li [same fingerprint]
.Dc .Dc
followed by the same fields as before. However, since the hostnames are stored followed by the same fields as before. However, since the hostnames are stored
hashed, it can't know what the hostname was here, and so it prints hashed, it can't know what the hostname was here. Due to that it prints
.Do .Do
.Li (unknown host) .Li (unknown host)
.Dc .Dc
in its place. in its place.
.Pp .Pp
The reasoning for not printing these in case there is a full The reason why the
match in the file is that these are mainly useful when some other host is .Do
impersonating the host you are trying to reach or if the host has several .Li [same fingerprint]
different domains and you are trying to verify one that is not in the sshwot .Dc
files. In the first case, since the given host and fingerprint combination is message is not printed if there is a full match in the same file is twofold.
verified in the same file, there is no danger of that. In the second case, this Firstly, there are only two cases where the information is useful. One is if
information is likewise useless, since the file did in fact contain the given some other host is impersonating the host you are trying to reach, and other is
domain. In addition to that, it for hosts that have several domains it is quite if the host has several different domains and you are trying to verify one that
common for them all to be in the same sshwot file, so unconditionally printing is not in the sshwot files. Latter is only useful if the host was not found, and
them out would make the output contain useless noise in normal use cases. if there is a full match for the host and the fingerprint, there is no danger of
another server impersonating it. Secondly, it is quite common to have several
domains resolving into one host in the same sshwot file. If the
.Do
.Li [same fingerprint]
.Dc
messages were printed unconditionally, the output would have a lot of useless
information.
.Pp .Pp
.Nm .Nm
can only handle fingerprints in the SHA256 format, which begins with can only handle fingerprints in the SHA256 format, which begins with
@ -81,14 +87,18 @@ file of OpenSSH.
returns the code 0 if at least one match was found and there were no matching returns the code 0 if at least one match was found and there were no matching
hosts with different fingerprint. A non-zero exit code is returned otherwise. hosts with different fingerprint. A non-zero exit code is returned otherwise.
.Sh EXAMPLES .Sh EXAMPLES
.Li sshwot-verify example.com SHA256:Q9E3qf0ypXqIUGUhhKIDxNnZkUIIwXuDfsaK4vLI55U .Bd -literal
sshwot-verify example.com SHA256:Q9E3qf0ypXqIUGUhhKIDxNnZkUIIwXuDfsaK4vLI55U
.Ed
.Pp .Pp
Checks the fingerprint for the host Checks the fingerprint for the host
.Li example.com .Li example.com
against the files stored in against the files stored in
.Pa ~/.sshwot .Pa ~/.sshwot
.Pp .Pp
.Li sshwot-verify -p 443 secret.example.com SHA256:ZCHE6V++5H/pOeZVjMBF9+9R8ayVDS7IpSa3SpptQDY example.com-keys.sshwot .Bd -literal
sshwot-verify -p 443 secret.example.com SHA256:ZCHE6V++5H/pOeZVjMBF9+9R8ayVDS7IpSa3SpptQDY example.com-keys.sshwot
.Ed
.Pp .Pp
Checks the fingerprint for the sshd running at port 443 on Checks the fingerprint for the sshd running at port 443 on
.Li example.com .Li example.com