diff options
| author | Sam Chudnick <sam@chudnick.com> | 2023-06-10 13:04:24 -0400 |
|---|---|---|
| committer | Sam Chudnick <sam@chudnick.com> | 2023-06-10 13:04:24 -0400 |
| commit | ef2c74ad8806a47efc9d39b7437ff40b87c65103 (patch) | |
| tree | e0d2e6eb55301dc5bb21c3e7cb79386688dd46bb /projects/template.html | |
| parent | fa8fe10e13f15530338037158a04b728a4ef47cf (diff) | |
Several updates
Diffstat (limited to 'projects/template.html')
| -rw-r--r-- | projects/template.html | 107 |
1 files changed, 0 insertions, 107 deletions
diff --git a/projects/template.html b/projects/template.html deleted file mode 100644 index 77b6c6a..0000000 --- a/projects/template.html +++ /dev/null | |||
| @@ -1,107 +0,0 @@ | |||
| 1 | <!DOCTYPE html> | ||
| 2 | <html lang=en> | ||
| 3 | <head> | ||
| 4 | <title></title> | ||
| 5 | <meta charset="utf-8"/> | ||
| 6 | <link rel="shortcut icon" href="favicon.ico"/> | ||
| 7 | <link rel='stylesheet' type='text/css' href='style.css'/> | ||
| 8 | <meta name="viewport" content="width=device-width, initial-scale=1"> | ||
| 9 | </head> | ||
| 10 | <body> | ||
| 11 | <header><h1 class=pagetop>Projects</h1></header> | ||
| 12 | <main> | ||
| 13 | <h2>mfa</h2> | ||
| 14 | <p><em>Check out the source code here - </em> | ||
| 15 | <a href=https://git.chudnick.com/mfa>git.chudnick.com/mfa</a></p> | ||
| 16 | |||
| 17 | <p><strong>mfa</strong> is a system for out-of-band multi-factor authentication with PAM. | ||
| 18 | My original reason for working on this was to get MFA functionality for a Postfix/Dovecot | ||
| 19 | mail server that uses PAM for authentication. Solutions such as pam_oath are not feasible | ||
| 20 | for this purpose because a mail client has no way of exposing an interface for the oath | ||
| 21 | challenge-response. Therefore a way to circumvent the original application to get the request | ||
| 22 | to the user is needed, which is what mfa does.</p> | ||
| 23 | |||
| 24 | <p>The design of mfa is not novel, it works the same way as Cisco's Duo. Duo does have open | ||
| 25 | source modules for achieving this objective, but all the authentication requests are | ||
| 26 | sent back to their proprietary "cloud" service. I'm sure that most free software | ||
| 27 | enthusiasts see this as a major red flag, especially for small personal use cases.</p> | ||
| 28 | |||
| 29 | <h3>Design</h3> | ||
| 30 | |||
| 31 | <p>mfa is primarily composed of three parts - the server, the client, and the PAM module. | ||
| 32 | The server listens for connections from both clients and PAM modules. The server receives a | ||
| 33 | request from a PAM module that includes the username of the user attempting to authenticate, | ||
| 34 | the hostname of the computer, and the service being accessed. The server then correlates the | ||
| 35 | combination of user, host, and service to a particular client, and attempts to push a request. | ||
| 36 | The server will then evaluate the client's response, and either return to the PAM module that | ||
| 37 | the user is authenticated or denied.</p> | ||
| 38 | |||
| 39 | <p>The server itself consists of two parts that I've called <strong>mfad</strong> and | ||
| 40 | <strong>mfac</strong>. mfad is the program responsible for doing what I've described above. | ||
| 41 | mfac is a command line utility that the administrator uses to configure the server. mfac is used | ||
| 42 | to enroll clients in the system and to provision applications. A client is enrolled by using the | ||
| 43 | --add-client option and providing an alias for that user. The server then assigns that user an | ||
| 44 | identifying key that is used to connect and a TOTP secret key. With the client enrolled, the | ||
| 45 | administrator can then assign applications to that client. With the --add-app command, the | ||
| 46 | administrator ties a username, hostname, and service combination to a client alias, so that | ||
| 47 | when that combination is seen the server knows who to ask for authentication. The administrator | ||
| 48 | also identifies which MFA methods are valid for this combination (currently either or both of | ||
| 49 | push and/or totp). The example below shows the process of enrolling a new client called | ||
| 50 | 'tux' and then provisioning MFA for SSH attempts to tux@linux.example.org.</p> | ||
| 51 | |||
| 52 | <pre><code><em># Enroll a client named tux</em> | ||
| 53 | mfac --add-client tux | ||
| 54 | alias: tux | ||
| 55 | client key: VA32LB3SF2HG2FDWJS5XIOFVWTMBQYRSQ3PK3OOPA3FBIQMSMJZCXYJQCYKYUWUU | ||
| 56 | totp secret: TGGG3QCXA4MR2S2X6B33GSYN | ||
| 57 | uri: otpauth://totp/tux%40mfad?secret=TGGG3QCXA4MR2S2X6B33GSYN | ||
| 58 | |||
| 59 | <em># Provision MFA for SSH tux@linux.example.org allowing for both push authentication or TOTP</em> | ||
| 60 | mfac --add-app --user tux --host linux.example.org --service sshd --alias tux --methods push totp | ||
| 61 | </code></pre> | ||
| 62 | |||
| 63 | <p>The PAM module of mfa also consists of two parts: the actual PAM module | ||
| 64 | <strong>pam_mfa.so</strong> that gets called in the PAM stack and a helper | ||
| 65 | program that interacts with mfad. The job of pam_mfa.so is to retrieve the | ||
| 66 | necessary information (user and service) from PAM and then invoke the helper | ||
| 67 | program with that data. It then waits for the MFA process to complete, retrieves | ||
| 68 | the result, and returns either success or failure to the PAM stack. The helper | ||
| 69 | program initiates a connetion to mfad when run and then passes username, hostname, | ||
| 70 | and service information to the server. It too receives a success or failure response | ||
| 71 | and then relays that information to the PAM module. Here is an example of using | ||
| 72 | pam_mfa.so in the PAM stack for sshd.</p> | ||
| 73 | |||
| 74 | <pre><code><strong>/etc/pam.d/sshd</strong> | ||
| 75 | auth requisite pam_mfa.so</code></pre> | ||
| 76 | |||
| 77 | <p>The client program is what the end user interacts with to provide authentication responses. | ||
| 78 | Currently it is only a very simple terminal program but expanding on this is high on the | ||
| 79 | TODO list. The client opens a connection to the server and identifies itself with the client | ||
| 80 | key that was generated during enrollment. The client waits for a prompt from the server, and | ||
| 81 | when it receives one, informs the user. The client receives the users input and sends it back | ||
| 82 | to the server. The client performs this loop continuously until it is closed.</p> | ||
| 83 | |||
| 84 | <h2>clibrary</h2> | ||
| 85 | |||
| 86 | <p><em>Check out the source code here -</em> | ||
| 87 | <a href=https://git.chudnick.com/clibrary>git.chudnick.com/clibrary</a></p> | ||
| 88 | |||
| 89 | <h2>mail-tools</h2> | ||
| 90 | <p> | ||
| 91 | <a href=https://git.chudnick.com/mail-tools>git.chudnick.com/mail-tools</a> | ||
| 92 | </p> | ||
| 93 | |||
| 94 | <h2>deploy-scripts</h2> | ||
| 95 | <p> | ||
| 96 | <a href=https://git.chudnick.com/deploy-scripts>git.chudnick.com/deploy-scripts</a> | ||
| 97 | </p> | ||
| 98 | |||
| 99 | <h2>server-scripts</h2> | ||
| 100 | <p> | ||
| 101 | <a href=https://git.chudnick.com/server-scripts>git.chudnick.com/server-scripts</a> | ||
| 102 | </p> | ||
| 103 | </main> | ||
| 104 | <footer><a href=index.html>www.chudnick.com</a></footer> | ||
| 105 | </body> | ||
| 106 | </html> | ||
| 107 | |||