Yak Shaving

Kerberos uses tickets to grant access to resources on a Kerberos-enabled computer. If you want to login (via SSH) to a remote host and you don’t want to re-execute the kinit command after you login, you can just forward your ticket with your ssh client. Two steps are needed to do this – given that your Kerberos client is configured:

1. Create a Kerberos forwardable ticket to your machine
2. and, forward your ticket while logging in to the remote machine.

In order to create a forwardable ticket execute kinit with the “-f” argument. e.g.:

pythoagoras:~ asteriosk$ kinit -f
Please enter the password for username@domain.com:

In order to tell the ssh client to forward your ticket to the remote machine, you have to configure it accordingly. The easiest way to do it is to include two directives in your ssh client configuration file which is in .ssh/config (create one if there its not there).

chercheurs2-235:~ asteriosk$ more ~/.ssh/config
Host domain.com
        GSSAPIAuthentication yes
        GSSAPIDelegateCredentials yes

Of course, substitute domain.com and username accordingly to match your configuration. This works for both Linux and Mac OS X clients.

I am sure that you have heard about OpenID. OpenID is an open, decentralized, free framework for user-centric digital identity. That means that you only need only one username in order to be able to login into many sites that support OpenID. Yahoo!, Google, Microsoft and many many others have expressed support and are already providers of this wonderful idea that is spreading every day.

With OpenID every user has one universal username that uses in every OpenID-enabled site. For example, my OpenID is “id.asteriosk.gr”. It is unique since I own the domain asteriosk.gr and I use it to log into this blog, and in many other sites that support OpenID login.

In order to be able to use openID you need an OpenID provider. That could be AOL, Blogger, Flickr, Wordpress and many many others. For example if aol is your provider, you will can use username like this: openid.aol.com/screenname to login to sites. If its Wordpress you have to use usernames like this: username.wordpress.com.

Having a provider that you trust is a very nice thing. However, when it comes to a universal username that you will use for every login on the internet, you might want to have your own personalized OpenID that is using your own domain name.

Having your own OpenID means that you are the provider of yourself. If you are the provider of yourself, you will have to use your own server and infrastructure to provide yourself OpenID services. Providing OpenID services to yourself, means that you have to be able to keep your site secure. Installing an OpenID server is quite easy but keeping it secure, is kind of tricky. If you want to run your own OpenID server, you can use one of the many OpenID servers out there.

In my case, I chose the Prairie server. It supports multiple users and it only needs PHP and MySQL. However, there were problems installing it. Prairie needs Apache to run. That’s because it needs .htaccess files in order to make those URL rewrites easier for Prairie’s developers. My server runs on Lighttpd, so the first problem that came up when trying to install Prairie was -as usual- lighttpd’s mod_rewrite module.

I followed Prairie’s instructions. The installation is pretty easy, you just need a MySQL username and password and a database where Prairie will save its data. After that you run the installed script and everything works as expected! The only difficult thing I had to overcome was to convert the .htaccess file so that lighttpd can understand what to do with those rewrites.

In my existing PHP-enabled server, I created a subdomain named id.asteriosk.gr and I put these rewrite rules to get it working:

 <br />$HTTP["host"] == "id.asteriosk.gr" { <br /> server.document-root = "/opt/apps/prairie/" <br /> url.rewrite = ( "(.<em>.php|theme/|template/|install/).</em>" => "$0", "^/(.*)$" => "/index.php?$1" ) <br />} <br />

Another thing that you will have to have in mind is that Prairie, needs a special PHP library to run. The library is called bcmath and you will have to install it by hand or using your package manager. In my case (CentOS 5) I just run:

 yum -y install php-bcmath 

and restarted lighttpd. I also had to kill the existing php-fcgi’s that were already running.

Suppose that you want to access a remote port in a machine that runs a service on port 3306. Also suppose that the remote machine has restricted access to that port only for requests coming from the host “localhost”. You will have to create a tunnel to that machine and tunnel all your requests from you local computer’s port e.g. 2000 to the remote host’s port 3306.

ssh  -L 2000:localhost:3306  root@asteriosk.gr

After doing this, every request to localhost:2000 will be redirected(tunneled) to the remote machine at port 3306 through a secure channel! The remote machine, will accept all requests coming from the tunnel like if they were coming from localhost.

For me, this was a very nice way to access my MySQL database from my computer with the Sequel Pro client that does not support SOCKS proxies. I tell Sequel to connect to 127.0.0.1:2000 and all the requests that I make, are being redirected to my host (asteriosk.gr) so that MySQL thinks I am a local user and lets me in.

Let me know if there is something not clear here!

Yesterday, I was trying to login to my machine and I got the following message:

PTY allocation request failed on channel 0

My prompt was stuck and I could not enter commands. This happened because -for some reason- the tty related devices(/dev/ptmx, /dev/pts) were not created or mounted on my machine. In order to get this problem resolved, I created and mounted the missing devices using the following commands:

rm -rf /dev/ptmx
mknod /dev/ptmx c 5 2
chmod 666 /dev/ptmx
umount /dev/pts
rm -rf /dev/pts
mkdir /dev/pts
mount /dev/pts

In order to be able to execute commands you will have to login to your machine(isn’t this supposed to be the original problem :) ).
This will do the trick:

ssh user@host "/bin/bash -i"

My VPS is built on openVZ but I have seen this problem occur also in XEN machines.
Leave me a comment if this works for you!

Exclude host 10.16.21.206 from sniffing AND resolve hostnames

tethereal -N n -f 'host not 10.16.21.206'