Managing RHEV VMs Via the Virsh CLI

cropped-space-cadet.jpg

Out of the box you are not going to be able to run virsh commands on the cli as root. Libvirt, Virsh, and KVM are just not that tightly integrated in RHEV.

You can however, follow the procedure below, and create a user and password to use for authentication.

# saslpasswd2 -a libvirt fatmin
Password:
Again (for verification):

Now enter the credentials you entered above.

# virsh list –all
Please enter your authentication name: fatmin
Please enter your password:
Id Name State
—————————————————-
10 HostedEngine running

Now you can shut down or start a VM. Here I am shutting down my RHEV HostedEngine.

# virsh destroy HostedEngine
Please enter your authentication name: fatmin
Please enter your password:
Domain HostedEngine destroyed

 

 

Password Protecting Grub in RHEL 6

19552780-illustration-of-cartoon-wormGrub, is the standard boot loader used by each and every Linux type operating system that I can think of. RHEL 6 uses what I guess we are now calling grub 1.o, since grub 2.0 has been released and in use by Fedora for the last few releases. You will also find that grub 2.0 has replaced grub 1.0 in RHEL 7. At some point I plan to explore grub 2 at lenght, but today is not that day (unless something strange happens before I go to bed tonight — you never know).

 

Anyway – I digress. Below is an excerpt from the current grub.conf that is in use by my EC2 RHEL 6.5 instance. I've made it really tiny to save space.

# grub.conf generated by anaconda
#
# Note that you do not have to rerun grub after making changes to this file
# NOTICE:  You do not have a /boot partition.  This means that
#          all kernel and initrd paths are relative to /, eg.
#          root (hd0)
#          kernel /boot/vmlinuz-version console=ttyS0 ro root=/dev/vda1
#          initrd /boot/initrd-[generic-]version.img
#boot=/dev/vda
default=0
timeout=1

splashimage=(hd0)/boot/grub/splash.xpm.gz

hiddenmenu
title Red Hat Enterprise Linux Server (2.6.32-431.17.1.el6.x86_64)
        root (hd0)
        kernel /boot/vmlinuz-2.6.32-431.17.1.el6.x86_64 console=ttyS0 ro root=UUID=05e7b919-2577-40a7-91fb-1ccdede87fc4 rd_NO_LUKS  KEYBOARDTYPE=pc KEYTABLE=us LANG=en_US.UTF-8 xen_blkfront.sda_is_xvda=1 console=ttyS0,115200n8 console=tty0 rd_NO_MD SYSFONT=latarcyrheb-sun16 crashkernel=auto rd_NO_LVM rd_NO_DM rhgb quiet
        initrd /boot/initramfs-2.6.32-431.17.1.el6.x86_64.img

To configure a password to use for grub you need to use the grub-crypt command. as you can see in the example below, grub-crypt prompts you for your password, although you can also pass the password to grub-crypt in the inital command. Grub-crypt spits out your hashed and salted password.

[root@ip-172-31-22-45 ~]# grub-crypt
Password:
Retype password:
$6$V0qkcD4b/CouCY/L$.7vrHd.X6MZWzzDxvXdQn3avPwv2rUX80XKuS.Hvh1YqR11ZyINZszvJ/e0qH6VcsFMAVWAPWXtugHHYTzYj90

Now stick this password in your grub.conf using the format below.

password –encrypted $6$V0qkcD4b/CouCY/L$.7vrHd.X6MZWzzDxvXdQn3avPwv2rUX80XKuS.Hvh1YqR11ZyINZszvJ/e0qH6VcsFMAVWAPWXtugHHYTzYj90

You have a couple of options when inserting the password into the grub.conf. You can either stick this entry near the top of the file, which protects each and every boot image that you might be configured to use, or you can stick the entry directly into a particular stanza to protect a specific boot image. For example, if you are building your servers with the option to pxe-boot from grub, or wipe the disk from grub, you might want to protect these options with a password.

Also note that adding a password to grub does not keep an unauthorized user from being able to boot or reboot a server, rather what it does is protect the grub menu from being edited manually durring a reboot. This keeps nefarious users from being able to break the boot sequence and boot into single-user mode where they can compromise your system.

 

Related articles

RHEL6 – Restore Grub on MBR
Grub
RHEL6 – Mount: Could Not Find Any Free Loop Device

Fun With PAM: Working with pam_cracklib and pam_tally2

Liberty-bell_13850_smPlugable Authentication Modules, or PAM, is the standard mechanism that most Unix and Linux Operatng Systems use for user credential authentication. By design, PAM is broken out into a number of files, each with a specific purpose. Before you can get started with PAM you need to understand a bit about how PAM configuration files are formatted.  So lets get into that first before we try to bite off anything more.

 

PAM Config File Standards:

PAM config files follow a standard format as shown below.

Rule Types        Control        Module [module arguments]

 

There are 4 Rule Types

  • auth – used to authenticate users/passwords
  • account – set properties for a user's account
  • password – controls password changes
  • session – sets and controls environmental variables

And there are 5 Control Types

  • required – a module that a user is required to pass
  • sufficient – a user is not required to pass a sufficient module
  • optional – these modules do not have to be passed sucessfully
  • include – these rules reference other PAM config files
  • requisite – similar to required, but if failed, no further rules are checked

 

Configuring pam_cracklib:

Pam_cracklib is used to define password complexity. It has several module arguments that can be used to define password complexity and lenght. Its most common arguments are show below

  • ucredit – when used in the following format (ucredit=-n) requires the defined number of uppercase characters in a password
  • dcredit – when used in the following format (dcredit=-n) requires the defined number of digits in a password
  • ocredit – when used in the following format (ocredit=-n) requires the defined number of other (think symbols) type charaters in a password
  • lcredit – when used in the following format (lcredit=-n) requires the defined number of lower case letters  in a password
  • minclass – defines the minimum number of different character classes that must be present in a password.
  • minlen – defines the minimum required lenght of a password.

Here's a usage example of the cracklib module from a /etc/pam.d/system-auth file. In this example try_first_pass tells pam to try to use any cached credentials, while retry allows a user to try their password 3 times before the fail this module.

password    requisite     pam_cracklib.so minlen=8 ocredit=-1 ucredit=-1 try_first_pass retry=3

 

Configuring pam_tally2:

Pam_tally2 can be used to lock users after a defined number of failed login attempts. The example below, taken from the system-auth file will lock a user after 3 failed login attempts, will automatically unlock the user after 300 seconds, and will do so quietly, without any notification to the user.

auth        required        pam_tally2.so deny=3 unlock_time=300 quiet

The command pam_tally2 can be used to list users with failed logins and can also be used to reset a user's failed login count. See reset example below

pam_tally2 –reset –u testuser

Note that pam_tally2 deprecates the faillock module.

 

Supplementary PAM Configuration Options:

Want to limit a user to a particular number of concurrent ssh sessions? You can set this up in /etc/security/limits.conf if you are calling the pam_limits.so in your pam configs. Limits.conf provides the example below. Just copy the format and you are off to the races. Remember to remove the #.

#@student        -       maxlogins       4

 

 

Related articles

How to enforce password complexity on Linux
Secure Linux Servers
You are not allowed to access to (crontab) because of pam configuration.

Enycrypting Passwords Via SSL for Redhat Kickstart Configuration Files

MummyHello again earthlings. The fatmin returns once again to dispense a bit of wisdom. This handy one-liner is a command that for the life of me I cannot remember.

Our story begings when building your kickstart config and post-install config files you are going to need to set the password for at least one user (being root). If you are like me your configs add all sorts of users. As you know you cannot just stick the password for these users into your config files in plain text, rather you need to encrypt them via ssl.

The command to do so is below.

openssl passwd -1

At this point you will be prompted to enter the users password — twice. Then the command will spit out your ssl encrypted password which you can then shove into your config files.

Related articles

Really Awesome Network Config Differ Tricks we use to forget
Strategies to establish secure password storage systems
HomeLab: Simple SSH Setup on a Cisco Router
Re: Sound Wallet – Audio Cold Storage – Your private key as .wav, CD, or a Record

You are not allowed to access to (crontab) because of pam configuration.

PD Donut Guy with ShadowHey look a real live Linux post.

Sure enough, and right as rain I am back with something that is not about networking (yeah!) and not about Solaris (boo!).

This is a short story about how we had a user who was a member of our database team who was attempting to make modifications to the oracle user’s crontab. They kept running into the error below.

Authentication token expired
You (oracle) are not allowed to access to (crontab) because of pam configuration.

Remembering that the oracle account is a special account without a password, or the ability to login, I figured that it had something to do with the fact the lack or password or something related.

I used the chage command to determine that while the password was not expired, rather that the account was considered inactive. Probably due to the fact that we locked down login permissions for service users on this box, but did not take into account that this user needed to login from time to time to keep the account from becoming inactive.

# chage -l oracle
Last password change                                    : Mar 25, 2013
Password expires                                        : Apr 22, 2013
Password inactive                                       : May 06, 2013
Account expires                                         : never
Minimum number of days between password change          : 7
Maximum number of days between password change          : 28
Number of days of warning before password expires       : 7

Now whats funny about this issue is that its pretty much a time bomb waiting to go off. You lock down logins for service accounts and forget to modify the inactive or expiration dates, and some day in the near future your users cron jobs will stop running, which possibly could cause all hell to break loose depending on whats running out of cron.

The fix is as follows.

# chage -I -1 -m 0 -M 99999 -E -1 oracle

Then use chage again to check out the sexy new settings

# chage -l oracle
Last password change                                    : Mar 25, 2013
Password expires                                        : never
Password inactive                                       : never
Account expires                                         : never
Minimum number of days between password change          : 0
Maximum number of days between password change          : 99999
Number of days of warning before password expires       : 7

Related articles

HomeLab: Simple SSH Setup on a Cisco Router
HomeLab: Cisco 2621 Router Password Recovery/Factory Reset
chkcrontab 1.6
How to Use Cron to Automate Tasks on a VPS

RHEL – Managing Passwords with Chage

Large_SkeletonKeyPTo understand the chage command  if might be best to make sure that you understand the /etc/shadow file, so lets look at a line from mine. Note that “:” is the field separator.

chris:$6$MZsU1MdDNVs50KaP$.sPNd90oOieOHAMwWt5rVB1:15188:0:99999:7:::

In the shadow file the fields are as follows:

  1. Username
  2. Password Hash
  3. Date of Last Password Change in days since the dawn of Unix Time
  4. Minimum Password Age
  5. Maximum Password Age
  6. Password Warning Period
  7. Password Inactive Period
  8. Account Expiration

The basic options of the chage command are as follows

  • -M Max Days
  • -m Min Days
  • -I inactive
  • -E Expiry Date
  • -D 0 Force Password Change

So first lets take a look at the current settings for user “chris”. You will see that the entries below match the options listed above.

# chage -l chris

Last password change                                    : Aug 02, 2011
Password expires                                        : never
Password inactive                                       : never
Account expires                                         : never
Minimum number of days between password change          : 0
Maximum number of days between password change          : 99999
Number of days of warning before password expires       : 7

So lets say that we want to force user chris to update his password on next login

#chage -d 0 chris

and then set a minimum number of days of 10 between password changes

#chage -m 10 chris

or set an expiration date of 10/10/2020

#chage -E 10/10/2020 chris

You get the idea…

Anyway the chage command can be run interactively as well if you do not pass any options to the command other than the username.

Additional Resources:

Managing Password Aging on AIX, Solaris, Linux

http://www.thegeekstuff.com/2009/04/chage-linux-password-expiration-and-aging/