Email notification on SSH login using PAM

There are cases where you are interested in getting a email message on every successful login through SSH. This could have been solved by adding a simple line in .bash_profile for every user, but this solution does not catch all SSH logins. The preferred way of doing it is by using PAM and a custom email notify script.

Add the following line to the bottom of file /etc/pam.d/sshd

session optional pam_exec.so seteuid /usr/local/bin/login-notify.sh

This is the contents of /usr/local/bin/login-notify.sh

#!/bin/sh

# Change these two lines:
sender="root@example.com"
recepient="root"

if [ "$PAM_TYPE" != "close_session" ]; then
    host="`hostname`"
    subject="SSH Login: $PAM_USER from $PAM_RHOST on $host"
    # Message to send, e.g. the current environment variables.
    message="`env`"
    echo "$message" | mailx -r "$sender" -s "$subject" "$recepient"
fi

Make the script executable

# chmod 0700 /usr/local/bin/login-notify.sh

This is the email message you receive the next time you or someone else log in using SSH

SSH Login: username from hostname-remote.user.com on target-host.example.com

XDG_SESSION_ID=775
SELINUX_ROLE_REQUESTED=
PAM_SERVICE=sshd
SELINUX_USE_CURRENT_RANGE=
PAM_RHOST=hostname-remote.user.com
PAM_USER=username
PWD=/
SELINUX_LEVEL_REQUESTED=
SHLVL=1
PAM_TYPE=open_session
PAM_TTY=ssh
XDG_RUNTIME_DIR=/run/user/9000
_=/usr/bin/env

This has been tested on CentOS 7 and Ubuntu 18.04, but I guess most recent distributions supports this.

DATA PRIVACY
Sending emails on login may conflict with data privacy on multiuser systems. This can be circumvented by just sending emails for specific users or root (if at all accessible via SSH). I might cover that in a later post.

Using KVM as hypervisor on CentOS 7

This post describes how to use a CentOS 7 installation as hypervisor for a virtual machine running Ubuntu 14.04 LTS.

These examples is just to show the basics on getting KVM virtualization up and running and should not be put in to production before considering the added value SElinux gives.

Example 1
Since this VM is planned to be a webserver, the VM will only have access to a text console (headless) and there will not be any graphical consoles available through VGA, VNC, Spice or QXL. The VM will be connected to the default network, meaning network traffic from the VM will be NAT based through the host.

Using virt-install to create a headless VM
$ sudo virt-install -n vm-name –description “server for example.com” –os-type=Linux –os-variant=generic –ram=2048 –vcpus=1 –disk path=/var/lib/libvirt/images/vm-hhj.qcow2,bus=virtio,size=10 –graphics none –console pty,target_type=serial –location=/var/lib/libvirt/images/ubuntu-14.04.2-server-amd64.iso –extra-args=console=ttyS0,115200n8 serial –network default

To exit this console view you can use the key combination CTRL + Alt gr + 9
If you are using Putty as SSH client from Windows you can use the key combination CTRL+5 on the Norwegian, Swedish and Finnish keyboard layout.

Example 2
VM with graphical console available through SSH using port forwarding and VNC.

From your local workstation
Create a SSH tunnel from you workstation to the hypervisor server
$ ssh servername.example.com -L 5903:127.0.0.1:5903

Description of the SSH -L option
-L [bind_address:]port:host:hostport
Specifies that the given port on the local (client) host is to be forwarded to the given host and port on the remote side.

On the hypervisor server
Create a VM with a graphical VNC console
$ sudo virt-install –graphics vnc,port=5903 –noautoconsole –network default –name TestVM –ram 2048 –vcpus=1 –disk path=/var/lib/libvirt/images/TestVM.img,size=5 –location=/var/lib/libvirt/images/ubuntu-14.04.2-server-amd64.iso -v –accelerate –noreboot

From your local workstation (while you have a active SSH session with port forwarding)
Start a VNC connection to localhost port 5903 using krdc or other VNC clients.
The VNC path would then be like
vnc://localhost:5903

Or you can test virt-viewer
$ virt-viewer –connect qemu+ssh://username@example.com/system TestVM

Create file
/etc/polkit-1/localauthority/50-local.d/50-org.example-libvirt-remote-access.pkla

[Remote libvirt SSH access]
Identity=unix-group:wheel
Action=org.libvirt.unix.manage
ResultAny=yes
ResultInactive=yes
ResultActive=yes

You should now be able to install your desired operation system on your new VM.

virsh
Here is a list of useful virsh commands that might come handy when using CentOS as hypervisor.

Start VM
# virsh start vm-name

Stop VM (ACPI)
# virsh shutdown vm-name

If shutdown does not work you can try the destroy command. It is like using the power button on a physical server.
# virsh destroy vm-name

Connecting to the VM and start the installation
# virsh console vm-name

List networks
# virsh net-list

If the network is not active, start it by doing:
# virsh net-start default

List all VMs
# virsh list –all

Remove VM from list
# virsh undefine vm-name

Sources
https://snippets.webaware.com.au/howto/running-qemu-with-port-redirection-through-libvirt/
http://forum.proxmox.com/threads/21194-Port-Forward-with-built-in-NAT-and-PVE-Firewall
http://wiki.libvirt.org/page/SSHPolicyKitSetup
https://www.jethrocarr.com/2012/08/04/virt-viewer-remote-access-tricks/
https://virt-manager.org/download/

Howto enter VMware ESXi license key after it has expired

vmware-esxi-5-license-has-expired“Disable VMware ESX” is the warning message that is displayed when you open your VMware vSphere Client after the 60-day evaluation period has expired without typing in a new license key for your free VMware vSphere Hypervisor 5 install. You cannot type in the license key in the vSphere Client after the evaluation period has expired. If you do not type in the key before it expires you will not be able to power on VMs after they have been powered down.

This is a short howto describing how you can type in the license key for you free VMware Hypervisor after it has expired, since you cannot use the vSphere Client.
This requires that you have enabled the SSH service on your host before it expired and you can access it using your favourite SSH client to your ESXi host.
The file should look something like this if you have not entered any license information 00000-00000-00000-00000-00000.
This key should be replaced with the key you have gotten from VMware http://www.vmware.com/products/vsphere-hypervisor/ when you downloaded the installer file.

This is a step by step description of how you can update the license file

  1. Start a SSH session to your ESXi host using your favourite SSH client like Putty
  2. Log in with the username root (unless you have changed it to something else)
  3. Open the file /etc/vmware/vmware.lic using the vi editor
    ~# vi /etc/vmware/vmware.lic
    vmware-esxi-5-license-has-expired
  4. Delete the old license key with the dd command
    vmware-esxi-5-license-has-expired-putty02
  5. Insert a new license key by with the i command
    vmware-esxi-5-license-has-expired-putty03
    vmware-esxi-5-license-has-expired-putty04

    The key above is just an example and is not a valid key. Replace the key used above with the evaluation license key you received from VMware.

  6. Save the file using the write command w
    vmware-esxi-5-license-has-expired-putty05
  7. Now you can open a new vSphere Client window and see if the license warning windows appears again. If it does not, then you have successfully updated the license key. If not, then you need to check if the license key is typed in correctly.

All this can be done without a reboot of the ESXi host.

Using Lsyncd to perform “live” syncronization of a local directory to a remote directory

This post is a short HOWTO and describes how you can install and run lsyncd to perform a rsync syncronization from local to a remote server using SSH.
Lsyncd is a daemon to continuously synchronize directory trees and relies on inotify. If you need real live syncronization DRBD might be a better alternative since it is a block level syncronization.

Installing Lsyncd 2.0 from source on CentOS 6
Lsyncd is not included as a package in CentOS 6, so you need to download the source file from http://code.google.com/p/lsyncd/downloads/list.
You should have rsync, GCC and lua-devel installed on your system before you continue installing Lsyncd.

# yum install rsync lua-devel

Unpack the lsyncd source file and run the following commands from the unpacked file

# configure 
# make
# make install

make install copies the compiled files and install them to the right directories in your system.

I need to configure a non password SSH communication between the two servers with a shared SSH key.
On the source server run the following command to generate a SSH key, if you have not done this already.
Remember to do this as the user you are going to perform the sync with.

# ssh-keygen

Secure copy the generated SSH key from the source server to your target server

# scp ~/.ssh/id_rsa.pub root@remoteserver:/tmp

On the target server you need to add the copied SSH key to your existing authorized keys file.
Also remember to do this with the user you are going to connect with from the source server.

# cat /tmp/id_rsa.pub >> ~/.ssh/authorized_keys

If you do not have this file, just create it using the touch command described below

# touch ~/.ssh/authorized_keys

Test if you can ssh without a password from your source server to the target server.

I have made a config file, /root/scripts/lsyncd.conf that tells Lsyncd where to put the log- and statusfile. That it should be running as a daemon in the background, and a sync should occur after 900 seconds (15 minutes) if there have not been any filesystem changes and there should not be more than 6 parallell Lsyncd processes.

settings = {
   logfile      = "/tmp/lsyncd.log",
   statusFile   = "/tmp/lsyncd.status",
   nodaemon     = false,
   maxDelays    = 900,
   maxProcesses = 6,
}

sync{default.rsyncssh, source="/path/on/source/", host="hostnam.target.server.tld", targetdir="/path/on/target/"}

To start lsyncd you run the command

# lsyncd /root/scripts/lsyncd.conf

You should now see a Lsyncd process running as a daemon on your system. It performs a sync when you start and then waits for any filesystem changes or sync after 900 seconds.

If you would like Lsyncd to start at boot, just add the following line to the bottom of file /etc/rc.local

lsyncd /root/scripts/lsyncd.conf

You do now have a working secure rsync syncronization between two servers.

What directories you are syncing

# tail -f /tmp/lsyncd.status

What is happening now

# tail -f /tmp/lsyncd.log