# sudo_logsrvd(8) - man - phpman

[SUDO_LOGSRVD(8)](https://www.chedong.com/phpMan.php/man/SUDOLOGSRVD/8/markdown)           BSD System Manager's Manual          [SUDO_LOGSRVD(8)](https://www.chedong.com/phpMan.php/man/SUDOLOGSRVD/8/markdown)

## NAME
     **sudo**___**logsrvd** — sudo event and I/O log server

## SYNOPSIS
     **sudo**___**logsrvd** [**-hnV**] [**-f** _file_] [**-R** _percentage_]

## DESCRIPTION
     **sudo**___**logsrvd** is a high-performance log server that accepts event and I/O logs from **sudo**.  It
     can be used to implement centralized logging of **sudo** logs.  The server has two modes of opera‐
     tion: local and relay.  By default, **sudo**___**logsrvd** stores the logs locally but it can also be
     configured to relay them to another server that supports the [sudo_logsrv.proto(5)](https://www.chedong.com/phpMan.php/man/sudologsrv.proto/5/markdown) protocol.

     When not relaying, event log entries may be logged either via [syslog(3)](https://www.chedong.com/phpMan.php/man/syslog/3/markdown) or to a local file.
     I/O Logs stored locally by **sudo**___**logsrvd** can be replayed via the [sudoreplay(8)](https://www.chedong.com/phpMan.php/man/sudoreplay/8/markdown) utility in the
     same way as logs generated directly by the **sudoers** plugin.

     The server also supports restarting interrupted log transfers.  To distinguish completed I/O
     logs from incomplete ones, the I/O log timing file is set to be read-only when the log is com‐
     plete.

     Configuration parameters for **sudo**___**logsrvd** may be specified in the [sudo_logsrvd.conf(5)](https://www.chedong.com/phpMan.php/man/sudologsrvd.conf/5/markdown) file or
     the file specified via the **-f** option.

     **sudo**___**logsrvd** rereads its configuration file when it receives SIGHUP and writes server state to
     the debug file (if one is configured) when it receives SIGUSR1.

     The options are as follows:

### -f --file
                 Read configuration from _file_ instead of the default, _/etc/sudo_logsrvd.conf_.

### -h --help

### -n --no-fork
                 Run **sudo**___**logsrvd** in the foreground instead of detaching from the terminal and be‐
                 coming a daemon.

### -R --random-drop
                 For each message, there is a _percentage_ chance that the server will drop the con‐
                 nection.  This is only intended for debugging the ability of a client to restart a
                 connection.

### -V --version
                 Print the **sudo**___**logsrvd** version and exit.

### Securing server connections
     The I/O log data sent to **sudo**___**logsrvd** may contain sensitive information such as passwords and
     should be secured using Transport Layer Security (TLS).  Doing so requires having a signed cer‐
     tificate on the server and, if _tls_checkpeer_ is enabled in [sudo_logsrvd.conf(5)](https://www.chedong.com/phpMan.php/man/sudologsrvd.conf/5/markdown), a signed cer‐
     tificate on the client as well.

     The certificates can either be signed by a well-known Certificate Authority (CA), or a private
     CA can be used.  Instructions for creating a private CA are included below in the _EXAMPLES_ sec‐
     tion.

   **Debugging** **sudo**___**logsrvd**
     **sudo**___**logsrvd** supports a flexible debugging framework that is configured via Debug lines in the
     [sudo.conf(5)](https://www.chedong.com/phpMan.php/man/sudo.conf/5/markdown) file.

     For more information on configuring [sudo.conf(5)](https://www.chedong.com/phpMan.php/man/sudo.conf/5/markdown), please refer to its manual.

## FILES
     /etc/sudo.conf            Sudo front-end configuration

     /etc/sudo_logsrvd.conf    Sudo log server configuration file

     /var/log/sudo_logsrvd/incoming
                               Directory where new journals are stored when the _store_first_ _relay_
                               setting is enabled.

     /var/log/sudo_logsrvd/outgoing
                               Directory where completed journals are stored when the _store_first_
                               _relay_ setting is enabled.

     /var/log/sudo-io          Default I/O log file location

     /run/sudo/sudo_logsrvd.pid
                               Process ID file for **sudo**___**logsrvd**

## EXAMPLES
### Creating self-signed certificates
     Unless you are using certificates signed by a well-known Certificate Authority (or a local en‐
     terprise CA), you will need to create your own CA that can sign the certificates used by
     **sudo**___**logsrvd**, **sudo**___**sendlog**, and the **sudoers** plugin.  The following steps use the [openssl(1)](https://www.chedong.com/phpMan.php/man/openssl/1/markdown)
     command to create keys and certificates.

### Initial setup
     First, we need to create a directory structure to store the files for the CA.  We'll create a
     new directory hierarchy in _/etc/ssl/sudo_ for this purpose.

           # mkdir /etc/ssl/sudo
           # cd /etc/ssl/sudo
           # mkdir certs csr newcerts private
           # chmod 700 private
           # touch index.txt
           # echo 1000 > serial

     The serial and index.txt files are used to keep track of signed certificates.

     Next, we need to make a copy of the openssl.conf file and customize it for our new CA.  The
     path to openssl.cnf is system-dependent but _/etc/ssl/openssl.cnf_ is the most common location.
     You will need to adjust the example below if it has a different location on your system.

           # cp /etc/ssl/openssl.cnf .

     Now edit the _openssl.cnf_ file in the current directory and make sure it contains “ca” and
     “CA_default” sections.  Those sections should include the following settings:

           [ ca ]
           default_ca      = CA_default

           [ CA_default ]
           dir             = /etc/ssl/sudo
           certs           = $dir/certs
           database        = $dir/index.txt
           certificate     = $dir/cacert.pem
           serial          = $dir/serial

     If your _openssl.conf_ file already has a “CA_default” section, you may only need to modify the
     “dir” setting.

### Creating the CA key and certificate
     In order to create and sign our own certificates, we need to create a private key and a cer‐
     tificate for the root of the CA.  First, create the private key and protect it with a pass
     phrase:

           # openssl genrsa -aes256 -out private/cakey.pem 4096
           # chmod 400 private/cakey.pem

     Next, generate the root certificate, using appropriate values for the site-specific fields:

           # openssl req -config openssl.cnf -key private/cakey.pem \
               -new -x509 -days 7300 -sha256 -extensions v3_ca \
               -out cacert.pem

           Enter pass phrase for private/cakey.pem:
           You are about to be asked to enter information that will be
           incorporated into your certificate request.
           What you are about to enter is what is called a Distinguished Name
           or a DN.
           There are quite a few fields but you can leave some blank.
           For some fields there will be a default value,
           If you enter '.', the field will be left blank.
           -----
           Country Name (2 letter code) [AU]:US
           State or Province Name (full name) [Some-State]:Colorado
           Locality Name (eg, city) []:
           Organization Name (eg, company) [Internet Widgits Pty Ltd]:sudo
           Organizational Unit Name (eg, section) []:sudo Certificate Authority
           Common Name (e.g., server FQDN or YOUR name) []:sudo Root CA
           Email Address []:

           # chmod 444 cacert.pem

     Finally, verify the root certificate:

           # openssl x509 -noout -text -in cacert.pem

### Creating and signing certificates
     The server and client certificates will be signed by the previously created root CA.  Usually,
     the root CA is not used to sign server/client certificates directly.  Instead, intermediate
     certificates are created and signed with the root CA and the intermediate certs are used to
     sign CSRs (Certificate Signing Request).  In this example we'll skip this part for simplicity's
     sake and sign the CSRs with the root CA.

     First, generate the private key without a pass phrase.

           # openssl genrsa -out private/logsrvd_key.pem 2048
           # chmod 400 private/logsrvd_key.pem

     Next, create a certificate signing request (CSR) for the server's certificate.  The organiza‐
     tion name must match the name given in the root certificate.  The common name should be either
     the server's IP address or a fully qualified domain name.

           # openssl req -config openssl.cnf -key private/logsrvd_key.pem -new \
               -sha256 -out csr/logsrvd_csr.pem

           Enter pass phrase for private/logsrvd_key.pem:
           You are about to be asked to enter information that will be
           incorporated into your certificate request.
           What you are about to enter is what is called a Distinguished Name
           or a DN.
           There are quite a few fields but you can leave some blank.
           For some fields there will be a default value,
           If you enter '.', the field will be left blank.
           -----
           Country Name (2 letter code) [AU]:US
           State or Province Name (full name) [Some-State]:Colorado
           Locality Name (eg, city) []:
           Organization Name (eg, company) [Internet Widgits Pty Ltd]:sudo
           Organizational Unit Name (eg, section) []:sudo log server
           Common Name (e.g., server FQDN or YOUR name) []:logserver.example.com
           Email Address []:

           Please enter the following 'extra' attributes
           to be sent with your certificate request
           A challenge password []:
           An optional company name []:

     Now sign the CSR that was just created:

           # openssl ca -config openssl.cnf -days 375 -notext -md sha256 \
               -in csr/logsrvd_csr.pem -out certs/logsrvd_cert.pem

           Using configuration from openssl.cnf
           Enter pass phrase for ./private/cakey.pem:
           Check that the request matches the signature
           Signature ok
           Certificate Details:
                   Serial Number: 4096 (0x1000)
                   Validity
                       Not Before: Nov 11 14:05:05 2019 GMT
                       Not After : Nov 20 14:05:05 2020 GMT
                   Subject:
                       countryName               = US
                       stateOrProvinceName       = Colorado
                       organizationName          = sudo
                       organizationalUnitName    = sudo log server
                       commonName                = logserve.example.com
                   X509v3 extensions:
                       X509v3 Basic Constraints:
                           CA:FALSE
                       Netscape Comment:
                           OpenSSL Generated Certificate
                       X509v3 Subject Key Identifier:
                           4C:50:F9:D0:BE:1A:4C:B2:AC:90:76:56:C7:9E:16:AE:E6:9E:E5:B5
                       X509v3 Authority Key Identifier:
                           keyid:D7:91:24:16:B1:03:06:65:1A:7A:6E:CF:51:E9:5C:CB:7A:95:3E:0C

           Certificate is to be certified until Nov 20 14:05:05 2020 GMT (375 days)
           Sign the certificate? [y/n]:y

           1 out of 1 certificate requests certified, commit? [y/n]y
           Write out database with 1 new entries
           Data Base Updated

     Finally, verify the new certificate:

           # openssl verify -CAfile cacert.pem certs/logsrvd_cert.pem
           certs/logsrvd_cert.pem: OK

     The _/etc/ssl/sudo/certs_ directory now contains a signed and verified certificate for use with
     **sudo**___**logsrvd**.

     To generate a client certificate, repeat the process above using a different file name.

   **Configuring** **sudo**___**logsrvd** **to** **use** **TLS**
     To use TLS for client/server communication, both **sudo**___**logsrvd** and the **sudoers** plugin need to be
     configured to use TLS.  Configuring **sudo**___**logsrvd** for TLS requires the following settings, as‐
     suming the same path names used earlier:

           # Listen on port 30344 for TLS connections to any address.
           listen_address = *:30344(tls)

           # Path to the certificate authority bundle file in PEM format.
           tls_cacert = /etc/ssl/sudo/cacert.pem

           # Path to the server's certificate file in PEM format.
           tls_cert = /etc/ssl/sudo/certs/logsrvd_cert.pem

           # Path to the server's private key file in PEM format.
           tls_key = /etc/ssl/sudo/private/logsrvd_key.pem

     The root CA cert (_cacert.pem_) must be installed on the system running **sudo**___**logsrvd**.  If peer
     authentication is enabled on the client, a copy of _cacert.pem_ must be present on the client
     system too.

## SEE ALSO
     [sudo.conf(5)](https://www.chedong.com/phpMan.php/man/sudo.conf/5/markdown), [sudo_logsrvd.conf(5)](https://www.chedong.com/phpMan.php/man/sudologsrvd.conf/5/markdown), [sudoers(5)](https://www.chedong.com/phpMan.php/man/sudoers/5/markdown), [sudo(8)](https://www.chedong.com/phpMan.php/man/sudo/8/markdown), [sudo_sendlog(8)](https://www.chedong.com/phpMan.php/man/sudosendlog/8/markdown), [sudoreplay(8)](https://www.chedong.com/phpMan.php/man/sudoreplay/8/markdown)

## AUTHORS
     Many people have worked on **sudo** over the years; this version consists of code written primarily
     by:

           Todd C. Miller

     See the CONTRIBUTORS file in the **sudo** distribution (<https://www.sudo.ws/contributors.html>) for
     an exhaustive list of people who have contributed to **sudo**.

## BUGS
     If you feel you have found a bug in **sudo**___**logsrvd**, please submit a bug report at
     <https://bugzilla.sudo.ws/>

## SUPPORT
     Limited free support is available via the sudo-users mailing list, see
     <https://www.sudo.ws/mailman/listinfo/sudo-users> to subscribe or search the archives.

## DISCLAIMER
     **sudo**___**logsrvd** is provided “AS IS” and any express or implied warranties, including, but not lim‐
     ited to, the implied warranties of merchantability and fitness for a particular purpose are
     disclaimed.  See the LICENSE file distributed with **sudo** or <https://www.sudo.ws/license.html> for
     complete details.

## Sudo 1.9.9                    September 17, 2021                    Sudo 1.9.9
