Tag: rhel

  • 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
  • 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
  • HomeLab: Upgrading Cisco IOS Via tftp on RHEL

    0012fbf7_mediumSo I was planning on blogging about this process simply because I keep forgetting it. Being that I am in the middle of building out my lab, and have a ton of old cisco hardware with ancient images, I have found myself going through the process of updating firmware quite a bit as I tinker with different IOS images.

    The first thing that you are going to need is a tftp server, which I am running on my Fedora 18 desktop. Its a very easy setup, and has been simply documented on the link below. Note the article below is specfically about how to setup a tftp server on RHEL, however the process is pretty much the same.

    How to Install a tftp Server on RHEL

    Now if you are looking to setup a tftp server on Windows, well I cannot help you there. If I recall you just download and install a server app, and away you go.

    Below is another link that I have found that also does a fine job of explaining the Cisco side of the process simply, without getting too technical and long winded.

    How to Upgrade Cisco IOS Images

     
    Related articles

    HomeLab: The Cisco 3560G
    HomeLab: Configuring the NTP Client on a Cisco Catalyst Switches
    Configuring TFTP in Linux
    Best Cisco IOS switch for home use
    Cisco IOS: Basic Configuration of a Switch.
    Cisco IOS : How to configure passwords.
  • I have no name! – RHEL 6 and SSSD Issue.

    Cartoon_horses_st5This is an interesting one that I ran into today on an RHEL 6.3 VM that is using SSSD for authentication against LDAP.

    User contacted me stating that he was unable to su to a particual user.

    # su – app
    cannot find name for user ID 650
    [I have no name!@localhost ~]

    So I jumped on the box and attempted to "finger" the user "app". This command retured the expected output, as did the "id" command. Thinking that the issue was a temporary failure for the server to connect to the ldap server, I figured we were probably fine now. But when I attempted to su to the user above, I ran into the same issue that the user ran into. So I restarted sssd and tried again. Same issue. So in order to isolate the issue a bit more I then attempted to su to another user, and was successful.

    Huh?

    Remebering that I had run into a similar issue before I decided to stop sssd and then delete its cache

    service sssd stop ; cd /var/lib/sss/db ;rm cache_default.ldb; service sssd start.

    Boom, su now works like a charm.

    A bit of research shows that this is a known issue. See bugzilla here.

    Also I could have used the ldbsearch command to verify that the particular users database/cache entry was corrupt.

    ldbsearch -H /var/lib/sss/db/cache_default.ldb uidNumber=650

     

  • RHEL6 – Mount: Could Not Find Any Free Loop Device

    LoopSo I ran into this one today on RHEL 6.0 when trying to mount up a few additional isos on one of my remote kickstart servers.  I have actually run into this issue before in RHEL 5 ( see here) however being that this particular kickstart server was built using RHEL 6.0 and not RHEL 5 I figured that there was probably a new process to resolve as RHEL 6 no longer uses the traditional /etc/modprobe.conf.

    Note that a loop device is a pseudo device that makes a file accessible as a block device. In this case, the iso is the file.

    So here is how you fix it.

    First run the following command to increase the total number of loop devices to the max number of 256.

    MAKEDEV -v /dev/loop

    Then you need to make sure that this command runs at boot time, so stick it in /etc/rc.local. I think you can also pass this kernel option to the OS at boot in the /etc/grub.conf however I have not tried it.

  • RHEL6 – Quick and Easy Samba Configuration Guide – Part II

    Cartoon-SnakeA few weeks ago i published a Quick and Easy Samba Configuration Guide, which can be found here. After messing around with samba on and off since then I have learned a few things that I wanted to document before I totally forgot them. So  lets down to business.

    Samba Password Failures

    So I have read a few things here and there that say that passwords can be a sticky issue in samba. Such was the case for me when I was trying to set a simple password of “myuser” for the user myuser.

    As you can see below I got a bit of output from the command however in the end I was able to add the user, I quick check of google showed that the output below was supposed to be bogus anyway.

    # smbpasswd -a myuser
    New SMB password:
    Retype new SMB password:
    tdbsam_open: Converting version 0.0 database to version 4.0.
    tdbsam_convert_backup: updated /var/lib/samba/private/passdb.tdb file.
    for type 1 (min password length), returning 0
    account_policy_get: tdb_fetch_uint32 failed for type 2 (password history), returning 0
    account_policy_get: tdb_fetch_uint32 failed for type 3 (user must logon to change password), returning 0
    account_policy_get: tdb_fetch_uint32 failed for type 4 (maximum password age), returning 0
    account_policy_get: tdb_fetch_uint32 failed for type 5 (minimum password age), returning 0
    account_policy_get: tdb_fetch_uint32 failed for type 6 (lockout duration), returning 0
    account_policy_get: tdb_fetch_uint32 failed for type 7 (reset count minutes), returning 0
    account_policy_get: tdb_fetch_uint32 failed for type 8 (bad lockout attempt), returning 0
    account_policy_get: tdb_fetch_uint32 failed for type 9 (disconnect time), returning 0
    account_policy_get: tdb_fetch_uint32 failed for type 10 (refuse machine password change), returning 0

    Added user myuser

    But when I attempted to test with the samba client I got the following error

    # smbclient -L localhost -U myuser
    Enter myuser’s password:
    session setup failed: NT_STATUS_LOGON_FAILURE

    So at this point I decided to change the password to something more complex and tried again and this time no issues at all. Just to be cheeky, I then changed the password for myuser back to “myuser” and it worked again.

    Lesson learned here if if you see this message try changing your password to something else.

    Troubleshooting Samba Share Write Issues

    Holy Cow, this one was driving me nuts and I probably spent a good hour trying to fix it. And the fix was super easy. Below I am just trying to put a file on the share using smbclient

    # smbclient //localhost/samba -U myuser
    Enter myuser’s password:
    Domain=[WORKGROUP1] OS=[Unix] Server=[Samba 3.5.10-125.el6]
    smb: \> put /var/tmp/test test
    NT_STATUS_ACCESS_DENIED opening remote file \test

    I tried selinux, various smb.conf changes, checking ip tables, and in the end the issue was as simple as permissions on the directory

    chmod 2775 /shared/samba

    Once I set this everything worked fine.

    Additional Smb.conf Configuration Items

    Just do get samba up and running on a basic level you don’t really have to know too many configuration directives, and most of those are documented in smb.conf anyway. However there are a few more options that I think are either useful or interesting. They are below.

    admin users – a user configured as an admin user can perform actions as root.

    invalid users – any user here is denied access, even if the group that the user is a member of has access.