cert-validation
This element defines public-key infrastructure (PKI) settings
used for validating remote server authentication certificates. The
element can have three attributes: end-point-identity-check,
default-domain, http-proxy-url, and
socks-server-url.
The end-point-identity-check attribute specifies
whether the client will verify the server's hostname against the
Subject Name or Subject Alternative Name (DNS Address) in the
server's certificate. If set to no, the fields in the
server host certificate are not verified and the certificate is
accepted based on validity period and CRL check only. Note that
this is a possible security risk, as anyone with a certificate
issued by the same trusted CA that issues the server host
certificates can perform a man-in-the-middle attack on the server if
a client has the end-point identity check disabled. The default
value is yes.
The default-domain attribute can be used when the
end-point identity check is enabled. It specifies the default domain
part of the remote system name and it is used if only the base part of
the system name is available. The default-domain is
appended to the system name if it does not contain a dot
(.).
If the default domain is not specified, the end-point
identity check fails, for example, when a user tries to connect to a
host "rock" giving only the short hostname and the
certificate contains the full DNS address
"rock.example.com".
The http-proxy-url attribute defines a HTTP proxy
and the socks-server-url attribute defines a SOCKS
proxy for making LDAP or OCSP queries for certificate validity.
The address of the proxy is given as the value of the
attribute. The format of the address with a SOCKS proxy is:
socks://user@socks_srv:port/network/netmask,network/netmask ...
The format of the address with an HTTP proxy is:
http://user@proxy_srv:port/network/netmask,network/netmask ...
For example, by setting socks-server-url to
"socks://user@fw.ssh.com:1080/192.196.0.0/16,10.100.23.0/24"
the host fw.ssh.com and port 1080
are used as your SOCKS server for connections outside of
networks 192.196.0.0 (16-bit domain) and
10.100.23.0 (8-bit domain). Those networks are
connected directly.
The cert-validation element can contain multiple
ldap-server and ocsp-responder elements, a
dod-pki element, and multiple ca-certificate
elements.
- ldap-server
This element specifies an LDAP server address and
port used for fetching CRLs and/or subordinate CA
certificates based on the issuer name of the certificate being
validated. Several LDAP servers can be specified by using
several ldap-server elements.
CRLs are automatically retrieved from the CRL distribution
point defined in the certificate to be verified if the point
exists.
The default value for port is 389.
- ocsp-responder
This element specifies an OCSP (Online Certificate Status
Protocol) responder service address in URL format
(url). Several OCSP responders can be specified by
using several ocsp-responder elements.
If the certificate has a valid Authority Info Access extension with an OCSP Responder URL, it will be used
instead of this setting. Note that for the OCSP validation to
succeed, both the end-entity certificate and the OCSP Responder
certificate must be issued by the same CA.
The validity-period (in seconds) can be
optionally defined. During this time, new OCSP queries for the same
certificate are not made but the old result is used. The default
validity period is 0 (a new query is made every time).
- dod-pki
This element defines whether the certificates are required to
be compliant with the DoD PKI (US Department of Defense Public-Key
Infrastructure). In practise, this means that the Digital
Signature bit must be set in the Key Usage of the certificate. The
enable attribute can have a value of yes
or no. The default is no.
- ca-certificate
This element defines a CA used in server authentication.
It can have four attributes: name, file,
disable-crls, and use-expired-crls.
The name attribute must contain the name of the CA.
The element must either contain the path to the X.509 CA
certificate file as a value of the file
attribute, or include the certificate as a base64-encoded
ASCII block.
CRL checking can be disabled by setting the
disable-crls attribute to yes. The default
is no.
Expired CRLs can be used by setting a numeric value (in
seconds) for the use-expired-crls attribute. The
default is 0 (do not use expired CRLs).
An example of a certificate validation configuration is shown below:
<cert-validation end-point-identity-check="yes"
default-domain="example.com"
http-proxy-url="http://proxy.example.com:8080">
<ldap-server address="ldap://ldap.example.com:389" />
<ocsp-responder url="http://ocsp.example.com:8090" validity-period="0" />
<dod-pki enable="no" />
<ca-certificate name="ssh_ca1"
file="ssh_ca1.crt"
disable-crls="no"
use-expired-crls="100" />
</cert-validation>
|
strict-host-key-checking
This element enables strict host key checking. If it is enabled,
the SOCKS Proxy never adds host keys to the user's
.ssh2/hostkeys directory upon connection, and refuses to
connect to hosts whose key has changed. This provides maximum
protection against man-in-the-middle attacks. However, it can be
somewhat annoying if you frequently connect to new hosts.
The word yes or no is given as the
value of the enable attribute. The default is
no (the user is asked whether to accept a new or changed
host key).
Strict host key checking will be used, if it is so specified
in either the global or the user configuration file (or both).
<strict-host-key-checking enable="yes" />
|
accept-unknown-host-keys This element defines whether the SOCKS Proxy will always accept the
proposed host key without saving the key. It is the equivalent of
automatically answering "Once" to all accept-host-key
prompts.
The word yes or no is given as the
value of the enable attribute. The default is
no (unknown host keys are not automatically accepted).
If this element is set to no either in the global or
the user configuration file, the changed or new host keys are prompted
normally. Additionally, setting this element to yes takes
effect only when both strict-host-key-checking and
host-key-always-ask are set to no (or are not
explicitly defined).
<accept-unknown-host-keys enable="no" />
|
Note: When transparent tunneling is used, accepting the host
key cannot be prompted from the user. Either this setting must be set to
yes (not recommended) or the host keys of the Secure Shell
tunneling servers must be obtained beforehand and stored based on the IP
addresses of the servers, for example, by using the key distribution tool.
See Section Fetching Remote Server Keys.
Caution: Consider carefully before enabling this option.
Disabling the host-key checks can make you vulnerable to a
man-in-the-middle attack.
