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

Yum: Under the Covers with GPG Keys

Skeleton_key_1_keychain_sculpture_photo_cut_outs-r558fef9b275d4609b522ac07970a6af6_x7sa6_8byvr_324Hey look at this spooky key. Don't be frightened little one. Nothing scary is going to happen to you here. This is a safe place. As a matter of fact, if you stick around you might just learn a thing or two. A thing or two about GPG!

First off do any of us really know what GPG stands for? Well yes we do! It stands for GNU Privacy Guard. RPM Package creators use GPG to apply a digital signature to their packages. If a package was tampered with, then its GPG signature will no longer match what was placed in the original package.

First off to check what keys you have installed on your Linux server you can run the following rpm command as show in the example below.

[root@ip-172-31-22-45 ~]# rpm -qa gpg-pubkey
gpg-pubkey-0608b895-4bd22942
gpg-pubkey-fd431d51-4ae0493b
gpg-pubkey-2fa658e0-45700c69

 

Neet I have three keys installed. But lets say want to install another one. Well I can do so with the command below. In this example I have navigated to /etc/pki/rpm-gpg and am going to install the redhat beta key on my server.

[root@ip-172-31-22-45 rpm-gpg]# rpm –import RPM-GPG-KEY-redhat-beta

Hey that was fun. Now lets get our hands a bit dirtier.

Want to get more information on a specific key. Then this command is your huckleberry. Here you can see that this is the pubkey for the EPEL repo.

[root@ip-172-31-22-45 rpm-gpg]# rpm -qi gpg-pubkey-0608b895-4bd22942
Name        : gpg-pubkey                   Relocations: (not relocatable)
Version     : 0608b895                          Vendor: (none)
Release     : 4bd22942                      Build Date: Sat 14 Jun 2014 09:13:58 AM EDT
Install Date: Sat 14 Jun 2014 09:13:58 AM EDT      Build Host: localhost
Group       : Public Keys                   Source RPM: (none)
Size        : 0                                License: pubkey
Signature   : (none)
Summary     : gpg(EPEL (6) <epel@fedoraproject.org>)
Description :

 

To verify signature of a downloaded package, use the rpm command as shown below. In this example I have highlighted the key that was used to sign this package.

# rpm -vK nautilus-dropbox-1.6.0-1.fedora.i386.rpm
nautilus-dropbox-1.6.0-1.fedora.i386.rpm:
    Header V3 RSA/SHA1 Signature, key ID 5044912e: OK
    Header SHA1 digest: OK (a4d51906633f92913db075ba33946f50999c245e)
    V3 RSA/SHA1 Signature, key ID 5044912e: OK
    MD5 digest: OK (1b8ff7abc18f68bf274e24fc57fd3a87)

 

Using the bolded information in the example above, I can then use this information to track down the exact key that was used to sign the package.

[root@localhost Downloads]# rpm -qa | grep 5044912e
gpg-pubkey-5044912e-4b7489b1

 

Is this awesome, well not really, but you never know when you might need to use this information. Like on a test. Wink Wink.

Related articles

Using Yum Update to Apply Security Patches Only
How to Enable EPEL Repository on CentOs for Yum
Signing rpm packages with GPG

X11 No Worky – Worky

Christmas Ape from Space

 

 

 

 

 

 

Yikes, was banging my head against a wall trying to get X11 forwarding working on my RHEL 6.1 box. Every time I ssh’d in and attempted to pop an X window back to my fedora desktop, I was greeted with the error message below.

# Error: no display specified

Ok, I thought to myself — X11 forwarding is not enabled in sshd — let’s go fix it. However, when I checked /etc/ssh/sshd_config, I found that X11 forwarding was enabled. See the config item below, these needs to exist, and not set to no.

X11Forwarding yes

Ok so let’s check what the display variable is set to. So I ran the command below, which returned absolutely nothing, which meant that it’s not set to anything at all.

# echo $DISPLAY

So I check my local box and check to make sure that forwarding is enabled. Which it is

#grep X11 /etc/ssh/ssh_config
ForwardX11 yes

After I bit of research on google – I found a bugzilla that suggested I make sure that the following rpm was installed – xorg-x11-xauth.x86_64.  It wasn’t..

yum install xorg-x11-xauth.x86_64

Then logout and back in again. You will be now be greeted by the line below.

/usr/bin/xauth:  creating new authority file /root/.Xauthority

Now check your display variable.

# echo $DISPLAY
localhost:10.0

Ah, much better.

 

 

 

Using ssh-copy-id to Push SSH key to Authorized Keys

f44d3-6a00e551c39e1c88340162fcbcab43970d-piEverywhere I have ever worked we have always used complex scripts to push out id files to enable passwordless authentication from a bastion host. Today I stumbled across ssh-copy-id which is about as easy to use as it gets.

Check out the section below for usage and substitute your servers hostname where you see <yourhost>

# ssh-copy-id -i ~/.ssh/id_rsa.pub <yourhost>

You will get output similar to what is shown below.

Now try logging into the machine, with “ssh ‘<yourhost>'”, and check in:

  .ssh/authorized_keys

to make sure we haven’t added extra keys that you weren’t expecting.

Checkout the link below for more info

http://www.thegeekstuff.com/2008/11/3-steps-to-perform-ssh-login-without-password-using-ssh-keygen-ssh-copy-id/#more-268

Below is a little wrapper script that I use to make using ssh-copy-id even easier. Please feel free to borrow it for a bit.

[code language=”css”]
#!/bin/bash

echo "Please Enter Server Name :"
read servername
ssh-copy-id -i ~/.ssh/id_rsa.pub $servername
[/code]

Enabling SNMP in ESXi 4.1 using the Remote CLI

cdc63-6a00e551c39e1c88340168ea399c7e970c-pi

Based on the fact that ESX 4.1 is the last major release of ESX, I decided that I would make myself familiar with managing ESXi hosts.  Since I monitor all my hosts via Zenoss, I figured that I needed to get snmp up and running first.

So I first when out and installed the remote cli for ESX on my ubuntu desktop.  The rcli can be downloaded here. The remote cli allows you to run command administrative commands against ESX/ESXi systems. Its availbile for Windows or Linux.

Configuring on ESXi 4.1, Licensed

First configure your community string, target, and port:

vicfg-snmp –server <ESXi_ip> -c <communityname> -p 161 -t <destination_host>@161/<community name>

Then enable it using the command below:

vicfg-snmp –server <ESXi_ip> -E

Next verify your settings:

vicfg-snmp –server <ESXi_ip> -s

Now test your settings:

vicfg-snmp –server <ESXi_ip> -T

These settings are written out to /etc/vmware/snmp.xml. Sample file below.

/etc/vmware # cat snmp.xml
<config>
<snmpSettings>
<communities>pubic</communities>
<enable>true</enable>
<port>161</port>
<targets>10.1.xx.xx@161 public</targets>
</snmpSettings>

Configuring on ESXi 4.0, Free/Foundation

I had a couple of ESXi 4.0 free hosts to configure, but my attempts to configure them using the cli failed as the snmp settings via cli were read only. So the first thing that you need to do is enable the unsupported console. Instructions can be found here.

Once you are able to ssh to the ESXi box, you need to edit the following file by hand, /etc/vmware/snmp.xml. Use the sample file above as a template and modify your ip, port, and string as needed. I use vi to edit mine.

Then run the command below

services.sh restart

You can then verify your settings using the remote cli by running the command below against your esxi box.

vicfg-snmp –server <ESXi_ip> -T

Reset HP ILO Via the Command Line

Gary_the_snail Its not unheard of that an HP ILO (Integrated Lights Out) can become sick and slow down to a crawl. When this occurs, a restart of the ILO is in order, which is easily accomplished via the ILO cli interface. Note that you need to make sure that that you have enabled ssh access in ilo.

The steps to reset an ilo via ssh are below.

</>hpiLO-> cd /map1
status=0
status_tag=COMMAND COMPLETED

</map1>hpiLO-> reset
status=0
status_tag=COMMAND COMPLETED
Resetting iLO.

CLI session stopped

Additional Resources:

http://fatmin.com/2011/06/13/redirect-linux-console-to-hp-ilo-via-ssh/

http://www.thevirtualway.it/en/?p=985

http://setaoffice.com/2010/07/17/connecting-to-hp-ilo-using-the-command-line/