To make a QR code, you need a URL formatted string, as below. Last login: Wed Jul 10 22:38:53 2013 from set up the Google Authenticator smartphone app, you can take your Base32 formatted secret, and either enter it manually or generate a QR code. Log in quickly (before that token expires), and you should find it lets you in: ssh securehost You can generate your OTP using oathtool: # oathtool -totp 15ad027b56c81672214f4659ffb432 Now you can ssh into your server (don't close the root session you currently have open in case you've broken something!). auth pam_access.so accessfile=/etc/security/nfĪuth required pam_oath.so usersfile=/etc/users.oath window=30 The pam_access entry is optional, but it does make the above choices possible. You can be quite creative with these rules - they follow the standard pam_access syntax, so check the documentation for that.įinally, I added the following lines to /etc/pam.d/system-auth-ac and /etc/pam.d/password-auth-ac (This is a RHEL/CentOS-ism) - where you put them will depend on your pam configuration and OS. This might be useful to selectively 2FA enable user accounts as part of a gradual rollout, or you might decide to only require 2FA for users who have permission to su to root. This configuration only requires OTP for members of the 'otpusers' unix group. This configuration would allow access without requiring an OTP from a trusted network: + : ALL : 192.168.0.0/24 Since you probably don't want OTP enabled all the time for all users, create /etc/security/nf - you can set differing options depending on your requirements. You can type this in, or generate a QR code later. The Base32 version of the secret is the one that you will need for the Google Authenticator smartphone app. Run this with the -v option and your chosen key. You should also secure that file appropriately, as these strings are effectively a password: # chmod 600 /etc/users.oath You can add as many users as you need, one line at a time. A good way to generate a random string of an appropriate size and format: # head -10 /dev/urandom | md5sum | cut -b 1-30 If you're using a software token, you'll want to generate a random seed. # ln -s /usr/lib64/security/pam_oath.so /lib64/security/pam_oath.soĮnable ChallengeResponse auth in /etc/ssh/sshd_config: ChallengeResponseAuthentication yes Install the relevant packages, and symlink the pam_oath module into the right place: # yum install pam_oath oathtool You should leave a session logged in as root while you test this, in case you break anything and need to undo it. pam_oath (and its documentation) is available directly or it might be provided by your OS distribution, if you're not using RHEL/CentOS. These instructions are for RHEL/CentOS 6, and you'll need the EPEL repo for the oath packages (or install the packages and their dependencies directly). Setting up a simple trial to add 2FA to a remote access server using Google Authenticator as a software token, I thought it would be useful to document the bits that I glued together. OATH is an open mechanism for generating either event-based or time-based One Time Passwords and there are a number of hardware tokens and software implementations available, which makes it ideal for a small scale implementation without requiring lots of infrastructure or expense. Two-factor authentication (2FA) is becoming an increasingly useful way of providing an extra layer of security to services above and beyond passwords. Two-factor time based (TOTP) SSH authentication with pam_oath and Google Authenticator
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |