SFTP authentication not working

A few days before I stumbled upon a problem with our OpenSSH (net-misc/openssh-5.2_p1-r3) based SFTP solution. Although passwords were not changed SFTP logins did not work any longer whereas normal SSH logins with the same accounts continued working.

The concerning – now working – SSHD config looks like this (except AllowUsers):

Port 22
Protocol 2
LogLevel INFO
SyslogFacility AUTH
LoginGraceTime 60
PermitRootLogin no
PasswordAuthentication yes
KeepAlive yes
# this must be set to no and PasswordAuthentication to yes. Otherwise SFTP will not work!!!!
UsePAM no
PrintMotd no
PrintLastLog no
ClientAliveInterval 30
ClientAliveCountMax 10
Subsystem sftp internal-sftp
Match Group sftponly
ChrootDirectory /home/%u
ForceCommand internal-sftp
X11Forwarding no
AllowTcpForwarding no

After more than one hour of trial and error I found out, that UsePAM must be set to no and PasswordAuthentication must be set to yes. All other combinations of these two options kill sftp authentication (sys-auth/pambase-20090620.1-r1 with ssh USE flag enabled).

As I am not using pam’s advanced authentication functions this deactivation is not a problem to me.
So, finally, if you encounter strange authentication issues with sftp try to disable pam auth and see if sftp authentication is working again afterwards.


PS If you know another solution to this problem or if I somehow messed up my config please let me know.

Ebuild for KDE service menu manager

Recently I created a gentoo ebuild for the 0.4 version of the KDE 4.3 service menu manager (http://www.kde-apps.org/content/show.php/Service+Menu+Manager?content=94996):

# Copyright 1999-2008 Gentoo Foundation
# Author Phillip Merensky
# Distributed under the terms of the GNU General Public License v2


inherit kde4-base

DESCRIPTION="This app is a System Settings module to manage service menus."
KEYWORDS="amd64 x86"



src_unpack() {
unpack ${A}
cd "${S}_build"

src_compile() {
cd "$S"
emake || die "Make failed!"

Save it as service-menu-manager-0.4.ebuild in your favorite category (I prefer kde-misc) in your custom overlay, execute

ebuild service-menu-manager-0.4.ebuild digest

and emerge it.

Apache document root RewriteRule error

While customizing this homepage I came across the following problem: I wanted to rewrite every request which accesses the root of this page to access the subfolder “drupal”. This way t is possible to use “www.phillme.de” to see the blog and additionally allow subfolders on the same level as the “drupal” directory.

My first guess was to use the following in a .htaccess-file in the document root:

RewriteEngine on

Sadly enough it did not work although the url rewriting guide of apache at http://httpd.apache.org/docs/2.2/rewrite/rewrite_guide.html exactly mentions the same solution for a moved document root.

The solution described there is the following, which is very similar to my initial yet not working attempt:

RewriteEngine on
RewriteRule ^/$ /about/ [R]

Of course I also tried the “[R]” for redirect with the same problem. The redirect was not triggered. Fortunately I found another site with “very common mistakes” about rewrite rules (http://rewriterule.alantait.com/4/). It mentions that the RewriteRule does NOT have the beginning “/” which transforms my initial solution to

RewriteEngine on

without the root slash and… finally it works.

I am wondering if this is an error in the apache documentation or if I just got something wrong. Maybe someone can brighten the for me. All others may consider the solution above ;-).

ACL Support in the Grails Spring Security Plugin

I am very happy to announce that my enhancements to the Grails Spring Security Plug-in (Acegi Security Plug-in http://grails.org/plugin/acegi) based on Stephan February’s work were integrated into the main Plug-in source tree. Burt Beckwith, the Plug-In maintainer, did the integration including further features (e.g. annotation based configuration) and polishing.

The official announcement including an example application can be found on his blog (http://burtbeckwith.com/blog/?p=287).

Thank you for your great work Burt!