In this post, I am going to walk you through the process of installing and configuring two- factor SSH authentication via Google Authenticator. My base system is running a fresh install of RHEL 7.2
Installation Steps
The first step on my system was to install autoreconf, automake, and libtool. These packages are required by the bootstrap.sh script that we will need to in a couple more steps.
# yum -y install autoconf automake libtool
Now, we are going to install Git.
#yum -y install git
One more dependency to knock out. Install pam-devel as shown below.
# yum -y install pam-devel
Next, we clone the google-authenticator Git repo. In this example, I am cloning to /root
Setting a server’s hostname used to be as simple as running the ‘hostname’ command and adding a “HOSTNAME” entry in /etc/sysconfig/network. However things have changed quite a bit in RHEL7. Apparently, systemd now controls setting a server’s hostname. The ‘hostname‘ command no longer works to set your hostname, however the command is still available just to confuse you.
Now in RHEL 7 you use the command ‘hostnamectl‘. Below is an example of how it works.
Here I have logged into my a RHEL 7.1 VM. You can see that the system appears to have the hostname of node1.
[root@node1 ~]# hostname
node1
However upon further inspection, I find that this is not the case. Rather, the server has a static hostname of localhost.localdomain.
Unless you have been using Firewalld in the last few releases of Fedora, as some out there have, then you probably could probably use a few pointers to get you started on your way to configuring your Linux firewalls the “new-fangled fancy way”. This is especially the case if you plan on moving to RHEL7 anytime soon — as Firewalld is the default there. So put on your big boy (or girl) pants and say goodbye to your old friend IPTABLES.
“The dynamic firewall daemon firewalld provides a dynamically managed firewall with support for network “zones” to assign a level of trust to a network and its associated connections and interfaces. It has support for IPv4 and IPv6 firewall settings. It supports Ethernet bridges and has a separation of runtime and permanent configuration options. It also has an interface for services or applications to add firewall rules directly”
Wow, how fancy. So how do we use it? Well let’s take a stab at enabling HTTP access to our Fedora21 workstation.
First thing first, lets figure out what our default done is on our workstation.
Ok, thats a bit strange, in RHEL you should expect PUBLIC to be your default zone. Now that we know what zone we need to mess with let’s make sure that its applied to the proper interfaces.
Insync is a very powerful and full featured Google Drive client for Windows, Mac, and Linux. I ran across Insync when I was looking for a Google Drive client for Linux after I kicked Dropbox to the curb and switching over to Google Drive for all my cloud storage needs.
In all honesty, if it wasn’t for the Insync client I do not think that I would have made the switch at all, as Google does not even offer a basic GUI client for Linux. Really Google?
PSA: The integration that Google Drive provides into Google Photos, Google Music, Google Docs, and Gmail is well worth the switch from Dropbox in my opinion, and 1TB for only 9 bucks a month is hard to beat (100GB is only $1.99 a month). Just having a Gmail account gives you access to 15GB of free space… so there is no reason not to give it a try.
Ok now back to the topic at hand.
Note that a personal license of the Insync Google Drive client is not free, rather it costs $15. However you can download and try it risk free and without entering any credit card info. This one time fee for a personal license allows you to run and install Insync on multiple machines. Currently I have it installed on 4 separate Linux workstations/laptops. Its well worth cash.
Installing Insync is very easy and well documented so I am not going to go into that topic here. Rather lets talk about using Insync on Linux.
So first off let me start by saying that I know that there is a ton of information out there on how to get started with Git. Heck, when you create your repo in GitLab it spits these instructions right out in front of your nose. However, what I have found is that most instructions tell you what to do to get started with git, however they do not tell you exactly what you are doing. You end up running a few command and then sit back and try to figure out what you actually just did.
That being said, getting started with Git has been the hardest part of the process, as most of us traditional grey-beard sysadmins are not that familiar with code management. When I was first getting started in technology, there were developers and there were sysadmins, and those two worlds were extremely separate. Now, we as we enter the age of DEVOPS and automation these two worlds are once again colliding (like they did in the beginning, but more on that another day).
In my lab I decided to build a stand alone vm for Git and Puppet. After doing some research – and asking others– on how and what to do to get Git up and running with a nice front end web interface, I decided to get started by installing the GitLab Omnibus package for Centos 6. This process was quick, easy, and painless.
Once I had a working webUI up and running it was time to create my first repo. Instead of trying to accomplish this from my Fedora workstaion, I just clicked on the "New Project" button on the GitLab dashboard and created an empty repo called "General_Scripts".
Back on my Fedora workstation I created a new directory in my home dir called git, and inside that directory I created a directory called "General_Scripts" as I had done in the webUI.
Now it was time to use Git.
First off you need to configure a few global Git options. This only needs to be done once.
Once these global configs are set you can then you can move on to seeding your repo. Here you see my change directories to the Global_Scripts directory and tell Git to initialize this directory as a repo.
#cd Global_Scripts
#git init
Now lets create a file and add it to the repo. Here were are going to create a simple README containing a description of my new repo. The instructions do not tell you that you have to put anything in this initial file, however what good is an empty README anyway
#vi README.md
Now tell git that this file needs to be added to the "General_Scripts" repo that we created a few steps ago.
#git add README.md
Now lets commit that file with a nice little comment. Commit comments should describe what the file we added or what we changed in an existing file
#git commit -m "Added README.md"
Now we need to tell our local git command what remote repo we are going to sync to. Note my git repo url is puppet.lab.localdomain, fatmin is my user's namespace, and General_Scripts is my repo.
This is a neat and very useful trick that I learned today. Lets say that you want to be able to monitor and log all keystrokes that are typed as root. This is particularly useful as normally you can only log when a user uses sudo to run a command. If the user has the abilty to become root however, then they have effectively eluded yourattempts to track their activity. Like Thomas Magnum shaking a tail, they are free to scoot around your island with the top down.
So how do you stop this from occuring? How to you log all activity and keystrokes made by root without implementing a bloated 3rd party software that will probably cost and arm and a leg? You use PAM you dingbat.
The secret sauce in this security burrito is the pam_tty_audit.so module. Here is how to use it,
Below is my stock /etc/pam.d/system-auth file
#%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. auth required pam_env.so auth sufficient pam_fprintd.so auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 500 quiet auth required pam_deny.so
session optional pam_keyinit.so revoke session required pam_limits.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so
Now look above and then look below at my modified system-auth file. Note the additonal session entry for pam_tty_audit.so.
[root@ip-172-31-21-28 pam.d]# cat system-auth #%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. auth required pam_env.so auth sufficient pam_fprintd.so auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 500 quiet auth required pam_deny.so
Note that you will need to add the pam_tty_audit.so call to your /etc/pam.d/password-auth as well to ensure that you capture all of root's keystrokes, no matter how they log in.
Auditd gives you the ability to write your own custom audit rules. This functionality allows an administrator to keep a close eye on system calls, file access, and user behavior. This added functionality is especially useful in environments that are requred to adhear to compliance standards that are above and beyond normal standards. Think PCI.
Once of the simplest rules to add is a watch rule which can be set on files and directories. In the example below we are watching the /etc/passwd file for permission changes (writes and attibute changes specifically). We are creating a custom key to use for organizational purposes.
[root@ip-172-31-21-28 ~]# auditctl -w /etc/passwd -p wa -k edit_watch
Here is a cool one – lets audit all binary executions under /usr/bin.
[root@ip-172-31-21-28 ~]# auditctl -w /usr/bin -p x
Using the -l option you can list your current audit rules, and using the -s option you can see the current status of the auditd subsystem
