RHEL 7 Two-Factor SSH Via Google Authenticator

650x300xgoogle-authenticator-header.png.pagespeed.gp+jp+jw+pj+js+rj+rp+rw+ri+cp+md.ic.194erIegOZ.jpg

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

# git clone https://github.com/google/google-authenticator.git
Cloning into ‘google-authenticator’…
remote: Counting objects: 1435, done.
remote: Total 1435 (delta 0), reused 0 (delta 0), pack-reused 1435
Receiving objects: 100% (1435/1435), 2.32 MiB | 0 bytes/s, done.
Resolving deltas: 100% (758/758), done.

Now change directory as shown below and run bootstrap.sh.

# cd /root/google-authenticator/libpam

# ./bootstrap.sh

Now run the following commands to finalize the module installs.

# ./configure

#make

#make install

Assuming that you do not run into any errors, the following modules will be installed.

  • /usr/local/lib/security/pam_google_authenticator.so
  • /usr/local/lib/security/pam_google_authenticator.la

Continue reading

RHEL7 – How to Set Your Hostname in Redhat Enterprise Linux 7

name-badge

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.

[root@node1 ~]# hostnamectl
Static hostname: localhost.localdomain
Transient hostname: node1
Icon name: computer-vm
Chassis: vm
Machine ID: 4c26a2a3101947bfa2ec7d9c16824ca4
Boot ID: f58707942bd1458da48680025b6f1a53
Virtualization: vmware
CPE OS Name: cpe:/o:redhat:enterprise_linux:7.1:GA:server
Kernel: Linux 3.10.0-229.el7.x86_64
Architecture: x86_64

So lets set the hostname permanently using ‘hostnamectl’.

[root@node1 ~]# hostnamectl set-hostname node1.packy.lab.localdomain

As you can see the hostname shows correct in the output of the ‘hostname’ command

[root@node1 ~]# hostname
node1.packy.lab.localdomain

… and in the output from ‘hostnamectl’

[root@node1 ~]# hostnamectl
Static hostname: node1.packy.lab.localdomain
Icon name: computer-vm
Chassis: vm
Machine ID: 4c26a2a3101947bfa2ec7d9c16824ca4
Boot ID: f58707942bd1458da48680025b6f1a53
Virtualization: vmware
Operating System: Employee SKU
CPE OS Name: cpe:/o:redhat:enterprise_linux:7.1:GA:server
Kernel: Linux 3.10.0-229.el7.x86_64
Architecture: x86_64

Fedora21 – Quick and Dirty with Firewalld

firewall

Hey, are you new to Firewalld like most of us?

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.

According to this page. Firewalld is…

“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.

$ sudo firewall-cmd –get-default-zone
FedoraWorkstation

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.

$ sudo firewall-cmd –get-active-zone
FedoraWorkstation
interfaces: enp4s0 enp5s4 macvtap0 tun0 virbr0

The first two interfaces above are our physical interfaces, so we are good here. Now lets apply the rule, and make sure its permanent.

$ sudo firewall-cmd –permanent –zone=FedoraWorkstation –add-service http
success

Now lets check our rules. Note HTTP is missing.

$ sudo firewall-cmd –list-services
dhcpv6-client mdns samba-client ssh

Since we have only applied this new rule to our permanent config and not to our running config, we need to restart firewalld to see the updated rule.

 $ sudo firewall-cmd –reload

Now your can view the updated rules…

$ sudo firewall-cmd –list-services
dhcpv6-client http mdns samba-client ssh

Insync: The Powerful Google Drive Client For Linux

Insync

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.

Continue reading

Getting Started with Git: Creating a Git Repo

NettutsFetch-1So 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.

#git config –global user.name "Fatmin"

#git config –global user.email "fatmin@fatmin.com"

 

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.

#git remote add origin git@puppet.lab.localdomain:/fatmin/General_Scripts.git

 

Now we need to actually push the local files to the remote repo (origin) in the master branch.

#git push -u origin master

 

Now wait a bit and go check out the webUI. You should now see the README.md file in your new remote repo.

Related articles

Super Quick Git Guide
Bashit… Just a Custom Bash Prompt Setup for Git
Git and GitHub LiveLessons

RHEL6: Cool PAM Tricks – Logging Terminal Keystokes

Pam-original-cooking-spray-72450This 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

account     required      pam_unix.so
account     sufficient    pam_localuser.so
account     sufficient    pam_succeed_if.so uid < 500 quiet
account     required      pam_permit.so

password    requisite     pam_cracklib.so try_first_pass retry=3 type=
password    sufficient    pam_unix.so md5 shadow nullok try_first_pass use_authtok
password    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

account     required      pam_unix.so
account     sufficient    pam_localuser.so
account     sufficient    pam_succeed_if.so uid < 500 quiet
account     required      pam_permit.so

password    requisite     pam_cracklib.so try_first_pass retry=3 type=
password    sufficient    pam_unix.so md5 shadow nullok try_first_pass use_authtok
password    required      pam_deny.so

session     optional      pam_keyinit.so revoke
session     required      pam_tty_audit.so enable=root
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

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.

 

Related articles

Much Todo About Linux/RHEL Passwords
RHEL6 – How to Manually Logout of an Iscsi Disk
Fun With PAM: Working with pam_cracklib and pam_tally2

RHEL6: Composing Custom Auditd Rules for Fun and Profit

297247-typewriterAuditd 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

[root@ip-172-31-21-28 ~]# auditctl -l
LIST_RULES: exit,always watch=/etc/passwd perm=wa key=edit_watch
LIST_RULES: exit,always dir=/usr/bin (0x8) perm=x

[root@ip-172-31-21-28 ~]# auditctl -s
AUDIT_STATUS: enabled=1 flag=1 pid=741 rate_limit=0 backlog_limit=320 lost=0 backlog=0

Want to get down and dirty with audit rules – you can check out the audit rules man page by running the command below.

[root@ip-172-31-21-28 ~]# man audit.rules

 

 

 

Related articles

RHEL6 – SELinux Troubleshooting II: Electric Boogaloo
Linux audit files to see who made changes to a file
A Brief Introduction to auditd