How to fix wlanO not found

The problem statement is while doing an *ip a* on the terminal and its output doesn’t show the wireless device, like below:

wlan0_not_showing_2017-01-27-22-17-20

The dmesg says like this below:

iwlwifi_firmware_not_found_2017-01-28-04-20-26

Let me cross check that file is present in the system or not,  just like below:

firmware_file_present_2017-01-28-04-23-41

So, it is very much seated there, where it suppose to be  Well, that trigger me trip to visit some kernel config variables, like below:

kernel_var_2017-01-28-04-31-25

It looks fine, then?? well, that warrant few more checks, well I made some trip to *gentoo forum* to know what is missing. And someone in the closed thread mentioned that The variable in question is CONFIG_IWLWIFI which is recommended =m and that necessarily meant I have to recompile the kernel one more time with that variable set to the module in the kernel.

Next, I went ahead and compile the kernel with that mentioned variable as the module. Okay, I have rebooted my machine and here is the outcome,

wlan0_showing_2017-01-28-05-14-35

Cool, but why we have to turn it to a module within the kernel than just straight built into the kernel not showing the device ?? The reason, by the time kernel boot and the firmware file, reside on the filesystem not yet read so it was missing.

Hope this will help.

 

 

 

 

How to sign your git commit?

First thing first,you are supposed to have a digital key. Haven’t you?? Get one!, but how? Here is how to create gpg key from command line.

I am assuming( o yeah I can’t help myself about that! thinking of you being smart enough to figure it out) ,if  you haven’t already installed GNUPG yet , read it here about it and take advantage of your OS’s package manager to install the package .

Again, once you setup your gpg key and uploaded it into the one of the keyserver and it will sync with other keyservers too.  Mind you, only share your public key , the private key should be reside with you.

Heads up! for heaven’s sake please remember the passphrase you enter while creating the key and do not forget to create a revocation certificate too.

Another way , you might start using keybase ,which quite new ,but has promise and will take over gnupg soon( thinking in that direction) . If you want to use , please let me know, I have few invite left with me. But please disclose your original identity .

Now, you need to tell git to use your private key to encrypt your commits ,but how? Here is how you should do ..read on:

I think, this page is very well explained. Give some effort to read it and understand it.

I believe you understood the previous link to gpg signing(again assuming you did!). Once you properly done with it . You can verify like below :

bhaskar@ArchLinux_17:34:07_Fri Nov 25:~/git-linux/Linux_Infrastructure_Management>git log –show-signature -1
commit a825344b39e962dcf3df91a276cfb53fd57db4dc
gpg: Signature made Sun 20 Nov 2016 04:27:44 PM IST
gpg:                using RSA key B23A9DB7114B2915
gpg: Good signature from “Bhaskar Chowdhury (Musing_with_GNU/Linux!!) <unixbhaskar@gmail.com>” [ultimate]
gpg:                 aka “[jpeg image of size 62428]” [ultimate]
Author: Bhaskar Chowdhury <unixbhaskar@gmail.com>
Date:   Sun Nov 20 16:27:33 2016 +0530

modified few sentences

Signed-off-by: Bhaskar Chowdhury <unixbhaskar@gmail.com>

 

But hey! how do you sign the commit??  Two ways:

  1. You need to pass -S  along the line with commit command and give the key hash.This is the laborious way to do thing and soon become very cumbersome.

Of course there is better way and that is second way of doing it:

2. You need to put in the global section of the git config (by doing git config add ) or by placing it for any project specific way . Like below ,I am having this configuration for this project.

bhaskar@ArchLinux_17:41:10_Fri Nov 25:~/git-linux/Linux_Infrastructure_Management>git config –list
user.email=unixbhaskar@gmail.com
user.name=Bhaskar Chowdhury
user.signingkey=**Long hash for key**(hsg23ljfgdrtu456)
push.default=matching
gpg.program=gpg2
commit.gpgsign=true
core.editor=vim
core.abbrev=12
color.ui=true
pretty.fixes=Fixes: %h (“%s”)
log.showsignature=true
alias.logline=log  –pretty=format:’%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset’ –abbrev-commit
core.repositoryformatversion=0
core.filemode=true
core.bare=false
core.logallrefupdates=true
remote.origin.url=https://github.com/unixbhaskar/Linux_Infrastructure_Management.git
remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*
branch.master.remote=origin
branch.master.merge=refs/heads/master

 

You are good enough to read it through ..aren’t you? By the way , those are git config options ,you need to tell git to use it by providing the key value at the git command line ,like this :

bhaskar@ArchLinux_17:41:26_Fri Nov 25:~/git-linux/Linux_Infrastructure_Management>git config add user.email unixbhaskar@gmail.com

If you did that with your mail id for a the specific project ,it can how you the first line of output shown above. Likewise ,you need to do that for other options too.

Did you notice there is “singed-off-by” ? It can be achieved by using -s (small ess) along the commit message or automate it like other options mentioned above.Why that is there ? Because ,oftentimes ,commiter and the author of the patch is not the same person. Plus for reviewing purpose.So, both author and commiter get credit for the submission 🙂 .

This post is very rudimentary and assuming the reader is capable enough to do lot of research .BTW if you have any genuine query about it ,please do let me know.

 

 

 

GNU/Linux container internals aka Cgroups and Namespaces

In this post, I will shed some light on the GNU/Linux container internals.Basically, what is underlying technology driving that. Here we go,without much ado:

What is GNU/Linux Container?

Is an operating system-level virtualization method for running multiple isolated GNU/Linux systems (containers) on a single control host (LXC host). It does not provide a virtual machine, but rather provides a virtual environment that has its own CPU, memory, block I/O, network, etc. space. This is provided by cgroups ( we will give details about it later) features in Linux kernel on LXC host. It is similar to a chroot, but offers much more isolation.
Before I give you the information about LXC , let me make you aware of the two crucial aspect of it ,namely cgroups and namespace.

Cgroups AKA Control Group:

It is a Linux kernel feature to limit, police and account the resource usage of certain processes (actually process groups).

  • Create and manage them on the fly using tools like cgcreate, cgexec, cgclassify etc
  • The “rules engine daemon”, to automatically move certain users/groups/commands to groups (/etc/cgrules.conf and /usr/lib/systemd/system/cgconfig.service)
  • Through other software such as (LXC) virtualization
  • (control groups) subsystem is a Resource Management solution providing a generic process-grouping framework
  • Cgroups provide resource management solution (handling groups)

For Cgroups implementation need a few simple hook into rest of the kernel,namely :

a) For each process :/proc/pid/cgroup

b) System-wide: /proc/cgroup
But we are lucky enough that, newer distribution running systemd comes along with all those tweak by default,so don’t sweat.

A little internals does not harm!! here we go :

First,cgroups use VFS(virtual file systems),all entries created in it ,are not persistent,means deleted on reboot.

Second, all cgroups actions are performed via file systems actions(create/remove directory,reading/writing to the files in it,mounting/mount options).

For example :

cgroup inode_operations for cgroup mkdir/rmdir.

cgroup file_system_type for cgroup mount/unmount.

cgroup file_operations for reading/writing to control files.

Systemd uses control groups only for the process grouping ;not for anything else like allocating resources like block io, bandwidth,etc.

It look something like this :

#subsys_name hierarchy    enabled

cpuset  8    1    1

cpu 3    2    1

cpuacct 3    2    1

blkio   4    2    1

memory  7    2    1

devices 2    41   1

freezer 5    1    1

net_cls 6    1    1

Below are few things you can do with cgroup,provided the library is installed:

Example:

cgcreate -g cpuset:/test

cgset -r cpuset.cpus=1 /test

cgset -r cpuset.mems=0 /test

cgexec -g

I have touched the tip of ice-burg ,if you are really interested to explore more , then you should follow the below mentioned link.

To use the effect of it ,you got to install libcgroup. The best place to know about cgroups is here and here and here  . Please read those mentioned link before to get a thorough understanding of cgroups.

Namespaces:

a)It is light weight process virtualization.

b) Isolation : enable a process or group of process to view the system in different perspective.

c)Much like zones in Solaris.

d)No hypervisor layer(as in OS virtualization like kvm and xen)

There are currently 6 namespaces,those are:

  • mnt(mount points and filesystems)
  • pid(processes)
  • net(network stack)
  • ipc(system v ipc)
  • uts(hostname)
  • user(UIDs)

Namespace first appear in Linux kernel 2.4.19,way back in 2002!!

** Each namespace has a unique inode number.

You need to know which config options are get effected ,while manipulating it(namespace). Here are those :

Kernel config items:

CONFIG_NAMESPACES

CONFIG_UTS_NS

CONFIG_IPC_NS

CONFIG_USER_NS

CONFIG_PID_NS

CONFIG_NET_NS

Each and every option doing the specific duty,as mentioned earlier. And in user space you have two package to play with it,those are :

iproute and util_linux 

Please explore those package in and the offering in detail to work with the above.Plus one has care about below findings:

How to find all existing namespace in GNU/Linux?

If you execute as root,you get the list of attached namespaces of the init process using PID=1.

In order to find other namespaces with attached processes in the system, we use these entries of the PID=1 as a reference. Any process or thread in the system, which has not the same namespace ID as PID=1 is not belonging to the DEFAULT namespace.

Additionally, you find the namespaces created by “ip netns add ” by default in /var/run/netns/ .

Okay, credit has to be given where it’s due……

Rami Rosen was kind enough to provide lots of information about those and most importantly share with public.Thanks Rami!  Here is his paper about it.

Check out this wonderful guide about it at LWN. Equally well written blog about it on opencloudblog and  here .

How docker use namespace,specifically about mount namespace.

Justin Weissig written a wonderful article about cgroups.

A must view place is kernel documentation about cgroups.

Ginny Henningsen and Lenz Grimmer written a magnificent blog at Oracle site.

Hope this will give you heads up.

Cheers!

Mod_Security and Mod_Evasive implementation and Testing on Scientific Linux

Yep,those two module has to be integrated with Apache running on SL.I am wildly expecting people who read this post at least have an idea what is Apache and what module can do;specifically those two modules can do.Anyway if you are really interested to know more about those two modules I would like to urge you people to please visit Apache’s web site(http://apache.org) and mod_security web site(http://www.modsecurity.org/).One more information I go with the default rule come along with it;you might tweak the rules according to your need.

So here we go without much ado..lets dig in..

Step 1:

bhaskar@Scientific-Linux_10:36:32_Wed Jan 25:~> sudo yum install mod_security
Loaded plugins: refresh-packagekit
Setting up Install Process
Resolving Dependencies
--> Running transaction check
---> Package mod_security.i686 0:2.5.12-2.el6 will be installed
--> Finished Dependency Resolution

Dependencies Resolved

================================================================================================================================================================================================================================
Package Arch Version Repository Size
================================================================================================================================================================================================================================
Installing:
mod_security i686 2.5.12-2.el6 epel 896 k

Transaction Summary
================================================================================================================================================================================================================================
Install 1 Package(s)

Total download size: 896 k
Installed size: 3.3 M
Is this ok [y/N]: y
Downloading Packages:
mod_security-2.5.12-2.el6.i686.rpm | 896 kB 00:02
Running rpm_check_debug
Running Transaction Test
Transaction Test Succeeded
Running Transaction
Installing : mod_security-2.5.12-2.el6.i686 1/1

Installed:
mod_security.i686 0:2.5.12-2.el6

Complete!

Step 2:

Installing mod_evasive


bhaskar@Scientific-Linux_10:38:53_Wed Jan 25:~> sudo yum install mod_evasive
[sudo] password for bhaskar:
Loaded plugins: refresh-packagekit
Setting up Install Process
Resolving Dependencies
--> Running transaction check
---> Package mod_evasive.i686 0:1.10.1-10.el6 will be installed
--> Finished Dependency Resolution

Dependencies Resolved

================================================================================================================================================================================================================================
Package Arch Version Repository Size
================================================================================================================================================================================================================================
Installing:
mod_evasive i686 1.10.1-10.el6 epel 24 k

Transaction Summary
================================================================================================================================================================================================================================
Install 1 Package(s)

Total download size: 24 k
Installed size: 49 k
Is this ok [y/N]: y
Downloading Packages:
mod_evasive-1.10.1-10.el6.i686.rpm | 24 kB 00:00
Running rpm_check_debug
Running Transaction Test
Transaction Test Succeeded
Running Transaction
Installing : mod_evasive-1.10.1-10.el6.i686 1/1

Installed:
mod_evasive.i686 0:1.10.1-10.el6

Complete!

Step 3:

Like this :

bhaskar@Scientific-Linux_11:04:48_Wed Jan 25:~> sudo vim /etc/httpd/conf/httpd.conf
# Mod_evasive implementation

DOSHashTableSize 3097
DOSPageCount 5
DOSSiteCount 100
DOSPageInterval 2
DOSSiteInterval 2
DOSBlockingPeriod 10
DOSBlockingPeriod 600


Step 4:

Restart the httpd server

bhaskar@Scientific-Linux_11:06:09_Wed Jan 25:~> sudo /sbin/service httpd restart
Stopping httpd: [FAILED]
Starting httpd: [ OK ]

It failed in first occassion because it was not running …

Step5:

To test mod_evasive to work or not ..using this perl script to test

#!/usr/bin/perl

# test.pl: small script to test mod_dosevasive's effectiveness

use IO::Socket;
use strict;

for(0..100) {
my($response);
my($SOCKET) = new IO::Socket::INET( Proto => "tcp",
PeerAddr=> "scientific-linux.localdomain:80");
if (! defined $SOCKET) { die $!; }
print $SOCKET "GET /?$_ HTTP/1.0\n\n";
$response = ;
print $response;
close($SOCKET);
}

Step 6:
So installing mod_security and enable the log file here ;

root@Scientific-Linux_11:20:03_Wed Jan 25:/var/log/httpd # ls
access_log error_log modsec_audit.log modsec_debug.log

Step 7:

Mod_security installaton base:

root@Scientific-Linux_11:21:20_Wed Jan 25:/etc/httpd # cd modsecurity.d/

root@Scientific-Linux_11:21:24_Wed Jan 25:/etc/httpd/modsecurity.d # ls

base_rules modsecurity_crs_10_config.conf modsecurity_localrules.conf optional_rules

Step 8:

Here is the two module file we have installed

root@Scientific-Linux_11:24:37_Wed Jan 25:/etc/httpd/conf.d # ls

mod_evasive.conf mod_security.conf README welcome.conf

Step 9:

Here are the rules files ,which can be adjusted according to our need

root@Scientific-Linux_11:38:01_Wed Jan 25:/etc/httpd/modsecurity.d/base_rules # ls
modsecurity_35_bad_robots.data modsecurity_46_et_web_rules.data modsecurity_crs_30_http_policy.conf modsecurity_crs_41_xss_attacks.conf modsecurity_crs_49_inbound_blocking.conf
modsecurity_35_scanners.data modsecurity_50_outbound.data modsecurity_crs_35_bad_robots.conf modsecurity_crs_42_tight_security.conf modsecurity_crs_50_outbound.conf
modsecurity_40_generic_attacks.data modsecurity_50_outbound_malware.data modsecurity_crs_40_generic_attacks.conf modsecurity_crs_45_trojans.conf modsecurity_crs_59_outbound_blocking.conf
modsecurity_41_sql_injection_attacks.data modsecurity_crs_20_protocol_violations.conf modsecurity_crs_41_phpids_converter.conf modsecurity_crs_47_common_exceptions.conf modsecurity_crs_60_correlation.conf
modsecurity_42_comment_spam.data modsecurity_crs_21_protocol_anomalies.conf modsecurity_crs_41_phpids_filters.conf modsecurity_crs_48_local_exceptions.conf
modsecurity_46_et_sql_injection.data modsecurity_crs_23_request_limits.conf modsecurity_crs_41_sql_injection_attacks.conf modsecurity_crs_49_enforcement.conf

Step 10:

While testing I try to access the etc dir of my local machine by url
and I got this on mod_security log

root@Scientific-Linux_12:13:08_Wed Jan 25:/var/log/httpd # tail -f modsec_audit.log
--e39f1539-H--
Message: Pattern match "\/etc\/" at REQUEST_FILENAME. [file "/etc/httpd/modsecurity.d/base_rules/modsecurity_crs_40_generic_attacks.conf"] [line "220"] [id "958700"] [rev "2.0.5"] [msg "Remote File Access Attempt"] [data "/etc/"] [severity "CRITICAL"] [tag "WEB_ATTACK/FILE_INJECTION"] [tag "WASCTC/WASC-33"] [tag "OWASP_TOP_10/A4"] [tag "PCI/6.5.4"]
Message: Access denied with code 403 (phase 2). [file "/etc/httpd/modsecurity.d/base_rules/modsecurity_crs_49_enforcement.conf"] [line "25"] [msg "Anomaly Score Exceeded (score 20): Remote File Access Attempt"]
Action: Intercepted (phase 2)
Stopwatch: 1327473375901826 18282 (16754 17940 -)
Producer: ModSecurity for Apache/2.5.12 (http://www.modsecurity.org/); core ruleset/2.0.5.
Server: Apache/2.2.15 (Scientific Linux)

--e39f1539-Z--

Step 11:

Another test of it :

root@Scientific-Linux_12:22:37_Wed Jan 25:/var/log/httpd # curl -i http://Scientific-Linux
HTTP/1.1 403 Forbidden
Date: Wed, 25 Jan 2012 06:53:16 GMT
Server: Apache/2.2.15 (Scientific Linux)
Accept-Ranges: bytes
Content-Length: 3822
Connection: close
Content-Type: text/html; charset=UTF-8

Test Page for the Apache HTTP Server on Scientific Linux

/*.content-column-left, .content-columns>.content-column-right {
/* Non-IE/Win */
}
img {
border: 2px solid #fff;
padding: 2px;
margin: 2px;
}
a:hover img {
border: 2px solid #f50;
}
/*]]>*/

Scientific Linux Test Page

This page is used to test the proper operation of the Apache HTTP server after it has been installed. If you can read this page, it means that the Apache HTTP server installed at this site is working properly.


If you are a member of the general public:

The fact that you are seeing this page indicates that the website you just visited is either experiencing problems, or is undergoing routine maintenance.

If you would like to let the administrators of this website know that you've seen this page instead of the page you expected, you should send them e-mail. In general, mail sent to the name "webmaster" and directed to the website's domain should reach the appropriate person.

For example, if you experienced problems while visiting http://www.example.com, you should send e-mail to "webmaster@example.com".

For information on Scientific Linux, please visit the Scientific Linux website.


If you are the website administrator:

You may now add content to the directory /var/www/html/. Note that until you do so, people visiting your website will see this page, and not your content. To prevent this page from ever being used, follow the instructions in the file /etc/httpd/conf.d/welcome.conf.

You are free to use the image below on web sites powered by the Apache HTTP Server:

[ Powered by Apache ]

Step 12:

And here is what the rules said :

root@Scientific-Linux_12:26:13_Wed Jan 25:/var/log/httpd # tail -f modsec_audit.log
--e39f1539-H--
Message: Matched phrase "curl" at REQUEST_HEADERS:User-Agent. [file "/etc/httpd/modsecurity.d/base_rules/modsecurity_crs_35_bad_robots.conf"] [line "26"] [id "990012"] [rev "2.0.5"] [msg "Rogue web site crawler"] [data "curl"] [severity "WARNING"] [tag "AUTOMATION/MALICIOUS"] [tag "WASCTC/WASC-21"] [tag "OWASP_TOP_10/A7"] [tag "PCI/6.5.10"]
Message: Warning. Operator LT matched 20 at TX:inbound_anomaly_score. [file "/etc/httpd/modsecurity.d/base_rules/modsecurity_crs_60_correlation.conf"] [line "31"] [msg "Inbound Anomaly Score (Total Inbound Score: 10, SQLi=, XSS=): Rogue web site crawler"]
Apache-Error: [file "/builddir/build/BUILD/httpd-2.2.15/modules/generators/mod_autoindex.c"] [line 2292] [level 3] Directory index forbidden by Options directive: /var/www/html/
Stopwatch: 1327474567095624 3198 (1152 2456 -)
Producer: ModSecurity for Apache/2.5.12 (http://www.modsecurity.org/); core ruleset/2.0.5.
Server: Apache/2.2.15 (Scientific Linux)

--e39f1539-Z--

Step 13:

Running the script mentioned in Step 5; got me this result:

Mod_Evasive working:


bhaskar@Scientific-Linux_12:30:31_Wed Jan 25:~> sudo ./test.pl
[sudo] password for bhaskar:
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden

I believe this information gives you heads up.O yes,I must say this representation is very minimal in nature. So you are free to explore and share.

Hope this will help.

Cheers!
Bhaskar

Server monitoring by Monit and Munin

In this article I am going to show your how you can keep an eye on your server/desktop/laptop visually through web browser. For that I am going to use two tools to do the job for you; those are monit and munin .

I am on Debian Lenny to implement those two tools.So the first thing first get those software in the system.Here we go:

Monit:

Before try to install it I tried to query the existing package database to whether it installed or not(or I might have installed some time back!!)

bhaskar@bhaskar-laptop_18:12:03_Tue Nov 16:/etc/monit> sudo dpkg -s monit
Package: monit
Status: install ok installed
Priority: optional
Section: admin
Installed-Size: 696
Maintainer: Stefan Alfredsson
Architecture: i386
Version: 1:4.10.1-4
Depends: libc6 (>= 2.7-1), libssl0.9.8 (>= 0.9.8f-5)
Conffiles:
/etc/default/monit cf582dd57fac58748aba3d7cf174f011
/etc/monit/monitrc d0127e44088e2c13e6eaef8f3cb95c9f
/etc/init.d/monit 3c19420528fdb85fd2669f6f7257a552
Description: A utility for monitoring and managing daemons or similar programs
monit is a utility for monitoring and managing daemons or similar
programs running on a Unix system. It will start specified programs
if they are not running and restart programs not responding.
.
monit supports:
* Daemon mode - poll programs at a specified interval
* Monitoring modes - active, passive or manual
* Start, stop and restart of programs
* Group and manage groups of programs
* Process dependency definition
* Logging to syslog or own logfile
* Configuration - comprehensive controlfile
* Runtime and TCP/IP port checking (tcp and udp)
* SSL support for port checking
* Unix domain socket checking
* Process status and process timeout
* Process cpu usage
* Process memory usage
* Process zombie check
* Check the systems load average
* Check a file or directory timestamp
* Alert, stop or restart a process based on its characteristics
* MD5 checksum for programs started and stopped by monit
* Alert notification for program timeout, restart, checksum, stop
resource and timestamp error
* Flexible and customizable email alert messages
* Protocol verification. HTTP, FTP, SMTP, POP, IMAP, NNTP, SSH, DWP,
LDAPv2 and LDAPv3
* An http interface with optional SSL support to make monit
accessible from a webbrowser

It seems it’s there.Ok,now it has deflated lot of file in the system and as I am not going to mention those in details,but should show you where it kept :

bhaskar@bhaskar-laptop_18:17:15_Tue Nov 16:~> whereis monit
monit: /usr/sbin/monit /etc/monit /usr/share/man/man1/monit.1.gz

We should be concerned about the configuration file it.Because we need to define everything in this file to get noticed by it.I changed into /etc/monit dir ,where I found the config file named monitrc.Let’s have a view of it:


bhaskar@bhaskar-laptop_18:20:12_Tue Nov 16:~> cd /etc/monit
bhaskar@bhaskar-laptop_18:20:18_Tue Nov 16:/etc/monit> ls

monitrc
bhaskar@bhaskar-laptop_18:20:20_Tue Nov 16:/etc/monit> sudo vim monitrc
###############################################################################
2 ## Monit control file
3 ###############################################################################
4 ##
5 ## Comments begin with a '#' and extend through the end of the line. Keywords
6 ## are case insensitive. All path's MUST BE FULLY QUALIFIED, starting with '/'.
7 ##
8 ## Below you will find examples of some frequently used statements. For
9 ## information about the control file, a complete list of statements and
10 ## options please have a look in the monit manual.
11 ##
12 ##
13 ###############################################################################
14 ## Global section
15 ###############################################################################
16 ##
17 ## Start monit in the background (run as a daemon) and check services at
18 ## 2-minute intervals.
19 #
20 set daemon 60
21 #
22 #
23 ## Set syslog logging with the 'daemon' facility. If the FACILITY option is
24 ## omitted, monit will use 'user' facility by default. If you want to log to
25 ## a stand alone log file instead, specify the path to a log file
26 #
27 set logfile syslog facility log_daemon
28 #
29 #
30 ## Set the list of mail servers for alert delivery. Multiple servers may be
31 ## specified using comma separator. By default monit uses port 25 - this
32 ## is possible to override with the PORT option.
33 #
34 set mailserver bhaskar-laptop # primary mailserver
35 # backup.bar.baz port 10025, # backup mailserver on port 10025
36 # localhost # fallback relay
37 #
38 #
39 ## By default monit will drop alert events if no mail servers are available.
40 ## If you want to keep the alerts for a later delivery retry, you can use the
41 ## EVENTQUEUE statement. The base directory where undelivered alerts will be
42 ## stored is specified by the BASEDIR option. You can limit the maximal queue
43 ## size using the SLOTS option (if omitted, the queue is limited by space
44 ## available in the back end filesystem).
45 #
46 # set eventqueue
47 # basedir /var/monit # set the base directory where events will be stored
48 # slots 100 # optionaly limit the queue size
49 #
50 #
51 ## Monit by default uses the following alert mail format:
52 ##
53 ## --8<--
54 ## From: monit@$HOST # sender
55 ## Subject: monit alert -- $EVENT $SERVICE # subject
56 ##
57 ## $EVENT Service $SERVICE #
58 ## #
59 ## Date: $DATE #
60 ## Action: $ACTION #
61 ## Host: $HOST # body
62 ## Description: $DESCRIPTION #
63 ## #
64 ## Your faithful employee, #
65 ## monit #
66 ## --8<-- 67 ## 68 ## You can override this message format or parts of it, such as subject 69 ## or sender using the MAIL-FORMAT statement. Macros such as $DATE, etc. 70 ## are expanded at runtime. For example, to override the sender: 71 # 72 set mail-format { from: monit@bhaskar-laptop.localdomain } 73 # 74 # 75 ## You can set alert recipients here whom will receive alerts if/when a 76 ## service defined in this file has errors. Alerts may be restricted on 77 ## events by using a filter as in the second example below. 78 # 79 set alert root@bhaskar-laptop.localdomain # receive all alerts 80 # set alert manager@foo.bar only on { timeout } # receive just service- 81 # # timeout alert 82 # 83 # 84 ## Monit has an embedded web server which can be used to view status of 85 ## services monitored, the current configuration, actual services parameters 86 ## and manage services from a web interface. 87 # 88 set httpd port 2812 and 89 use address bhaskar-laptop # only accept connection from localhost 90 allow bhaskar-laptop # allow localhost to connect to the server and 91 allow admin:admin # require user 'admin' with password 'admin' 92 # 93 # 94 ############################################################################### 95 ## Services 96 ############################################################################### 97 ## 98 ## Check general system resources such as load average, cpu and memory 99 ## usage. Each test specifies a resource, conditions and the action to be 100 ## performed should a test fail. 101 # 102 check system bhaskar-laptop.localdomain 103 if loadavg (1min) > 4 then alert
104 if loadavg (5min) > 2 then alert
105 if memory usage > 75% then alert
106 if cpu usage (user) > 70% then alert
107 if cpu usage (system) > 30% then alert
108 if cpu usage (wait) > 20% then alert
109 #
110 #
111 ## Check a file for existence, checksum, permissions, uid and gid. In addition
112 ## to alert recipients in the global section, customized alert will be sent to
113 ## additional recipients by specifying a local alert handler. The service may
114 ## be grouped using the GROUP option.
115 #
116 check file apache_bin with path /usr/sbin/apache2
117 # if failed checksum and
118 # expect the sum 8f7f419955cefa0b33a2ba316cba3659 then unmonitor
119 if failed permission 755 then unmonitor
120 if failed uid root then unmonitor
121 if failed gid root then unmonitor
122 alert security@bhaskar-laptop.localdomain on {
123 permission, uid, gid, unmonitor
124 } with the mail-format { subject: Alarm! }
125 # group server
126 #
127 #
128 ## Check that a process is running, in this case Apache, and that it respond
129 ## to HTTP and HTTPS requests. Check its resource usage such as cpu and memory,
130 ## and number of children. If the process is not running, monit will restart
131 ## it by default. In case the service was restarted very often and the
132 ## problem remains, it is possible to disable monitoring using the TIMEOUT
133 ## statement. This service depends on another service (apache_bin) which
134 ## is defined above.
135 #
136 check process apache2 with pidfile /var/run/Apache2/apache2.pid
137 start program = "/etc/init.d/apache2 start"
138 stop program = "/etc/init.d/apache2 stop"
139 if cpu > 60% for 2 cycles then alert
140 if cpu > 80% for 5 cycles then restart
141 if totalmem > 200.0 MB for 5 cycles then restart
142 if children > 250 then restart
143 if loadavg(5min) greater than 10 for 8 cycles then stop
144 if failed host bhaskar-laptop.localdomain port 80 protocol http
145 and request "/monit/doc/next.php"
146 then restart
147 # if failed port 443 type tcpssl protocol http
148 # with timeout 15 seconds
149 # then restart
150 if 3 restarts within 5 cycles then timeout
151 depends on apache_bin
152 group server
153 #
154 #
155 ## Check device permissions, uid, gid, space and inode usage. Other services,
156 ## such as databases, may depend on this resource and an automatically graceful
157 ## stop may be cascaded to them before the filesystem will become full and data
158 ## lost.
159 #
160 # check device datafs with path /dev/sdb1
161 # start program = "/bin/mount /data"
162 # stop program = "/bin/umount /data"
163 # if failed permission 660 then unmonitor
164 # if failed uid root then unmonitor
165 # if failed gid disk then unmonitor
166 # if space usage > 80% for 5 times within 15 cycles then alert
167 # if space usage > 99% then stop
168 # if inode usage > 30000 then alert
169 # if inode usage > 99% then stop
170 # group server
171 #
172 #LVM
173
174 check device Bhaskar-laptop-data with path /lvm
175 if space usage > 80% then alert
176
177 #Tmp
178 check device tmp with path /tmp
179 if space usage > 90% then alert
180
181 ## Check a file's timestamp. In this example, we test if a file is older
182 ## than 15 minutes and assume something is wrong if its not updated. Also,
183 ## if the file size exceed a given limit, execute a script
184 #
185 # check file database with path /data/mydatabase.db
186 # if failed permission 700 then alert
187 # if failed uid data then alert
188 # if failed gid data then alert
189 # if timestamp > 15 minutes then alert
190 # if size > 100 MB then exec "/my/cleanup/script"
191 #
192 #
193 ## Check directory permission, uid and gid. An event is triggered if the
194 ## directory does not belong to the user with uid 0 and gid 0. In addition,
195 ## the permissions have to match the octal description of 755 (see chmod(1)).
196 #Bin
197 check directory bin with path /bin
198 if failed permission 755 then unmonitor
199 if failed uid 0 then unmonitor
200 if failed gid 0 then unmonitor
201 #
202 #LVM
203 check directory lvm with path /lvm
204 if failed uid 0 then unmonitor
205 if failed gid 0 then unmonitor
206
207 #Home
208 check directory home with path /home
209 if failed uid 0 then unmonitor
210 if failed gid 0 then unmonitor
211
212 # Var
213 check directory var with path /var
214 if failed uid 0 then unmonitor
215 if failed gid 0 then unmonitor
216
217
218
219
220 ## Check a remote host network services availability using a ping test and
221 ## check response content from a web server. Up to three pings are sent and
222 ## connection to a port and a application level network check is performed.
223 #
224 # check host myserver with address 192.168.1.1
225 # if failed icmp type echo count 3 with timeout 3 seconds then alert
226 # if failed port 3306 protocol mysql with timeout 15 seconds then alert
227 # if failed url
228 # http://user:password@www.foo.bar:8080/?querystring
229 # and content == 'action="j_security_check"'
230 # then alert
231 #
232 #Mysql
233
234 check process mysql with pidfile /var/run/mysqld/mysqld.pid
235 group database
236 start program = "/etc/init.d/mysql start"
237 stop program = "/etc/init.d/mysql stop"
238 if failed host 127.0.0.1 port 3306 then restart
239 if 5 restarts within 5 cycles then timeout
240
241 ###############################################################################
242 ## Includes
243 ###############################################################################
244 ##
245 ## It is possible to include additional configuration parts from other files or
246 ## directories.
247 #
248 # include /etc/monit.d/*
249 #
250 #
"monitrc" 250L, 9699C

As it is visible from the mundane configuration file that what we are trying to monitor.It has a big advantage that monit can take decision about the service i.e if some service is down and it needs to up,it can do so.It is just not mere status showing software.

Now we can configure it start when the system boots.So we will define a runlevels for it .We will use a software called sysv-rc-conf ,(aptitude install sysv-rc-conf).Here is invocation of it:

sysv-rc-conf

sysv-rc-conf/>

Now you can see the highlighted section for the monit service.As I have mentioned in configuration file that the web interface of it can be accessed through port 2812 .Here is the invocation through browser:

Monit Web Interface

I hope enlarging those two above picture will give you enough insight that what you can do with it.Now if you click on any of the service on the left side of panel you can get a detailed view like below:

service-details

The above screen has a “Disable Monitoring” button at the bottom of the screen,so with that you can deactivate particular device or thing monitoring.

Munin:
It is basically a graphing system to plot thing on the browser to get a visual representation of activity happening on the network or particular device.Let’s check out whether I have it or not in y system:


bhaskar@bhaskar-laptop_18:38:14_Tue Nov 16:~> sudo dpkg -s munin
[sudo] password for bhaskar:
Package: munin
Status: install ok installed
Priority: optional
Section: net
Installed-Size: 996
Maintainer: Munin Debian Maintainers
Architecture: all
Version: 1.2.6-10~lenny2
Depends: perl (>= 5.6.0-16), perl-modules | libparse-recdescent-perl, librrds-perl, libhtml-template-perl, libdigest-md5-perl, libtime-hires-perl, libstorable-perl, rrdtool, adduser
Recommends: munin-node, libdate-manip-perl
Suggests: www-browser, httpd
Conffiles:
/etc/cron.d/munin 98f4112ea36053af9e1dc9111ab4d973
/etc/munin/munin.conf 057d322c5776710b8b71fbf02b12edbc
/etc/munin/templates/munin-comparison-month.tmpl 31f92013656bc96f496ad9fe9bd87b8b
/etc/munin/templates/munin-comparison-year.tmpl f8fc458757219e152bc0c316208214c4
/etc/munin/templates/definitions.html 6f2cda49ff5f0a5641549ae0dd063334
/etc/munin/templates/munin-nodeview.tmpl 60791f957f0879b859274ac423850e59
/etc/munin/templates/munin-serviceview.tmpl 9d061d0a097fdedc7cec09da56b45170
/etc/munin/templates/munin-comparison-week.tmpl 0ed0ac1772a96108e621f7ec9e651e65
/etc/munin/templates/logo.png 385010f8f050d25723206b1c77f0df5e
/etc/munin/templates/munin-comparison-day.tmpl 487b8c7f6f1eaf19687d601621da6f06
/etc/munin/templates/munin-overview.tmpl 07b6ba2c872f737fd3f2bf3df82bee06
/etc/munin/templates/munin-domainview.tmpl dfa7d0b5372086423c2aa7476bd04b90
/etc/munin/templates/style.css e6f61ecb33988635e5f6961de96c71c3
/etc/logrotate.d/munin caf8f6b63086ec5e11a9a2e2d883c7a1
Description: network-wide graphing framework (grapher/gatherer)
Munin is a highly flexible and powerful solution used to create graphs of
virtually everything imaginable throughout your network, while still
maintaining a rattling ease of installation and configuration.
.
This package contains the grapher/gatherer. You will only need one instance of
it in your network. It will periodically poll all the nodes in your network
it's aware of for data, which it in turn will use to create graphs and HTML
pages, suitable for viewing with your graphical web browser of choice.
.
It is also able to alert you if any value is outside of a preset boundary,
useful if you want to be alerted if a filesystem is about to grow full, for
instance. You can do this by making Munin run an arbitrary command when you
need to be alert it, or make use of the intrinsic Nagios support.
.
Munin is written in Perl, and relies heavily on Tobi Oetiker's excellent
RRDtool. To see a real example of Munin in action, you can follow a link
from to a live installation.
Homepage: http://munin.projects.linpro.no

It seems that I have it.So the next thing to where it reside in the system :

bhaskar@bhaskar-laptop_18:57:10_Tue Nov 16:~> whereis munin
munin: /etc/munin /usr/share/munin

Oh! I forgot to tell you that I need one more piece of software called “minin-node” . Let’s check out:


bhaskar@bhaskar-laptop_18:58:53_Tue Nov 16:~> sudo dpkg -s munin-node
Package: munin-node
Status: install ok installed
Priority: optional
Section: net
Installed-Size: 1396
Maintainer: Munin Debian Maintainers
Architecture: all
Source: munin
Version: 1.2.6-10~lenny2
Depends: perl (>= 5.6.0-16), libnet-server-perl, procps, adduser, lsb-base (>= 3.2-4), gawk
Recommends: libnet-snmp-perl
Suggests: munin, munin-plugins-extra, libwww-perl, liblwp-useragent-determined-perl, libnet-irc-perl, mysql-client, smartmontools (>= 5.37-6~bpo40+1), acpi | lm-sensors, python, ethtool, libdbd-pg-perl
Conffiles:
/etc/cron.d/munin-node 64b993c241bef6ad98b0f50f0de9d18b
/etc/init.d/munin-node 0a2e199d22c98af892cc407c63dddb5a
/etc/munin/munin-node.conf c317597f98622746dc2120d4aa1ace17
/etc/munin/plugin-conf.d/munin-node 686c0aa6a0a3eb4e973f162dc77ffe52
/etc/logrotate.d/munin-node 8afe5ab15b1f1731016d0bffadadff46
Description: network-wide graphing framework (node)
Munin is a highly flexible and powerful solution used to create graphs of
virtually everything imaginable throughout your network, while still
maintaining a rattling ease of installation and configuration.
.
This package contains the daemon for the nodes being monitored. You should
install it on all the nodes in your network. It will know how to extract all
sorts of data from the node it runs on, and will wait for the gatherer to
request this data for further processing.
.
It includes a range of plugins capable of extracting common values such as cpu
usage, network usage, load average, and so on. Creating your own plugins which
are capable of extracting other system-specific values is very easy, and is
often done in a matter of minutes. You can also create plugins which relay
information from other devices in your network that can't run Munin, such as a
switch or a server running another operating system, by using SNMP or similar
technology.
.
Munin is written in Perl, and relies heavily on Tobi Oetiker's excellent
RRDtool. To see a real example of Munin in action, you can follow a link
from to a live installation.
Homepage: http://munin.projects.linpro.no

Now I changed into the /etc/munin directory ,because I need to change the configuration file of it.Like below:

bhaskar@bhaskar-laptop_19:03:28_Tue Nov 16:/etc/munin> ls
munin.conf munin-node.conf plugin-conf.d plugins templates

Now have a look at the munin.conf file:

1 # Example configuration file for Munin, generated by 'make build'
2
3 # The next three variables specifies where the location of the RRD
4 # databases, the HTML output, and the logs, severally. They all
5 # must be writable by the user running munin-cron.
6 dbdir /var/lib/munin
7 htmldir /var/www/munin
8 logdir /var/log/munin
9 rundir /var/run/munin
10
11 # Where to look for the HTML templates
12 tmpldir /etc/munin/templates
13
14 # Make graphs show values per minute instead of per second
15 #graph_period minute
16
17 # Graphics files are normaly generated by munin-graph, no matter if
18 # the graphs are used or not. You can change this to
19 # on-demand-graphing by following the instructions in
20 # http://munin.projects.linpro.no/wiki/CgiHowto
21 #
22 #graph_strategy cgi
23
24 # Drop somejuser@fnord.comm and anotheruser@blibb.comm an email everytime
25 # something changes (OK -> WARNING, CRITICAL -> OK, etc)
26 #contact.someuser.command mail -s "Munin notification" somejuser@fnord.comm
27 #contact.anotheruser.command mail -s "Munin notification" anotheruser@blibb.comm
28 #
29 # For those with Nagios, the following might come in handy. In addition,
30 # the services must be defined in the Nagios server as well.
31 #contact.nagios.command /usr/sbin/send_nsca -H nagios.host.com -c /etc/send_nsca.cfg
32
33 # a simple host tree
34 [bhaskar-laptop.localdomain]
35 address 127.0.0.1
36 use_node_name yes
37
38 #
39 # A more complex example of a host tree
40 #
41 ## First our "normal" host.
42 # [fii.foo.com]
43 # address foo
44 #
45 ## Then our other host...
46 # [fay.foo.com]
47 # address fay
48 #
49 ## Then we want totals...
50 # [foo.com;Totals] #Force it into the "foo.com"-domain...
51 # update no # Turn off data-fetching for this "host".
52 #
53 # # The graph "load1". We want to see the loads of both machines...
54 # # "fii=fii.foo.com:load.load" means "label=machine:graph.field"
55 # load1.graph_title Loads side by side
56 # load1.graph_order fii=fii.foo.com:load.load fay=fay.foo.com:load.load
57 #
58 # # The graph "load2". Now we want them stacked on top of each other.
59 # load2.graph_title Loads on top of each other
60 # load2.dummy_field.stack fii=fii.foo.com:load.load fay=fay.foo.com:load.load
61 # load2.dummy_field.draw AREA # We want area instead the default LINE2.
62 # load2.dummy_field.label dummy # This is needed. Silly, really.
63 #
64 # # The graph "load3". Now we want them summarised into one field
65 # load3.graph_title Loads summarised
66 # load3.combined_loads.sum fii.foo.com:load.load fay.foo.com:load.load
67 # load3.combined_loads.label Combined loads # Must be set, as this is
68 # # not a dummy field!
69 #
70 ## ...and on a side note, I want them listen in another order (default is
71 ## alphabetically)
72 #
73 # # Since [foo.com] would be interpreted as a host in the domain "com", we
74 # # specify that this is a domain by adding a semicolon.
75 # [foo.com;]
76 # node_order Totals fii.foo.com fay.foo.com
77 #
78

I have bold the section in the file ; which is absolute must get going with it. If the directory is not present ,then please create it and point the right path.

Now take a look at the munin-node.conf file:

1 #
2 # Example config-file for munin-node
3 #
4
5 log_level 4
6 log_file /var/log/munin/munin-node.log
7 pid_file /var/run/munin/munin-node.pid
8
9 background 1
10 setseid 1
11
12 user munin
13 group munin
14 setsid yes
15
16 # Regexps for files to ignore
17
18 ignore_file ~$
19 ignore_file \.bak$
20 ignore_file %$
21 ignore_file \.dpkg-(tmp|new|old|dist)$
22 ignore_file \.rpm(save|new)$
23 ignore_file \.pod$
24
25 # Set this if the client doesn't report the correct hostname when
26 # telnetting to localhost, port 4949
27 #
28 #host_name localhost.localdomain
29
30 # A list of addresses that are allowed to connect. This must be a
31 # regular expression, due to brain damage in Net::Server, which
32 # doesn't understand CIDR-style network notation. You may repeat
33 # the allow line as many times as you'd like
34
35 allow ^127\.0\.0\.1$
36
37 # Which address to bind to;
38 host *
39 # host 127.0.0.1
40
41 # And which port
42 port 4949
43

So once more I have highlighted few thing in the this file to get going with it.And most of the thing are pretty easily understood thing.

Lets access it through browser to see the graph..here we go..this the first screen I got in my system:

Ok once I clicked on hyperlinked option I am presented with the graphs like below:

Ok, now if your click those graph then you can get little explanation of the graph too!!

Hope this will help.

Cheers!
Bhaskar

Password-less ssh

As the title said I am going to show you that how you can use the built-in mechanism to avoid typing your password at the terminal when connecting through ssh(secure shell) to the remote computer.

I am assuming both the computers(or as many we want to connect) has the required software to play with.I mean that both the boxes has openssh installed and well configured.So first thing first,we need to generate the keys.One is private(which should not be shared) and the public key(which should be shared).

Here is how it can be done…


bhaskar@bhaskar-laptop_08:58:56_Sat Oct 30:~> sudo /usr/bin/ssh-keygen -t rsa

It will ask you for the passphrase(password with space separated words).Once you have done that it will store the public key and private key in the specific users .ssh directory.And the public key file is ended with .pub extension.

Now try to figure out wether ssh-agent is running or not? Now a bit of explanation about it like this:ssh-agent is a program to hold private keys used for public key authentication (RSA, DSA). The idea is that ssh-agent is started in the beginning of an X-session or a login session, and all other windows or programs are started as clients to the ssh-agent program. Through use of environment variables the agent can be located and automatically used for authentication when logging in to other machines using ssh(1).

So how to detect it? Here is the way to do it :

bhaskar@bhaskar-laptop_09:07:26_Sat Oct 30:~> sudo echo $SSH_AGENT_PID
Password:
3482

So it’s running! If it is not running then start a new one like this :

bhaskar@bhaskar-laptop_09:07:51_Sat Oct 30:~> sudo eval $(ssh_agent)

Now tell it the key by running ssh-add .What does ssh-add do?? Here is explanation from the man page itself: ssh-add adds RSA or DSA identities to the authentication agent, ssh-agent(1). When run without arguments, it adds the files ~/.ssh/id_rsa, ~/.ssh/id_dsa and ~/.ssh/identity. After loading a private key, ssh-add will try to load corresponding certificate information from the filename obtained by appending -cert.pub to the name of the private key file. Alternative file names can be given on the command line.Right?

Now run :


bhaskar@bhaskar-laptop_09:13:11_Sat Oct 30:~> sudo ssh-add

and enter your passphrase. You’ll need to do this each time you log in; if you’re using X, try adding


SSH_ASKPASS=ssh-askpass ssh-add

to your .xsession file. (You may need to install ssh-askpass.) Now for each server you log into, create the directory ~/.ssh and copy the file ~/.ssh/id_rsa.pub into it as ~/.ssh/authorized_keys . If you started the ssh-agent by hand, kill it with

bhaskar@bhaskar-laptop_09:15:19_Sat Oct 30:~> sudo ssh-agent -k

when you log out.

Hope this will help.

Cheers!
Bhaskar

PAM : Pluggable Authentication Modules

In this article we will explore PAM ,which is a research over the internet and found so many wonderful article related to this topic written by some great guys.Kindly look into resources section of this article(at the bottom) to find the article glue with it.I am just trying to reproduce the great work done by others in those article and after going through all of those to understand how it work underneath.It is a very very important tool for any open system administrators.And not to mention that a complex topic to master,but once grasp one can do hell lot of thing with this to make system infrastructure more effective and secure.

PAM (Pluggable Authentication Modules) is a suite of shared libraries that enable the local system administrator to choose how applications authenticate users.

The function of the configuration file(s) is to provide a mapping from the application’s service name to a selection of modules that provide authentication services to the raw application. When a pam aware application with a file in /etc/pam.d starts, the PAM library loads the configuration for the specified service and constructs four module chains (one for each facility.) If the configuration does not specify any modules for one or more facilities, the configuration for the other service is used instead for these facilities.

Linux as a server, can provide several different services (e.g., web, ftp with areas restricted by password control). Through the use of modules, PAM can enable a program to search through several different password databases, even if that program is not explicitly coded for that particular database.

Here are some examples of the possibilities that this enables.

  • Apache has a module that provides PAM services. Now authentication to use particular directories can be conducted by PAM, which means that the range of modules that are available to PAM can be used, including RADIUS, NIS, NCP (which means that Novell password databases can be used).
  • pppd has a PAMified version (available from RedHat) Now it is possible to use a series of databases to authenticate ppp users. In addition to the normal Linux-based password databases (such as /etc/passwd and /etc/shadow), you can use PAM modules to authenticate against Novell password databases or NT-based password databases.
  • The preceding two examples can be combined. Imagaine that the persons in your office or department are already registered with a username and password in a Novell or NT LAN. If you wanted to use this database on your Linux server (for PPP access, for web access, or even for normal shell access), you can use PAM to authenticate against this existing database, rather than maintain a separate database on both Linux and the LAN server.

PAM configuration files, located in /etc/pam.d and named for the service which they control have three fields, with optional fourth and greater fields. The first field in the configuration file is the module-type indicatiing which of four PAM management services the correspoding module will provide to the application. PAM deals with four separate types of management services. The type token tells PAM what type of authentication is to be used for this module. Modules of the same type can be “stacked”, requiring a user to meet multiple requirements to be authenticated. The four types of management services are: authentication management; account management; session management; and password management.

auth

Determines whether the user is who they claim to be, usually by a password, but perhaps by a more sophistcated means, such as biometrics.

account

Determines whether the user is allowed to access the service. This is different from establishing whether the user is who they say they are. Account management deals with enforcing the expiration of passwords and preventing logins during system time.

password

Provides a mechanism for the user to change their authentication. Again, this usually their password.

session

Things that should be done before and/or after the user is authenticed. This might included things such as mounting/unmounting the user home directory, logging their login/logout, and restricting/unrestricting the services available to the user.

Control:

PAM modules can be stacked – there can be any number of modules of the same module type for a single application. The application is not told of the individual success or failure of any module, only of the success or failure of the stack. The control flags determine how each module affects the success or failure of the stack. Modules in the stack are executed in the order they are listed in the configuration file.

The second field in the configuration file is the control token, which tells PAM what should be done in if authentication by this module fails. PAM recognizes four control types: required, requisite, sufficient, and optional.

requisite
The module must succeed for the stack of this module type to succeed. Failure to authenticate via this module results in immediate denial of authentication.

required
The module must succeed for the stack of this module type to succeed. Failure also results in denial of authentication, although PAM will still call all the other modules listed for this service before denying authentication.

sufficient
Success of this module is sufficient for the stack of this module type to succeed. If authentication by this module is successful, PAM will grant authentication.

optional
Not critical to the success or failure of the stack. If at least one non-optional module succeeds or fails, the result of this module is ignored when calculating the success or failure of the stack. Whether this module succeeds or fails is only significant if it is the only module of its type for this service.

Module Path:

The module-path tells PAM which module to use and (optionally) where to find it. Most configurations only contain the module’s name. Since Linux-PAM-0.56 was released there is support for a default authentication-module directory, and a full path is no longer required, only the name of the module. PAM looks for the modules in the default PAM module directory, normally /usr/lib/security. However, if your linux distribution conforms to the Linux Filesystem standard, PAM modules can be found in /lib/security.

Module Arguments:

Any further fields contain any arguments to the module. Each module has its own arguments. For example, in our login configuration, the “nulok” (“null ok”, argument being passed to pam_unix.so module, indicating the a blank (“null”) password is acceptable (“ok”).

The following are a list of module options that are likely to be recognize by all modules:

  • debugUse the syslog(3) call to log debugging information to the system log files.
  • no_warn
  • Instruct module to not give warning messages to the application.
  • use_first_pass The module should not prompt the user for a password. Instead, it should obtain the previously typed password (from the preceding auth module), and use that. If that doesn’t work, then the user will not be authenticated. (This option is intended for auth and password modules only).
  • try_first_pass The module should attempt authentication with the previously typed password (from the preceding auth module). If that doesn’t work, then the user is prompted for a password. (This option is intended for auth modules only).
  • use_mapped_pass This argument is not currently supported by any of the modules in the Linux-PAM distribution because of possible consequences associated with U.S. encryption exporting restrictions. Within the U.S., module developers are, of course, free to implement it (as are developers in other countries). For compatibility reasons we describe its use as suggested in the DCE-RFC 86.0, see section bibliography for a pointer to this document.The use_mapped_pass argument instructs the module to take the clear text authentication token entered by a previous module (that requests such a token) and use it to generate an encryption/decryption key with which to safely store/retrieve the authentication token required for this module. In this way the user can enter a single authentication token and be quietly authenticated by a number of stacked modules. Obviously a convenient feature that necessarily requires some reliably strong encryption to make it secure. This argument is intended for the auth and password module types only.
  • expose_account In general the leakage of some information about user accounts is not a secure policy for modules to adopt. Sometimes information such as users names or home directories, or preferred shell, can be used to attack a user’s account. In some circumstances, however, this sort of information is not deemed a threat: displaying a user’s full name when asking them for a password in a secured environment could also be called being friendly. The expose_account argument is a standard module argument to encourage a module to be less discrete about account information as it is deemed appropriate by the local administrator.

Example configuration file entries

Let’s look at some examples of pam configuration files. The first example is for the other or default service. If there is not a specific pam configuration file in /etc/pam.d for a service, this is the configuration file that can be used to ease the integration of new services by providing a default selection of modules appropriate to the local security policy. Or, it can be used to deny access to any application that does not have a specific /etc/pam.d entry. The fields in the configuration file are module-type, control-flag and module-filename. Any other fields are optional arguments that are specific to the individual modules.

Default policy

If a system is to be considered secure, it had better have a reasonably secure other entry. The following is a paranoid setting (which is not a bad place to start!):

#
# default configuration: /etc/pam.d/other
#
auth required pam_deny.so
account required pam_deny.so
password required pam_deny.so
session required pam_deny.so

While fundamentally a secure default, this won’t give the administrator any feedback about a misconfigured system. For example, such a system is vulnerable to locking everyone out should the configuration file for a specific service be badly written.

The module pam_deny is not very sophisticated, it logs no information when it is invoked. Unless the users of a system contact the administrator when failing to execute a service application, the administrator may go for a long not knowing that his system is mis-configured.

By changing the configuration to the example below would provide a suitable warning to the administrator. Notice the the stacking of pam_warn.so and pam_deny.so.

#
# default configuration: /etc/pam.d/other
#
auth required pam_deny.so
auth required pam_warn.so
account required pam_deny.so
account required pam_warn.so
password required pam_deny.so 

password required pam_warn.so
session required pam_deny.so
session required pam_warn.so

With this configuration, whenever an unknown service attempts to access any of the four configuration types, PAM denies authentication (via the pam_deny.so module) and then logs a syslog warning (via the pam_warn.so module). Short of a bug in PAM, this configuration is brutally secure. The only problem with that brutality is it may cause problems if your accidentally delete the configuration of another service. If your /etc/pam.d/login was mistakenly deleted, no one would be able to login!

Here’s a little gentler configuration

#
# default configuration: /etc/pam.d/other
#
auth requisite pam_securetty.so
auth required pam_unix.so
auth required pam_warn.so
account required pam_unix.so
account required pam_warn.so
password required pam_unix.so
password required pam_warn.so
session required pam_unix.so
session required pam_warn.so.

The first module (pam_securetty.so) checks to see if the user is root and prevents root from logging in from an insecure terminal. The value requisite for control-flag is used to force immediate authentication failure if the securetty module fails. If this occurs, no more of the auth modules are executed. This has the benefit of preventing root from mistakenly typing a password over an insecure terminal line. This configuration will allow an unknown service to authenticate (via the pam_unix.so module), although it will not allow it to change the user’s password. Although it allows authentication by unknown services, it logs a syslog warning whenever such a service attempts authentication.

A word on null passwords

On many linux systems there are a number of accounts used to assign privileges to system services like ftp, apache, news, and databases. These accounts allow services to run as unprivileged users, providing a level of security, because an intruder that compromises the service only has the limited privileges available to that service, rather than the privileges of root. However, allowing these accounts login privileges is a security risk, as they usually have blank (null) passwords. The nullok options-argument allows passwordless accounts. It is recommended you remove this argument from any modules of auth type for services that allow login. This is usually the login service, may also include services like rlogin and ssh. So the following line in /etc/pam.d/login:

auth required pam_unix.so nullok

Should be changed to:

auth required pam_unix.so

Disable unused services

If you find you have pam configuration files in /etc/pam.d/ that you’re not using, you may want to rename or remove them to prevent their unauthorized use. For example, if you’re not using graphical login (Red Hat runlevel 5) then you might want to rename /etc/pam.d/xdm to /etc/pam.d/noxdm. Not finding the file named after the service requesting authentication, PAM will fall back to the /etc/pam.d/other. If you later want to enable the service, rename to it’s original name and everything will work as it was intended.

Basic PAM modules

pam_unix.so

This module provides traditional Unix authentication, password management, and user account setup. It uses standard system calls to retrieve and set password and account information, and relies on /etc/shadow and /etc/passwd.

  • accountEstablishes the validity of the user’s account and password and may offer advice on changing the user’s password, or force a password change. The actions this module performs are controlled by the /etc/passwd and /etc/shadow files.Arguments: audit, debug.
  • authThis component of the module checks the user’s password against the password databases. Configuration for this component is done in /etc/nsswitch.conf. An additional binary, unix_chkpwd, is used to allow the component to read protected databases without requiring the whole module to be setuid root.Arguments: audit, debug, nodelay, nullok, try_first_pass, use_first_pass.
  • passwordThis component changes the user’s password. The module pam_cracklib.so can be stacked with this component to check password security.Arguments: audit, bigcrypt, debug, md5, nis, not_set_pass, nullok, remember, try_first_pass, use_authtok, and use_first_pass.
  • sessionThis component logs the user name and session type to syslog, at the start and end of the user’s session. There are no arguments to this component.
  • arguments
    • audit A more extensive form of debug
    • bigcrypt Use the DEC “C2” extension to crypt().
    • debug – Log information using syslog
    • md5 – Use md5 encryption instead of crypt().
    • nis – Use NIS (Network Information Service) passwords.
    • nodelay – By default, the module requests a delay-on-failure of a second. This argument overrides the default.
    • not_set_pass – Don’t use the passwords from other stacked modules. Don’t give the new password to other stacked modules.
    • nullok – By default, if the official password is blank, the authentication fails. This argument overrides the default.
    • remember (remember=n) – Save n recent passwords to prevent the user from alternating passwords.
    • try_first_pass – Use the password from the previous stacked auth module, and prompt for a new password if the retrieved password is blank or incorrect.
    • use_authtok – Set the new password to the one provided by a previous module.
    • use_first_pass – Use the result from the previous stacked auth module, never prompts the user for a password, fails if the result was a fail.
pam_access.so

This module intercepts the user’s name and password. If the name is ftp or anonymous, the user’s password is broken up at the @ delimiter into a PAM_RUSER and a PAM_RHOST part; these pam-items being set accordingly. The username is set to ftp. In this case the module succeeds. Alternatively, the module sets the PAM_AUTHTOK item with the entered password and fails.

The behavior of the module can be modified with the following flags:

  • debug – log more information to with syslog(3).
  • users=XXX,YYY,… – instead of ftp or anonymous, provide anonymous login to the comma separated list of users; XXX,YYY,…. Should the applicant enter one of these usernames the returned username is set to the first in the list; “XXX”.
  • ignore – pay no attention to the email address of the user (if supplied).
pam_chroot.so

This module is intended to provide a transparent wrapper around the average user, one that puts them in a fake file-system (eg, their / is really /some/where/else

).

Useful if you have several classes of users, and are slightly paranoid about security. Can be used to limit who else users can see on the system, and to limit the selection of programs they can run.

pam_console.so

This module implements a console permission scheme similar to Solaris’ logindevperms. Allows for the permissioning of certain devices and files at login and logout time.

pam_cracklib.so

This module can be plugged into the password stack of a given application to provide some plug-in strength-checking for passwords.

This module works in the following manner:
it first calls the Cracklib routine to check the strength of the password; if crack likes the password, the module does an additional set of strength checks. These checks are:

  • Palindrome – Is the new password a palindrome of the old one?
  • Case Change Only – Is the new password the the old one with only a change of case?
  • Similar – Is the new password too much like the old one? This is primarily controlled by one argument, difok which is a number of characters that if different between the old and new are enough to accept the new password, this defaults to 10 or 1/2 the size of the new password whichever is smaller. To avoid the lockup associated with trying to change a long and complicated password, difignore is available. This argument can be used to specify the minimum length a new password needs to be before the difok value is ignored. The default value for difignore is 23.
  • Simple – Is the new password too small? This is controlled by 5 arguments minlen, dcredit, ucredit, lcredit, and ocredit. See the section on the arguments for the details of how these work and there defaults.
  • Rotated – Is the new password a rotated version of the old password?
  • Already used – Was the password used in the past? Previously used passwords are to be found in /etc/security/opasswd.

This module with no arguments will work well for standard unix password encryption. With md5 encryption, passwords can be longer than 8 characters and the default settings for this module can make it hard for the user to choose a satisfactory new password. Notably, the requirement that the new password contain no more than 1/2 of the characters in the old password becomes a non-trivial constraint. For example, an old password of the form the quick brown fox jumped over the lazy dogs would be difficult to change… In addition, the default action is to allow passwords as small as 5 characters in length. For a md5 systems it can be a good idea to increase the required minimum size of a password. One can then allow more credit for different kinds of characters but accept that the new password may share most of these characters with the old password.

pam_deny.so

This module can be used to deny access. It always indicates a failure to the application through the PAM framework. As is commented in the overview section above, this module might be suitable for using for default (the OTHER) entries.

pam_env.so

This module allows you to (un)set arbitrary environment variables using fixed strings, the value of previously set environment variables and/or PAM_ITEMs.

All is controlled via a configuration file (by default, /etc/security/pam_env.conf but can be overriden with conffile argument). Each line starts with the variable name, there are then two possible options for each variable DEFAULT and OVERRIDE. DEFAULT allows an administrator to set the value of the variable to some default value, if none is supplied then the empty string is assumed. The OVERRIDE option tells pam_env.so that it should enter in its value (overriding the default value) if there is one to use. OVERRIDE is not used, “” is assumed and no override will be done.

VARIABLE [DEFAULT=[value]] [OVERRIDE=[value]]

(Possibly non-existent) environment variables may be used in values using the ${string} syntax and (possibly non-existent) PAM_ITEMs may be used in values using the &commat;{string} syntax. Both the $ and &commat; characters can be backslash-escaped to be used as literal values (as in \$. Double quotes may be used in values (but not environment variable names) when white space is needed the full value must be delimited by the quotes and embedded or escaped quotes are not supported.

This module can also parse a file with simple KEY=VAL pairs on separate lines (/etc/environment by default). You can change the default file to parse, with the envfile flag and turn it on or off by setting the readenv flag to 1 or 0 respectively.

The behavior of this module can be modified with one of the following flags:

  • debug write more information to syslog(3).
  • conffile=filename by default the file /etc/security/pam_env.conf is used as the configuration file. This option overrides the default. You must supply a complete path + file name.
  • envfile=filename by default the file /etc/environment is used to load KEY=VAL pairs directly into the env. This option overrides the default. You must supply a complete path + file name.
  • readenv=0|1 turns on or off the reading of the file specified by envfile (0 is off, 1 is on). By default this option is on.
pam_filter.so

Each component of the module has the potential to invoke the desired filter. The filter is always execv(2)d with the privilege of the calling application and not that of the user. For this reason it cannot usually be killed by the user without closing their session.

The behavior of the module can be significantly altered by the arguments passed to it in the Linux-PAM configuration file:

  • debug – this option increases the amount of information logged to syslog(3) as the module is executed.
  • new_term – the default action of the filter is to set the PAM_TTY item to indicate the terminal that the user is using to connect to the application. This argument indicates that the filter should set PAM_TTY to the filtered pseudo-terminal.
  • non_term – don’t try to set the PAM_TTY item.
  • runX – in order that the module can invoke a filter it should know when to invoke it. This argument is required to tell the filter when to do this. The arguments that follow this one are respectively the full pathname of the filter to be run and any command line arguments that the filter might expect.Permitted values for X are 1 and 2. These indicate the precise time that the filter is to be run. To understand this concept it will be useful to have read the Linux-PAM Module developer’s guide. Basically, for each management group there are up to two ways of calling the module’s functions.

In the case of the authentication and session components there are actually two separate functions. For the case of authentication, these functions are _authenticate and _setcred – here run1 means run the filter from the _authenticate function and run2 means run the filter from _setcred. In the case of the session modules, run1 implies that the filter is invoked at the _open_session stage, and run2 for _close_session.

For the case of the account component. Either run1 or run2 may be used.

For the case of the password component, run1 is used to indicate that the filter is run on the first occasion _chauthtok is run (the PAM_PRELIM_CHECK phase) and run2 is used to indicate that the filter is run on the second occasion (the PAM_UPDATE_AUTHTOK phase).

pam_ftp.so

This module intercepts the user’s name and password. If the name is ftp or anonymous, the user’s password is broken up at the @ delimiter into a PAM_RUSER and a PAM_RHOST part; these pam-items being set accordingly. The username (PAM_USER) is set to ftp. In this case the module succeeds. Alternatively, the module sets the PAM_AUTHTOK item with the entered password and fails.

The behavior of the module can be modified with the following flags:

  • debug – log more information to with syslog(3).
  • users=XXX,YYY,… – instead of ftp or anonymous, provide anonymous login to the comma separated list of users; XXX,YYY,…. Should the applicant enter one of these usernames the returned username is set to the first in the list; XXX.
  • ignore – pay no attention to the email address of the user (if supplied).
pam_group.so

This module does not authenticate the user, but instead it grants group memberships (in the credential setting phase of the authentication module) to the user. Such memberships are based on the service they are applying for. The group memberships are listed in text form in the /etc/security/group.conf file.

pam_issue.so

This module allows you to prepend an issue file to the username prompt. It also by default parses escape codes in the issue file similar to some common getty’s (using \x format).

Recognized escapes:

  • d – current date
  • s – operating system name
  • l – name of this tty
  • m – architecture of this system (i686, sparc, powerpc, …)
  • n – hostname of this system
  • o – domainname of this system
  • r – release number of the operation system (eg. 2.2.12)
  • t – current time
  • u – number of users currently logged in
  • U – same as u, except it is suffixed with “user” or “users” (eg. “1 user” or “10 users”
  • v – version/build-date of the operating system (eg. “#3 Mon Aug 23 14:38:16 EDT 1999” on Linux).

The behavior of this module can be modified with one of the following flags:

  • issue – the file to output if not using the default
  • noesc – turns off escape code parsing
pam_krb5.so

pam_krb5.so is designed to allow smooth integration of Kerberos 5 password- checking with applications built using PAM. It also supports session-specific ticket files (which are neater), and Kerberos IV ticket file grabbing. Its main use is as an authentication module, but it also supplies the same functions as a session-management module to better support poorly-written applications, and a couple of other workarounds as well. It also supports account management and password-changing.

When a user logs in, the module’s authentication function performs a simple password check and, if possible, obtains Kerberos 5 and Kerberos IV credentials, caching them for later use. When the application requests initialization of credentials (or opens a session), the usual ticket files are created. When the application subsequently requests deletion of credentials or closing of the session, the module deletes the ticket files.

pam_lastlog.so

This module can be used to provide a Last login on … message. when the user logs into the system from what ever application uses the PAM libraries. In addition, the module maintains the /var/log/lastlog file.

The behavior of this module can be modified with one of the following flags:

  • debug – write more information to syslog(3).
  • nodate – neglect to give the date of the last login when displaying information about the last login on the system.
  • noterm – neglect to diplay the terminal name on which the last login was attempt.
  • nohost – neglect to indicate from which host the last login was attempted.
  • silent – neglect to inform the user about any previous login: just update the /var/log/lastlog file.
  • never – if the /var/log/lastlog file does not contain any old entries for the user, indicate that the user has never previously logged in with a welcome… message.
pam_ldap.so

This is a relatively new module that allows the use of ldap instead of something like NIS or NIS+ to do distributed authentication.

pam_limits.so

Through the contents of the configuration file, /etc/security/limits.conf, resource limits are placed on users’ sessions. Users of uid=0 are not affected by this restriction.

The behavior of this module can be modified with the following arguments:

  • debug – verbose logging to syslog(3).
  • conf=/path/to/file.conf – indicate an alternative limits configuration file to the default.
  • change_uid – change real uid to the user for who the limits are set up. Use this option if you have problems like login not forking a shell for user who has no processes. Be warned that something else may break when you do this.
  • utmp_early – some broken applications actually allocate a utmp entry for the user before the user is admitted to the system. If some of the services you are configuring PAM for do this, you can selectively use this module argument to compensate for this behavior and at the same time maintain system-wide consistency with a single limits.conf file.
pam_listfile

The module gets the item of the type specified – user specifies the username, PAM_USER; tty specifies the name of the terminal over which the request has been made, PAM_TTY; rhost specifies the name of the remote host (if any) from which the request was made, PAM_RHOST; and ruser specifies the name of the remote user (if available) who made the request, PAM_RUSER – and looks for an instance of that item in the file filename. filename contains one line per item listed. If the item is found, then if sense=allow, PAM_SUCCESS is returned, causing the authorization request to succeed; else if sense=deny, PAM_AUTH_ERR is returned, causing the authorization request to fail.

If an error is encountered (for instance, if filename does not exist, or a poorly-constructed argument is encountered), then if onerr=succeed, PAM_SUCCESS is returned, otherwise if onerr=fail, PAM_AUTH_ERR or PAM_SERVICE_ERR (as appropriate) will be returned.

An additional argument, apply=, can be used to restrict the application of the above to a specific user (apply=username) or a given group (apply=@groupname). This added restriction is only meaningful when used with the tty, rhost and shell items.

Besides this last one, all arguments should be specified; do not count on any default behavior, as it is subject to change.

No credentials are awarded by this module.

Classic ftpusers authentication can be implemented with this entry in /etc/pam.d/ftp

auth required pam_listfile.so onerr=succeed item=user sense-deny
file=/etc/ftpusers

Note, users listed in /etc/ftpusers file are (counterintuitively) not allowed access to the ftp service.

pam_mail.so

This module provides the you have new mail service to the user. It can be plugged into any application that has credential hooks. It gives a single message indicating the newness of any mail it finds in the user’s mail folder. This module also sets the Linux-PAM environment variable, MAIL, to the user’s mail directory.

The behavior of this module can be modified with one of the following flags:

  • debug – write more information to syslog(3).
  • dir=pathname – look for the users’ mail in an alternative directory given by pathname. The default location for mail is /var/spool/mail. Note, if the supplied pathname is prefixed by a `’, the directory is interpreted as indicating a file in the user’s home directory.
  • nopen – instruct the module to not print any mail information when the user’s credentials are acquired. This flag is useful to get the MAIL environment variable set, but to not display any information about it.
  • close – instruct the module to indicate if the user has any mail at the as the user’s credentials are revoked.
  • noenv – do not set the MAIL environment variable.
  • empty – indicate that the user’s mail directory is empty if this is found to be the case.
  • hash=hashcount – mail directory hash depth. For example, a hashcount of 2 would make the mailfile be /var/spool/mail/u/s/user.
  • standard – old style “You have…” format which doesn’t show the mail spool being used. this also implies empty
  • quiet – only report when there is new mail.
pam_mkhomedir.so

This module is useful for distributed systems where the user account is managed in a central database (such as NIS, NIS+, or LDAP) and accessed through multiple systems. It frees the administrator from having to create a default home directory on each of the systems by creating it upon the first successfully authenticated login of that user. The skeleton directory (usually /etc/skel/) is used to copy default files and also set’s a umask for the creation.

The behavior of this module can be modified with one of the following flags:

  • skel – The skeleton directory for default files to copy to the new home directory.
  • umask – An octal for of the same format as you would pass to the shells umask command.
pam_motd.so

This module allows you to have arbitrary motd’s (message of the day) output after a successful login. By default this file is /etc/motd, but is configurable to any file.

The behavior of this module can be modified with one of the following flags:

  • motd – the file to output if not using the default.
pam_nologin.so

Provides standard Unix nologin authentication. If the file /etc/nologin exists, only root is allowed to log in; other users are turned away with an error message (and the module returns PAM_AUTH_ERR or PAM_USER_UNKNOWN). All users (root or otherwise) are shown the contents of /etc/nologin.

If the file /etc/nologin does not exist, this module defaults to returning PAM_IGNORE, but the successok module argument causes it to return PAM_SUCCESS in this case.

The administrator can override the default nologin file with the file=pathname module argument.

pam_permit.so

No matter what management group, the action of this module is to simply return PAM_SUCCESS – operation successful.

In the case of authentication, the user’s name will be acquired. Many applications become confused if this name is unknown.

pam_pwdb.so

This module is a pluggable replacement for the pam_unix_.. modules. It uses the generic interface of the Password Database library libpwdb.

The debug argument makes the accounting functions of this module syslog(3) more information on its actions. (Remaining arguments supported by the other functions of this module are silently ignored, but others are logged as errors through syslog(3)).

Based on the following pwdb_elements: expire; last_change; max_change; defer_change; warn_change, this module performs the task of establishing the status of the user’s account and password. In the case of the latter, it may offer advice to the user on changing their password or, through the PAM_AUTHTOKEN_REQD return, delay giving service to the user until they have established a new password. The entries listed above are documented in the Password Database Library Guide (see pointer above). Should the user’s record not contain one or more of these entries, the corresponding shadow check is not performed.

pam_rhosts_auth.so

his module performs the standard network authentication for services, as used by traditional implementations of rlogin and rsh etc.

The authentication mechanism of this module is based on the contents of two files; /etc/hosts.equiv (or _PATH_HEQUIV in #include ) and /.rhosts. Firstly, hosts listed in the former file are treated as equivalent to the localhost. Secondly, entries in the user’s own copy of the latter file is used to map remote-host remote-user pairs to that user’s account on the current host. Access is granted to the user if their host is present in /etc/hosts.equiv and their remote account is identical to their local one, or if their remote account has an entry in their personal configuration file.

Some restrictions are applied to the attributes of the user’s personal configuration file: it must be a regular file (as defined by S_ISREG(x) of POSIX.1); it must be owned by the superuser or the user; it must not be writable by any user besides its owner.

The module authenticates a remote user (internally specified by the item PAM_RUSER) connecting from the remote host (internally specified by the item PAM_RHOST). Accordingly, for applications to be compatible this authentication module they must set these items prior to calling pam_authenticate(). The module is not capable of independently probing the network connection for such information.

In the case of root-access, the /etc/host.equiv file is ignored unless the hosts_equiv_rootok option should be used. Instead, the superuser must have a correctly configured personal configuration file.

The behavior of the module is modified by flags:

  • debug – log more information to syslog(3). (XXX – actually, this module does not do any logging currently, please volunteer to fix this!)
  • no_warn – do not give verbal warnings to the user about failures etc. (XXX – this module currently does not issue any warnings, please volunteer to fix this!)
  • no_hosts_equiv – ignore the contents of the /etc/hosts.equiv file.
  • hosts_equiv_rootok – allow the use of /etc/hosts.equiv for superuser. Without this option /etc/hosts.equiv is not consulted for the superuser account. This option has no effect if the no_hosts_equiv option is used.
  • no_rhosts – ignore the contents of all user’s personal configuration file /.rhosts.
  • privategroup – normally, the /.rhosts file must not be writable by anyone other than its owner. This option overlooks group write access in the case that the group owner of this file has the same name as the user being authenticated. To lessen the security problems associated with this option, the module also checks that the user is the only member of their private group.
  • promiscuous – A host entry of `+’ will lead to all hosts being granted access. Without this option, ‘+’ entries will be ignored. Note, that the debug option will syslog a warning in this latter case.
  • suppress – This will prevent the module from syslog(3)ing a warning message when this authentication fails. This option is mostly for keeping logs free of meaningless errors, in particular when the module is used with the sufficient control flag.
pam_rootok.so

This module is for use in situations where the superuser wishes to gain access to a service without having to enter a password.

This module authenticates the user if their uid is 0. Applications that are created setuid-root generally retain the uid of the user but run with the authority of an enhanced effective-uid. It is the real uid that is checked.

pam_securetty.so

Provides standard Unix securetty checking, which causes authentication for root to fail unless PAM_TTY is set to a string listed in the /etc/securetty file. For all other users, it succeeds.

For canonical usage, should be listed as a required authentication method before any sufficient authentication methods.

pam_shells.so

This module checks for the existence of a user’s shell in /etc/shells

pam_stack.so

from the man page

In a nutshell, pam_stack lets you “call”, from inside of the stack for a particular service, the stack defined for any another service. The intention is to allow multiple services to “include” a system-wide setup, so that when that setup needs to be changed, it need only be changed in one place.

pam_stress.so

A stress testing PAM module

pam_tally.so

This module maintains a count of attempted accesses, can reset count on success, can deny access if too many attempts fail.

pam_tally comes in two parts: pam_tally.so and pam_tally. The former is the PAM module and the latter, a stand-alone program. pam_tally is an (optional) application which can be used to interrogate and manipulate the counter file. It can display users’ counts, set individual counts, or clear all counts. Setting artificially high counts may be useful for blocking users without changing their passwords. For example, one might find it useful to clear all counts every midnight from a cron job.

The counts file is organized as a binary-word array, indexed by uid. You can probably make sense of it with od, if you don’t want to use the supplied application.

Note, there are some outstanding issues with this module: pam_tally is very dependent on getpw*() – a database of usernames would be much more flexible; the `keep a count of current logins’ bit has been #ifdef’d out and you can only reset the counter on successful authentication, for now.

The authentication component of this module increments the attempted login counter.

pam_time.so

Running a well regulated system occasionally involves restricting access to certain services in a selective manner. This module offers some time control for access to services offered by a system. Its actions are determined with a configuration file. This module can be configured to deny access to (individual) users based on their name, the time of day, the day of week, the service they are applying for and their terminal from which they are making their request.

This module bases its actions on the rules listed in its configuration file: /etc/security/time.conf. Each rule has the following form,

services;ttys;users;times

In words, each rule occupies a line, terminated with a newline or the beginning of a comment; a `#’. It contains four fields separated with semicolons, `;’. The fields are as follows:

  • services – a logic list of service names that are affected by this rule.
  • ttys – a logic list of terminal names indicating those terminals covered by the rule.
  • user – a logic list of usernames to which this rule applies

By a logic list we mean a sequence of tokens (associated with the appropriate PAM_ item), containing no more than one wildcard character; `*’, and optionally prefixed with a negation operator; `!’. Such a sequence is concatenated with one of two logical operators: & (logical AND) and | (logical OR). Two examples are: !morgan&!root, indicating that this rule does not apply to the user morgan nor to root; and tty*&!ttyp*, which indicates that the rule applies only to console terminals but not pseudoterminals.

  • times – a logic list of times at which this rule applies. The format of each element is a day/time-range. The days are specified by a sequence of two character entries. For example, MoTuSa, indicates Monday Tuesday and Saturday. Note that repeated days are unset; MoTuMo indicates Tuesday, and MoWk means all weekdays bar Monday. The two character combinations accepted are,Mo Tu We Th Fr Sa Su Wk Wd Al

    The last two of these being weekend days and all 7 days of the week respectively.

    The time range part is a pair of 24-hour times, HHMM, separated by a hyphen – indicating the start and finish time for the rule. If the finish time is smaller than the start time, it is assumed to apply on the following day. For an example, Mo1800-0300 indicates that the permitted times are Monday night from 6pm to 3am the following morning.

    Note, that the given time restriction is only applied when the first three fields are satisfied by a user’s application for service.

For convenience and readability a rule can be extended beyond a single line with a `\newline’.

pam_unix.so

This is the standard Unix authentication module. It uses standard calls from the system’s libraries to retrieve and set account information as well as authentication. Usually this is obtained from the /etc/passwd and the /etc/shadow file as well if shadow is enabled.

The debug argument makes the accounting functions of this module syslog(3) more information on its actions. (Remaining arguments supported by the other functions of this module are silently ignored, but others are logged as errors through syslog(3)). The audit argument causes even more logging.

Based on the following shadow elements: expire; last_change; max_change; min_change; warn_change, this module performs the task of establishing the status of the user’s account and password. In the case of the latter, it may offer advice to the user on changing their password or, through the PAM_AUTHTOKEN_REQD return, delay giving service to the user until they have established a new password. The entries listed above are documented in the GNU Libc info documents. Should the user’s record not contain one or more of these entries, the corresponding shadow check is not performed.

pam_userdb.so

Look up users in a .db database and verify their password against what is contained in that database.

This module is used to verify a username/password pair against values stored in a Berkeley DB database. The database is indexed by the username, and the data fields corresponding to the username keys are the passwords, in unencrypted form, so caution must be exercised over the access rights to the DB database itself..

The module will read the password from the user using the conversation mechanism. If you are using this module on top of another authentication module (like pam_pwdb😉 then you should tell that module to read the entered password from the PAM_AUTHTOK field, which is set by this module.

The action of the module may be modified from this default by one or more of the following flags in the /etc/pam.d/ file.

  • debug – Supply more debugging information to syslog(3).
  • icase – Perform the password comparisons case insensitive.
  • dump – dump all the entries in the database to the log (eek, don’t do this by default!)
  • db=XXXX – use the database found on pathname XXXX. Note that Berkeley DB usually adds the needed filename extension for you, so you should use something like /etc/foodata instead of /etc/foodata.db.
pam_warn.so

This module is principally for logging information about a proposed authentication or application to update a password.

Log the service, terminal, user, remote user and remote host to syslog(3). The items are not probed for, but instead obtained from the standard pam-items.

pam_wheel.so

This module is used to enforce the so-called wheel group. By default, it permits root access to the system if the applicant user is a member of the wheel group (better described as the group with group-id 0).

The action of the module may be modified from this default by one or more of the following flags in the /etc/pam.conf file.

  • debug – Supply more debugging information to syslog(3).
  • use_id – This option modifies the behavior of the module by using the current uid of the process and not the getlogin(3) name of the user. This option is useful for being able to jump from one account to another, for example with ‘su’.
  • trust – This option instructs the module to return PAM_SUCCESS should it find the user applying for root privilege is a member of the wheel group. The default action is to return PAM_IGNORE in this situation. By using the trust option it is possible to arrange for wheel-group members to become root without typing a password. USE WITH CARE.
  • deny – This is used to reverse the logic of the module’s behavior. If the user is trying to get uid=0 access and is a member of the wheel group, deny access (for the wheel group, this is perhaps nonsense!): it is intended for use in conjunction with the group= argument…
  • group=XXXX – Instead of checking the gid=0 group, use the user’s XXXX group membership for the authentication. Here, XXXX is the name of the group and not its numeric identifier.

To allow only members of the wheel group to become root through su, use the following line in /etc/pam.d/su:

auth required /lib/security/pam_wheel.so use_uid
pam_warn.so

This module logs information about an authentication or password change attempt to syslog.

This module has no arguments, and only auth and password components. Log the service, terminal, user, remote user and remote host to syslog(3). The items are not probed for, but instead obtained from the standard pam-items.

pam_xauth.so

This module is designed to forward xauth keys (sometimes referred to as “cookies”) between users.

Without pam_xauth, when xauth is enabled and a user uses the su command to assume superuser privileges, that user is not able to run X commands as root without somehow giving root access to the xauth key used for the current X session. pam_xauth solves the problem by forwarding the key from the user running su (the source user) to the user whose identity the source user is assuming (the target user) when the session is created, and destroying the key when the session is torn down.

Resources:

1) http://www.freebsd.org/doc/en_US.ISO8859-1/articles/pam/

2) http://www.kernel.org/pub/linux/libs/pam/FAQ

3) http://tldp.org/HOWTO/User-Authentication-HOWTO/index.html

4) http://www.linuxgeek.net/documentation/authentication#SECTION05010000000000000000

Hope this will help.

Cheers!

Bhaskar