Command Center

Following any of the usual how-to’s didn’t leave me with a successfully speedy login.. I eventually tracked down the problem to a particularly monumental bug in RedHat’s OpenSSH server (apparently fixed up stream.. it does us all now no good)..

The fix

1. edit /etc/ssh/sshd_config
2. Find and change the lines (or add if missing):
   
   GSSAPIAuthentication yes
   
   ...
   
   #UseDNS yes
   
   

   to

   
   
   GSSAPIAuthentication no
   
   ...
   
   UseDNS no
   
   
3. Enjoy

Side Note

If you use CentOS you’re probably unable to reboot your SSH server and you don’t know it.

I also experienced this problem while attempting to restart the ssh server. Everything seemed to work but when checking the logs it showed serious errors. It complained about being unable to bind to port 22. To see if you have the same problem follow these steps..

If you find something like the following:

then you’ve got problems.. It’s basically saying that the localhost IPv6 address (represented as “::”) is hogging port 22 instead of 0.0.0.0 (means ANY IPv4 address). If that’s what you want, then great! If not..

edit

and change it to look as follows from

to

Hope this helps!

================================================

[root@home]# cat disableipv6.sh

#!/bin/sh
#http://usalug.org/phpBB2/viewtopic.php?t=13265
# For debugging use iptables -v.
IPTABLES="/sbin/iptables"
IP6TABLES="/sbin/ip6tables"
MODPROBE="/sbin/modprobe"
RMMOD="/sbin/rmmod"
ARP="/usr/sbin/arp"

#------------------------------------------------------------------------------
# Completely disable IPv6.
#------------------------------------------------------------------------------

# Block all IPv6 traffic, otherwise the firewall might be circumvented by an
# attacker who simply sends IPv6 traffic instead of IPv4 traffic.
# Note: The safest way to prevent IPv6 traffic is to not enable support for
# IPv6 in the kernel in the first place (neither built-in nor as a module).

# If the ip6tables command is available, try to block all IPv6 traffic.
if test -x $IP6TABLES; then
  # Set the default policies (drop everything).
  $IP6TABLES -P INPUT DROP 2>/dev/null
  $IP6TABLES -P FORWARD DROP 2>/dev/null
  $IP6TABLES -P OUTPUT DROP 2>/dev/null

  # The mangle table can pass everything through unaltered (we don't use it).
  $IP6TABLES -t mangle -P PREROUTING ACCEPT 2>/dev/null
  $IP6TABLES -t mangle -P INPUT ACCEPT 2>/dev/null
  $IP6TABLES -t mangle -P FORWARD ACCEPT 2>/dev/null
  $IP6TABLES -t mangle -P OUTPUT ACCEPT 2>/dev/null
  $IP6TABLES -t mangle -P POSTROUTING ACCEPT 2>/dev/null

  # Delete all rules.
  $IP6TABLES -F 2>/dev/null
  $IP6TABLES -t mangle -F 2>/dev/null

  # Delete all (non-builtin) user-defined chains.
  $IP6TABLES -X 2>/dev/null
  $IP6TABLES -t mangle -X 2>/dev/null

  # Zero all packet and byte counters.
  $IP6TABLES -Z 2>/dev/null
  $IP6TABLES -t mangle -Z 2>/dev/null
fi

REFERENCE

http://www.dbaranski.net/2010/03/slow-ssh-logins-on-centos-5/

So this is quite frustrating:

Background:

In Ubuntu 9.04 I had a VPN connection configured in order to use
Witopia. It worked.

Under Ubuntu 9.04 I used these
instructions to set everything up.

I upgraded to Ubuntu 9.10 and now it doesn't work.

Problem:

In Network Manager, under VPN Connections, when I select my "openvpn"
connection I get this error message:

The vpn connection 'openvpn' failed because the VPN
service failed to start.

More Info:

Here is what it says in Sys Log:

(notice what I have highlighted in red)

Nov  7 21:05:21 ubuntu-laptop NetworkManager:
<info>  Starting VPN service
'org.freedesktop.NetworkManager.openvpn'...

Nov  7 21:05:21 ubuntu-laptop NetworkManager: <info>  VPN
service 'org.freedesktop.NetworkManager.openvpn' started
(org.freedesktop.NetworkManager.openvpn), PID 1974

Nov  7 21:05:22 ubuntu-laptop NetworkManager: <info>  VPN
service 'org.freedesktop.NetworkManager.openvpn' just appeared,
activating connections

Nov  7 21:05:22 ubuntu-laptop NetworkManager: <info>  VPN
plugin state changed: 1

Nov  7 21:05:22 ubuntu-laptop NetworkManager: <info>  VPN
plugin state changed: 3

Nov  7 21:05:22 ubuntu-laptop NetworkManager: <info>  VPN
connection 'openvpn' (Connect) reply received.

Nov  7 21:05:22 ubuntu-laptop
NetworkManager: <WARN>  nm_vpn_connection_connect_cb(): VPN
connection 'openvpn' failed to connect: 'No VPN secrets!'.

Nov  7 21:05:22 ubuntu-laptop
NetworkManager: <WARN>  connection_state_changed(): Could not
process the request because no VPN connection was active.

Nov  7 21:05:22 ubuntu-laptop NetworkManager: <info>  Policy
set 'Auto eth0' (eth0) as default for routing and DNS.

Nov  7 21:05:35 ubuntu-laptop NetworkManager: <debug>
[1257624335.001600] ensure_killed(): waiting for vpn service pid 1974 to
exit

Nov  7 21:05:35 ubuntu-laptop NetworkManager: <debug>
[1257624335.001766] ensure_killed(): vpn service pid 1974 cleaned up

Nov  7 21:05:40 ubuntu-laptop NetworkManager: <info>  Starting
VPN service 'org.freedesktop.NetworkManager.openvpn'...

Nov  7 21:05:40 ubuntu-laptop NetworkManager: <info>  VPN
service 'org.freedesktop.NetworkManager.openvpn' started
(org.freedesktop.NetworkManager.openvpn), PID 1978

Nov  7 21:05:40 ubuntu-laptop NetworkManager: <info>  VPN
service 'org.freedesktop.NetworkManager.openvpn' just appeared,
activating connections

Nov  7 21:05:40 ubuntu-laptop NetworkManager: <info>  VPN
plugin state changed: 3

Nov  7 21:05:40 ubuntu-laptop NetworkManager: <info>  VPN
connection 'openvpn' (Connect) reply received.

Nov  7 21:05:40 ubuntu-laptop NetworkManager: <WARN>
 nm_vpn_connection_connect_cb(): VPN connection 'openvpn' failed to
connect: 'No VPN secrets!'.

Nov  7 21:05:40 ubuntu-laptop NetworkManager: <WARN>
 connection_state_changed(): Could not process the request because no
VPN connection was active.

Nov  7 21:05:40 ubuntu-laptop NetworkManager: <info>  Policy
set 'Auto eth0' (eth0) as default for routing and DNS.

Nov  7 21:05:53 ubuntu-laptop NetworkManager: <debug>
[1257624353.002543] ensure_killed(): waiting for vpn service pid 1978 to
exit

Nov  7 21:05:53 ubuntu-laptop NetworkManager: <debug>
[1257624353.002711] ensure_killed(): vpn service pid 1978 cleaned up

What I have tried so far:

Reading through the Ubuntu forums, and searching Google, it seems
many people are having this problem. It also doesn't appear to be a new
problem (although I did not experience it in Ubuntu 9.04).

I tried to remove openvpn and network-manage-openvpn packages and to
add them again and to create new connection profiles.

Unfortunately without success.

Any ideas?

Update:

Apparently the following method has worked for some, can anyone
confirm?

• In the VPN settings, uncheck the option "Available
  to all users"
• Enable MPPE

Doing so will apparently solve the issue. I have not
yet tested this.

Update 2009.12.09:

The proposed fix did not work for me.

At this moment in time, I am of the assumption that
this problem is occurring mainly on machines that had a previous VPN set
up and were then updated?

Update 2009.12.25:

Two new solutions have been proposed. Before you try
them consider these points to see which option is better: Solution 1
allows network manager to use pptp encryption, this is a little less
secure than ssl. So I would recommend that you try Solution 2
first, if that doesn't work for you, undo the changes and try Solution
1.

Solution 1:

Install the package network-manager-pptp

The command would be: sudo apt-get install
network-manager-pptp

Then it should work as has been reported in the
comments section.

Solution 2:

Edit your /etc/network/interfaces file.

Change it from this:

auto lo
iface lo inet loopback

To this:

auto eth0
iface eth0 inet dhcp

This has also been reported to
work for some.

REFERENCES

http://www.cognitivecombine.com/2009/11/ubuntu-9-10-network-manager-openvpn-vpn-service-failed-to-start/

As you may have read, I’m testing with an IP management tool, called IPPlan.

Since I’m not the only one at our company, that need access to
IPPlan and I wasn’t planning in doing a lot of user management, I
did a try to connect IPPlan to our Active Directory (LDAP) environment.

It took me a while to figure it out, maybe cause the lack of
“good” documentation or my experience. It doesn’t
matter, because it is working now. This is what I did to get it working.

Go to the subdirectory “user” in the
“ipplan” directory, the full path (here) is:
“/var/www/ipplan/user” and create a file with the name
“.htacces”. Edit the file with the following information.

AuthType basic

AuthName “IP Plan LDAP Authentication”

AuthBasicProvider ldap

AuthLDAPURL ldap://ldapserver:389/ou=accounts,dc=robmaas,dc=eu?cn

AuthLDAPRemoteUserIsDN off

require valid-user

The “ldapserver” is just the IP or DNS name of your
LDAP(AD) server. After the URL you can use a standard LDAP query
(don’t forget to replace the domain name).

If your LDAP server needs authentication like mine does, you need to add the following two variables.

AuthLDAPBindDN “ldap@robmaas.eu”

AuthLDAPBindPassword “secret”

Make sure, your Apache configuration does support the including of
“.htaccess” files. This can be done by setting the
“AllowOverride” to All, like this.

AllowOverride All

Don’t forget this; it took me about 2 hours, before I got it.

Also don’t forget to include the LDAP module in to Apache.

a2enmod authnz_ldap

After this we need to edit “config.php”, find the following line:

define(“AUTH_INTERNAL”, TRUE);

and change it to:

define(“AUTH_INTERNAL”, FALSE);

The last change I had to make, was changing this line:

define(“AUTH_VAR”), ‘PHP_AUTH_USER’);

into

define(“AUTH_VAR”), ‘REMOTE_USER’);

That’s it, after restarting the Apache (httpd) service, it should all work.

Don’t forget, the authentication is done through LDAP, but you still have to create the users in IPPlan.

Sidenote: If the webpage is running on HTTP the
username(s) and password(s) are sent in plain text to the webserver. In
this case you should think about migrate it to HTTPS.

REFERENCES
http://www.progob.nl/robmaaseu/?cat=6