SSH key authentication not working under SELinux? Check this.

Just a short story after resolving a recently encountered problem: all our machines that are in the cloud, have SELinux enabled by default. Normally not a problem, but I found one interesting nuisance: one user could not log on using ssh key authentication.

It would have been found faster, but the developers stated, that _some_ users can’t use the key authentication method; had they told me from the get-go that they meant one user, I’d have been faster with the resolution.

First I confirmed the problem by adding my own ssh key to the .ssh/authorized_keys file in the affected user’s home directory, I checked all directory and file owners and permissions (644 on the .ssh, and 600 on the keyfile) – problem confirmed, I’m getting prompted for a password.

Using ssh -vvv I got this difference in logging in:

Unaffected user:

debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 279

Affected user:

debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,gssapi-keyex,

My key is obviously denied, but without message? Why? Let’s look in the system’s logfiles.

In the audit.log is a hint at the culprit:

Nov 18 11:51:43 sa1ha2l kernel: type=1400 audit(1384771903.411:62597): avc:
denied  { search } for  pid=14683 comm="sshd" name="/" dev=dm-3 ino=2 scontext=
system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:file_t:s0

My old “friend” the AVC denial, we meet again. At first I did a simple restorecon -v -R, but no luck, still got an AVC denied message. There was no difference in the SELinux permissions on the affected user’s and a random unaffected user’s .ssh directory, still a tclass=dir denial? What the …? Let’s look up one level!

[root@localhost ~]# ls -lZ /var/local/ | grep sa1user
drwx------. sai1usr sa1grp system_u:object_r:var_t:s0       sa1user
[root@localhost ~]# ls -lZ /home
drwxr-xr-x. root  root  unconfined_u:object_r:home_root_t:s0 chroot
drwx------. test1 test1 unconfined_u:object_r:user_home_dir_t:s0 test1

Gotcha! Although both users were created with the adduser command, the user in the nonstandard /var/local location did not have the user_home_dir context on its homedir.
Repair was easy:

chcon -v --type=user_home_dir_t /usr/local/sa1user

SSH key login began functioning immediately.


Say bye-bye to the old trusty MD5

It is official: Microsoft is one of the big ones who’ll be retiring the venerable-but-vulnerable MD5 algorithm. Don’t worry, you’ll still be able to create MD5 hashes for your documents and verify them, but not for authentication and code signing anymore.

The first chink in MD5’s armor was discovered in 1996; while not critical (MD5 creates 128-bit hashes – the vulnerability is in one of the 64 steps to create the hash value) security experts began recommending alternate algorithms. Both recommended replacement hash functions became obsolete since then.

How big of a security risk was the 1996 announcement? When something like this comes up, cryptoanalysts begin investigating, and creating scenarios, how the fuction can be compromised. It took 8 years, and an unimaginable increase in computing power to crack the MD5 hashing algorithm. The server the chinese analysts demonstrated on (a pSeries IBM) reportedly had 24 Power processors and 1TB RAM – to find a collision with a randomly given MD5 hash took less, than 1 hour.

What is a collision? Basically you take two files which differ in size and (obviously) content, you run your favourite md5sum command on them, and surprise-surpise, the files got identical hashes. No big deal, really? Imagine then what horror Adobe’s programmers felt, when _all_ their user data, passwords, hints, everything was leaked. The passwords were of course left encrypted, but savvy users soon found by sorting the data by password hash, that there were many similarities, even when the password hints indicated completely different. In MySQL databases you have the option to have your fields be MD5 encrypted, and many authentication algorithms simply create a hash when you put your password in the password field, and then compare it to the stored value in the sql database.


Using the cracking method outlined in the 2004 announcement, and some (cheap!) hardware, a password can be created from an MD5 hash value. It won’t be the original password, but since the hashed value will be the same – you’re in like Flynn. The hardware required is really not on the same level as in 2004 – today you can use the just about anything with a processor in it, a powerful GPU is one way, or use your bitcoin-mining FPGAs to create a program that just runs the blocks over and over, hundered million times a second. The only good thing about the published methods is, that you won’t be able to decode the orignal password, just replicate it with something that will be accepted as your password.

Read about the update in more detail on Microsoft’s website: Technet
Read about the MD5 function, its history, and the vulnerability: Wikipedia
Check if your personal data was leaked: ZDNet

Basic gateway to gateway VPN tutorial: Part 2 – “Cisco RV042”

In this Article i will guide you through a Gateway to Gateway VPN Tunnel configuration using two Cisco RV042. Our goal is just like in the first part of the article, to create an sql DB link between two MS SQL DB server.

Continue reading “Basic gateway to gateway VPN tutorial: Part 2 – “Cisco RV042””

Basic gateway to gateway VPN tutorial: Part 1 – “TheGreenBow”

In these two articles i will show you two examples, how to connect two computers like two DB servers for example, securely through the internet, with the use of the VPN tunel technology.

I will use two Windows 2008 R2 Servers with a Microsoft SQL Server 2005 installed on each of them. The Servers are installed with a dedicated NIC for this task. I will concentrate on configuring the VPN Tunnel, and only mention some general info about routing, firewall, or DB link configurations needed.

Continue reading “Basic gateway to gateway VPN tutorial: Part 1 – “TheGreenBow””

AuthBasicProvider not allowed here

During vhost provisions with LDAP auth I was seeing errors:

root@test:~# /etc/init.d/apache2 restart
Syntax error on line 30 of /etc/apache2/sites-enabled/000-default:
AuthBasicProvider not allowed here
Action 'configtest' failed.
The Apache error log may have more information.

Continue reading “AuthBasicProvider not allowed here”

Puppet-dashboard with LDAP Auth on Debian Squeeze


After installing puppet I was researching a possibility to secure puppet dashboard with either ldap auth or apache htpasswd auth. Some quick tests and I got a working config set up fairly easily.
Continue reading “Puppet-dashboard with LDAP Auth on Debian Squeeze”

Puppet install on Debian Squeeze with Dashboard


I had some time and started playing around with puppet. At first I was really frustrated with some sites giving documentation or guides that had errors that resulted in hours of debuging, and googling. So I would like to present my short but tested guide.

Continue reading “Puppet install on Debian Squeeze with Dashboard”