aboutsummaryrefslogtreecommitdiff
path: root/content/blog/2022-03-26-ssh-mfa.org
blob: 0e80170391279dd2bfcb6cb49d6f31bda1ccb65e (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
#+date:        <2022-03-26 Sat 00:00:00>
#+title:       Secure Your SSH Access: Deploying Time-Based One-Time Password Authentication
#+description: Step-by-step deployment guide for enabling TOTP multi-factor authentication on SSH services using Google Authenticator and Pluggable Authentication Module (PAM) integration.
#+slug:        ssh-mfa
#+filetags:    :ssh:mfa:security:

* Why Do I Need MFA for SSH?

If you are a sysadmin of a server anywhere (that includes at home!), you
may want an added layer of protection against intruders. This is not a
replacement for other security measures, such as:

- Disable root SSH
- Disable SSH password authentication
- Allow only certain users to login via SSH
- Allow SSH only from certain IPs

However, MFA can be added as an additional security measure to ensure
that your server is protected. This is especially important if you need
to allow password authentication for SSH.

For more guidance on server security measures, see my other post:
[[../hardening-a-public-facing-home-server/][Hardening a Public-Facing
Home Server]].

* Install MFA PAM Module

PAM, which stands for Pluggable Authentication Module, is an
authentication infrastructure used on Linux systems to authenticate a
user. In order to use this technology, let's install the
=libpam-google-authenticator= package:

#+begin_src sh
sudo apt-get update
#+end_src

#+begin_src sh
sudo apt-get install libpam-google-authenticator
#+end_src

* Initialize the PAM Module

** Interactive Method

Once the package is installed, initialize it and following the
interactive prompts to generate your OTP or TOTP:

#+begin_src sh
google-authenticator
#+end_src

If you are not sure how to answer, read the prompts carefully and think
about having to how each situation would affect your normal login
attempts. If you are still not sure, use my default responses below.

#+begin_src txt
OUTPUT

Do you want authentication tokens to be time-based (y/n) y
#+end_src

At this point, use an authenticator app somewhere one of your devices to
scan the QR code. Any future login attempts after our upcoming
configuration changes will require that TOTP.

#+begin_src txt
OUTPUT

Do you want me to update your "/home/user/.google_authenticator" file? (y/n) y
#+end_src

#+begin_src txt
OUTPUT

Do you want to disallow multiple uses of the same authentication
token? This restricts you to one login about every 30s, but it increases
your chances to notice or even prevent man-in-the-middle attacks (y/n) y
#+end_src

#+begin_src txt
OUTPUT

By default, a new token is generated every 30 seconds by the mobile app.
In order to compensate for possible time-skew between the client and the server,
we allow an extra token before and after the current time. This allows for a
time skew of up to 30 seconds between authentication server and client. If you
experience problems with poor time synchronization, you can increase the window
from its default size of 3 permitted codes (one previous code, the current
code, the next code) to 17 permitted codes (the 8 previous codes, the current
code, and the 8 next codes). This will permit for a time skew of up to 4 minutes
between client and server.
Do you want to do so? (y/n) n
#+end_src

#+begin_src txt
OUTPUT

If the computer that you are logging into isn't hardened against brute-force
login attempts, you can enable rate-limiting for the authentication module.
By default, this limits attackers to no more than 3 login attempts every 30s.
Do you want to enable rate-limiting? (y/n) y
#+end_src

** Non-Interactive Method

If you need to do this quickly, know your responses to the prompts, or
are setting this up for numerous users, the non-interactive method can
be much faster:

#+begin_src sh
google-authenticator -t -d -f -r 3 -R 30 -w 3
#+end_src

The options referenced above are as follows:

#+begin_src txt
google-authenticator [<options>]
 -h, --help                     Print this message
 -c, --counter-based            Set up counter-based (HOTP) verification
 -t, --time-based               Set up time-based (TOTP) verification
 -d, --disallow-reuse           Disallow reuse of previously used TOTP tokens
 -D, --allow-reuse              Allow reuse of previously used TOTP tokens
 -f, --force                    Write file without first confirming with user
 -l, --label=<label>            Override the default label in "otpauth://" URL
 -i, --issuer=<issuer>          Override the default issuer in "otpauth://" URL
 -q, --quiet                    Quiet mode
 -Q, --qr-mode={NONE,ANSI,UTF8} QRCode output mode
 -r, --rate-limit=N             Limit logins to N per every M seconds
 -R, --rate-time=M              Limit logins to N per every M seconds
 -u, --no-rate-limit            Disable rate-limiting
 -s, --secret=<file>            Specify a non-standard file location
 -S, --step-size=S              Set interval between token refreshes
 -w, --window-size=W            Set window of concurrently valid codes
 -W, --minimal-window           Disable window of concurrently valid codes
 -e, --emergency-codes=N        Number of emergency codes to generate
#+end_src

This fully configures the authenticator, saves it to a file, and then
outputs the secret key, QR code, and recovery codes. (If you add the
flag =-q=, then there won't be any output). If you use this command in
an automated fashion, make sure your script captures the secret key
and/or recovery codes and makes them available to the user.

* PAM Configuration Settings

Once you've enabled the T/OTP and have it saved to an MFA app on your
phone or other device, open the PAM =sshd= file:

#+begin_src sh
sudo nano /etc/pam.d/sshd
#+end_src

You need to do two things in this file. First, add the following lines
to the bottom of the file:

#+begin_src config
auth required pam_google_authenticator.so nullok
auth required pam_permit.so
#+end_src

Second, comment-out the following line near the top of the file.

If you leave this line uncommented, every SSH login attempt will ask for
the following three authentication factors:

1. Publickey
2. Password
3. T/OTP code

#+begin_src config
#@include common-auth
#+end_src

* SSH Configuration Settings

Finally, edit the =sshd_config= file again:

#+begin_src sh
sudo nano /etc/ssh/sshd_config
#+end_src

You'll need to change =ChallengeResponseAuthentication= to yes and add
the =AuthenticationMethods= line to the bottom of the file.

#+begin_src config
ChallengeResponseAuthentication yes
AuthenticationMethods publickey,password publickey,keyboard-interactive
#+end_src

Finally, restart the =ssh= service:

#+begin_src sh
sudo systemctl restart sshd.service
#+end_src

The next time you log in, you should be greeted with a verification code
request!