Posts Tagged ‘ authentication

Securing Synergy

At work, I have several computers on my desk, but I prefer to only use one mouse and keyboard to control all of them. To accomplish this, I use Synergy. The more recent versions of Synergy come with the ability to perform encryption on the connections through Synergy itself, but I did not feel it adequate enough or easy enough to use for my needs. Instead, I run Synergy on my machine which has the keyboard and mouse attached to it, then on my client machines, I tunnel the remote server’s synergy port to the local machine, and connect locally, This tunnels all Synergy traffic through SSH transparently, and is extremely secure. I like this level of security because often times, I am typing personal, sensitive, or confidential information on one of the client machines using the server’s keyboard.

In my setup, cota.austin.ibm.com is the Synergy server. All SSH is done through public key encryption to make the connection painless.
Here is the script I use:

#!/bin/bash -x

function clean()
{
    for job in `ps -eo pid,args | grep ssh | grep 24800 | grep -v grep | awk '{print $1}'`
    do
        kill -9 $job
    done
}

trap clean SIGINT

ssh -f -N -L localhost:24800:cota.austin.ibm.com:24800 cemeyer@cota.austin.ibm.com
synergyc -f localhost
clean

I hope this helps someone else looking for an easy way to secure down Synergy.

Auto installation of ssh public keys

Over the past few months, I’ve been writing little shell scripts here and there that make it just a bit easier to get my day to day work done. I thought I would post one of them here in case it might be beneficial to others as well.

I work a daily job where I am constantly using ssh to access many different remote machines all across the world. Since different machines can have different passwords and the like, I prefer to use public key authentication when possible to avoid this headache. The issue is, for each new machine I access, I used to have to manually install my pubkey on it to use public key authentication in the future. Even though Ubuntu has a shell script that ships with it called ssh-copy-id which handles the work for me, I knew that I could do better. Here is what I came up with:

~/bin/ssh

#!/bin/bash -x

/usr/bin/ssh -o PreferredAuthentications=publickey -o PasswordAuthentication=no -n $@ &> /dev/null
if [ $? -ne 0 ] 
then
    ssh-copy-id $@
fi  
exec /usr/bin/ssh $@

What this script does is first check if my pubkey is installed on the remote machine. If not, it runs the ssh-copy-id script to install it. This will prompt for the password, then install my public key. After that, a normal ssh session is started which, if everything worked properly, will use pubkey authentication to log me in. Perfect! The exec was necessary so that konsole (my preferred terminal) would realize I was in a remote session and update the tab label properly. I also had to change the shell script /usr/local/bin/ssh-copy-id near the end to have it use /usr/bin/ssh rather than just “ssh” otherwise it would recursively infinitely loop.

Apache-based authentication for Seaside

I recently posted about a completely Smalltalk-based solution for LDAP authentication for Seaside applications. After I got that working for my application, I realized that once I submitted my application to our security group here on campus for review, it would never pass inspection due to the fact that user passwords are accessible to my code. I can imagine many scenarios where programmer access to user credentials is unacceptable.

Fortunately, our university provides its own kerberos-based authentication solution for applications called Bluestem. It provides the user first with a screen to enter their username, then a second screen to enter their university kerberos password. Upon successful authentication, the user is given access to the proper resources on the server. Bluestem is written in Perl and there exists an Apache module to integrate it with web applications. I previously set up the server I plan to deploy my Seaside application on for Bluestem authentication for other web applications that I host on it, but I did not know of a way that I could use this type of authentication with Seaside since I was planning on using mod_proxy to proxy requests from my external-facing Apache server to my headless Pharo VM.

While I was researching how to do this, I came across an Apache module that someone has posted on Github at https://github.com/aimxhaisse/mod-proxy-add-user which takes the authenticated user name set by Apache and forwards it on to servers being proxied. I was able to compile it (manually, the Makefile appeared to be broken) and get it up and running on my CentOS server within a few minutes. I configured my Apache configuration file with:

<Proxy *>
    Order deny,allow
    Allow from all
    ProxyAddUser On
    ProxyAddUserKey "HTTP_X_FORWARDED_USER"
</Proxy>

And low and behold, I was able to access the authenticated user name in my proxied Seaside application with:

username := self class decodeUserIdFrom: (self requestContext request headerAt: 'http_x_forwarded_user' ifAbsent: [username := 'cemeyer2']).

Let me explain a little bit. In most cases, just self requestContext request headerAt: ‘http_x_forwarded_user’ will give you the authenticated user name, but our university’s kerberos solution sets this variable to ‘username@uiuc.edu/kerberos’, so the decodeUserIdFrom message strips off everything but the user name. The above line also is useful for when accessing the application when not being proxied behind university authentication (such as during development), as it will default to return my user name if the header is not found.