Listing and cleaning out old xauth entries on CentOS 5

When we do a X-forwarding,

$ ssh -X somehost.com

and you if you do a xauth list to check on your X-forwarding session, you can see an xauth entry something like:

$ xauth list

..... 
current-local-server:17  MIT-MAGIC-COOKIE-1  395f7b22fb6087a29b5fb1c9e37577c0
.....

Somehow after exiting the X-forwarding, somehow the session is still found in the xauth list

To clear the xauth entries, you can take a look at Clean up old xauth entries

In that blog entries, the author,

$ xauth list | cut -f1 -d\  | xargs -i xauth remove {}

Additional Information - Critical Security Vulnerability: Bash Code Injection Vulnerability, aka Shellshock (CVE-2014-6271)

Security advisories had been released by the key vendors with regards to the BASH vulnerabilities affecting  their products.
Kindly refer to the link for more detailed information

i). Cisco
http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20140926-bash

ii) Oracle
http://www.oracle.com/technetwork/topics/security/alert-cve-2014-7169-2303276.html

iii) Juniper
http://kb.juniper.net/InfoCenter/index?page=content&id=JSA10648

iv)    Apple
No official  patch release – Coming soon
http://www.imore.com/apple-working-quickly-protect-os-x-against-shellshock-exploit

Critical Security Vulnerability: Bash Code Injection Vulnerability, aka Shellshock (CVE-2014-6271)

A critical vulnerability in the Bourne again shell commonly known as Bash that is  present in most Linux and UNIX distributions as well as Apple’s Mac OS X, had been found and administrators are being urged to patch and remediate immediately. Do read https://securityblog.redhat.com/2014/09/24/bash-specially-crafted-environment-variables-code-injection-attack/

The flaw discovered allows an attacker to remotely attach a malicious executable to a variable that is executed when Bash is invoked. 

Operating systems with updates include:
CentOS
Debian
Redhat
More info: https://access.redhat.com/articles/1200223

Proof-of-concept code for exploiting Bash-using CGI scripts to run code with the same privileges as the web server is already floating around the web. A simple Wget fetch can trigger the bug on a vulnerable system.

http://www.theregister.co.uk/2014/09/24/bash_shell_vuln/
http://www.wordfence.com/blog/2014/09/major-bash-vulnerability-disclosed-may-affect-a-large-number-of-websites-and-web-apps/

Diagnostic Steps
To test if your version of Bash is vulnerable to this issue, run the following command:

$ env x='() { :;}; echo vulnerable'  bash -c "echo this is a test"
If the output of the above command looks as follows:
vulnerable
this is a test

If you are using a vulnerable version of Bash. The patch used to fix this issue ensures that no code is allowed after the end of a Bash function. Thus, if you run the above example with the patched version of Bash, you should get an output similar to:

$ env x='() { :;}; echo vulnerable'  bash -c "echo this is a test"
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
this is a test

haproxy unable to bind socket

After confguring haproxy and when you start the haproxy services as you can find in
Install and Configure HAProxy on CentOS/RHEL 5/6, you might encounter the following error.

Starting haproxy: [WARNING] 265/233231 (20638) : config : log format ignored for proxy 'load-balancer-node' since it has no log address.
[ALERT] 265/233231 (20638) : Starting proxy load-balancer-node: cannot bind socket

To check whether what other services are listening to the port, do the following

# netstat -anop | grep ":3389"
tcp        0      0 0.0.0.0:3389                0.0.0.0:*                   LISTEN      20606/xrdp          off (0.00/0/0)

Stop the listening services

# service xrdp stop

Start the haproxy service

# service haproxy

You should not encounter any error now.                                                           [  OK  ]

Centrify Error - Not authenticated: while getting service credentials: No credentials found with supported encryption

I was not able to use authenticate with my password when I tried to logon with Putty. A closer look at the log file shows. Only the local account root was able to logon

Sep 17 12:00:00 node1 sshd[4725]: error: PAM: 
Authentication failure for user2 from 192.168.1.5
Sep 17 12:00:01 node1 adclient[7052]: WARN  audit User 'user2' not authenticated: 
while getting service credentials: 
No credentials found with supported encryption

The solution was very simple. Just restart the /etc/init.d/centrifydc and /etc/init.d/centrify-sshd

# service /etc/init.d/centrifydc restart
# service /etc/init.d/centrify-sshd restart