Unode's questions

I have a network on which I run multiple servers each dedicated to a given service.

Because most services run on distinct ports I'm currently looking for a way of unifying "all" services into a single "proxy" machine. The idea is to abstract which machine is being accessed but still allow direct connection if needed/requested.

This "proxy" machine has only one network interface which is part of the same network as all the other service providing machines.

I've looked into Routing and NAT but I've so far failed to figure out how to make it work. I tried to achieve this using shorewall but couldn't find clear examples. However I'm not entirely sure this is the best/simplest strategy.

With that said, what would be the best way of achieving this result?

Example case:

Proxy IP     - Listening port - Send requests to
192.168.0.50   80 (http)        192.168.0.1:80
     "         22 (ssh)         192.168.0.2:2222
     "         3306 (mysql)     192.168.0.3:3000
     "         5432 (postgres)  192.168.0.4:5432 
     "         5222 (jabber)    192.168.0.5:5222

PS: I'm not concerned with the single-point-of-failure nature of the proxy.

Thanks

I've been searching for a way to setup OpenSSH's umask to 0027 in a consistent way across all connection types.

By connection types I'm referring to:

1. sftp
2. scp
3. ssh hostname
4. ssh hostname program

The difference between 3. and 4. is that the former starts a shell which usually reads the /etc/profile information while the latter doesn't.

In addition by reading this post I've became aware of the -u option that is present in newer versions of OpenSSH. However this doesn't work.

I must also add that /etc/profile now includes umask 0027.

Going point by point:

• sftp - Setting -u 0027 in sshd_config as mentioned here, is not enough.

If I don't set this parameter, sftp uses by default umask 0022. This means that if I have the two files:

-rwxrwxrwx 1 user user 0 2011-01-29 02:04 execute
-rw-rw-rw- 1 user user 0 2011-01-29 02:04 read-write

When I use sftp to put them in the destination machine I actually get:

-rwxr-xr-x 1 user user 0 2011-01-29 02:04 execute
-rw-r--r-- 1 user user 0 2011-01-29 02:04 read-write

However when I set -u 0027 on sshd_config of the destination machine I actually get:

-rwxr--r-- 1 user user 0 2011-01-29 02:04 execute
-rw-r--r-- 1 user user 0 2011-01-29 02:04 read-write

which is not expected, since it should actually be:

-rwxr-x--- 1 user user 0 2011-01-29 02:04 execute
-rw-r----- 1 user user 0 2011-01-29 02:04 read-write

Anyone understands why this happens?

• scp - Independently of what is setup for sftp, permissions are always umask 0022. I currently have no idea how to alter this.

• ssh hostname - no problem here since the shell reads /etc/profile by default which means umask 0027 in the current setup.

• ssh hostname program - same situation as scp.

In sum, setting umask on sftp alters the result but not as it should, ssh hostname works as expected reading /etc/profile and both scp and ssh hostname program seem to have umask 0022 hardcoded somewhere.

Any insight on any of the above points is welcome.

EDIT: I would like to avoid patches that require manually compiling openssh. The system is running Ubuntu Server 10.04.01 (lucid) LTS with openssh packages from maverick.

Answer: As indicated by poige, using pam_umask did the trick.

The exact changes were:

Lines added to /etc/pam.d/sshd:

# Setting UMASK for all ssh based connections (ssh, sftp, scp)
session    optional     pam_umask.so umask=0027

Also, in order to affect all login shells regardless of if they source /etc/profile or not, the same lines were also added to /etc/pam.d/login.

EDIT: After some of the comments I retested this issue.

At least in Ubuntu (where I tested) it seems that if the user has a different umask set in their shell's init files (.bashrc, .zshrc,...), the PAM umask is ignored and the user defined umask used instead. Changes in /etc/profile did't affect the outcome unless the user explicitly sources those changes in the init files.

It is unclear at this point if this behavior happens in all distros.