maybe a definition renders nicer
This commit is contained in:
parent
c2447eab80
commit
4f65a3a136
@ -40,17 +40,15 @@ can secure those with DNSSEC.
|
|||||||
* VerifyHostKeyDNS
|
* VerifyHostKeyDNS
|
||||||
[[https://man.openbsd.org/ssh_config.5#VerifyHostKeyDNS][ssh_config(5)]] explains how [[https://man.openbsd.org/ssh.1][ssh(1)]] can use SSHFP records to verify
|
[[https://man.openbsd.org/ssh_config.5#VerifyHostKeyDNS][ssh_config(5)]] explains how [[https://man.openbsd.org/ssh.1][ssh(1)]] can use SSHFP records to verify
|
||||||
host-keys:
|
host-keys:
|
||||||
#+begin_example
|
|
||||||
VerifyHostKeyDNS
|
+ VerifyHostKeyDNS :: Specifies whether to verify the remote key using
|
||||||
Specifies whether to verify the remote key using DNS and SSHFP
|
DNS and SSHFP resource records. If this option is set to yes, the
|
||||||
resource records. If this option is set to yes, the client will
|
client will implicitly trust keys that match a secure fingerprint
|
||||||
implicitly trust keys that match a secure fingerprint from DNS.
|
from DNS. Insecure fingerprints will be handled as if this option
|
||||||
Insecure fingerprints will be handled as if this option was set
|
was set to ask. If this option is set to ask, information on
|
||||||
to ask. If this option is set to ask, information on fingerprint
|
fingerprint match will be displayed, but the user will still need to
|
||||||
match will be displayed, but the user will still need to confirm
|
confirm new host keys according to the StrictHostKeyChecking option.
|
||||||
new host keys according to the StrictHostKeyChecking option. The
|
The default is no.
|
||||||
default is no.
|
|
||||||
#+end_example
|
|
||||||
|
|
||||||
One problem with this is, if you put
|
One problem with this is, if you put
|
||||||
#+begin_example
|
#+begin_example
|
||||||
@ -71,18 +69,16 @@ does not know that it can trust the validating name-server. One way to
|
|||||||
have a trustworthy validating name-server is to run one on localhost.
|
have a trustworthy validating name-server is to run one on localhost.
|
||||||
|
|
||||||
[[http://man.openbsd.org/resolv.conf#trust-ad][resolv.conf(5)]] explains the *trust-ad* option:
|
[[http://man.openbsd.org/resolv.conf#trust-ad][resolv.conf(5)]] explains the *trust-ad* option:
|
||||||
#+begin_example
|
|
||||||
trust-ad A name server indicating that it performed DNSSEC
|
+ trust-ad :: A name server indicating that it performed DNSSEC
|
||||||
validation by setting the Authentic Data (AD) flag
|
validation by setting the Authentic Data (AD) flag in the answer can
|
||||||
in the answer can only be trusted if the name
|
only be trusted if the name server itself is trusted and the network
|
||||||
server itself is trusted and the network path is
|
path is trusted. Generally this is not the case and the AD flag is
|
||||||
trusted. Generally this is not the case and the
|
cleared in the answer. The trust-ad option lets the system
|
||||||
AD flag is cleared in the answer. The trust-ad
|
administrator indicate that the name server and the network path are
|
||||||
option lets the system administrator indicate that
|
trusted. This option is automatically enabled if resolv.conf only
|
||||||
the name server and the network path are trusted.
|
lists name servers on localhost.
|
||||||
This option is automatically enabled if
|
|
||||||
resolv.conf only lists name servers on localhost.
|
|
||||||
#+end_example
|
|
||||||
The easiest way is to run [[https://man.openbsd.org/unwind.8][unwind(8)]]. [[https://man.openbsd.org/resolvd.8][resolvd(8)]] will then add
|
The easiest way is to run [[https://man.openbsd.org/unwind.8][unwind(8)]]. [[https://man.openbsd.org/resolvd.8][resolvd(8)]] will then add
|
||||||
=nameserver 127.0.0.1= into =/etc/resolv.conf= and comment out all
|
=nameserver 127.0.0.1= into =/etc/resolv.conf= and comment out all
|
||||||
other dynamically learned name servers. Just make sure that you are
|
other dynamically learned name servers. Just make sure that you are
|
||||||
|
Loading…
Reference in New Issue
Block a user