Install Subversion on Mac OS X Lion (10.7)

23 09 2011

Edit the SystemVersion.plist file to change your Mac OS X version from 10.7 to 10.6:
sudo vi /System/Library/CoreServices/SystemVersion.plist
Replace each occurrence of 10.7 with 10.6
Save the file
Install Universal Subversion 1.6.17 Binaries for Snow Leopard (Mac OS X 10.6) from
Revert the file we edited previously (10.6 to 10.7 this time)


Simple Two-Factor SSH Authentication

23 09 2011

In a two-part post I’m going to show you some tricks you can do with SSH logins. This post covers setting up two-factor SSH authentication with the Google Authenticator app.

I was recently getting some servers in shape so I can pass the Payment Card Industry standards questionnaire and one requirement was two-factor authentication access to the server. I queried whether SSH key + passphrase was acceptable but didn’t get a clear answer so I figured I’d explore setting up another authentication factor myself, plus it piqued my interest.

After a bit of research I found it was possible using a PAM module but it doesn’t work along with SSH key authentication (only password authentication) and I only use SSH key logins for my servers.

The magic

I wanted to find the simplest method of implementing this so I started looking at what we can do with SSH itself. There is an option in the authorized_keys file that allows you to run a command when a user authorizes with a particular key eg.

command="/usr/bin/my_script" ssh-dsa AAA...zzz

The command="..." part invokes a different command upon key authentication and runs the /usr/bin/my_script instead. Now we’ve got a starting point to work on the Google Authenticator logic.

Simple implementation

I’ve chosen ruby to implement this simple example but in theory you could use anything you want. This is a naive implementation but it will prove the concept. You’re going to need therotp library as well for this to work gem install rotp.

We put the following in /usr/bin/two_factor_ssh

#!/usr/bin/env ruby
require 'rubygems'
require 'rotp'
# we'll pass in a secret to this script from the authorized_keys file
abort unless secret = ARGV[0]
# prompt the user for their validation code
STDERR.write "Enter the validation code: "
until validation_code = STDIN.gets.strip
  sleep 1
# check the validation code is correct
abort "Invalid" unless validation_code ==
# user has validated so we'll give them their shell

The secret is in Kernel.exec which, upon successful validation, replaces thetwo_factor_ssh script process with the original command the user was attempting or their default shell so it is a completely seamless experience from that point on.

Generating the secret

We need to generate a secret token that is shared between the Google Authenticator app and the server.

Here’s a little script that will spit out a new token and a link to a QR code that can be scanned into the Google Authenticator application.

#!/usr/bin/env ruby
require 'rubygems'
require 'rotp'
secret = ROTP::Base32.random_base32
data = "otpauth://totp/#{`hostname -s`.strip}?secret=#{secret}"
puts "Your secret key is: #{secret}"
puts url

Running this produces:

We can scan the QR code directly into Google Authenticator and then update ourauthorized_keys file as follows:

command="/usr/bin/two_factor_ssh 4rr7kc47sc5a2fgt" ssh-dsa AAA...zzz

That should do it!

Testing it out

[richard@mbp ~]$ ssh moocode@myserver
Enter the validation code: wrong
Connection to myserver closed.
[richard@mbp ~]$
[richard@mbp ~]$ ssh moocode@myserver
Enter the validation code: 410353

Great, that seems to work as expected.

Wrapping up

I’ve got a slightly more involved example that adds in support for ‘remember me’ by IP address for a fixed period of time so you don’t have to reach for the phone on every single login from the same IP.

The extended example also does some primitive logging but I’d like to add in a better auditing system (another PCI compliance requirement) as this would allow us to know which key is used to log into the server and whether they validated.

We should also probably have a fallback mechanism (a master key or 5 one-time codes like Google does) so we don’t inadvertently lock ourselves out of the server.


Display Disk I/O

2 12 2010

Would you like to know the disk I/O of the processes on your system?

Give iotop a try.

iotop screen shot



SSH Access – Prevent password guessing

27 07 2010

The Risk
In my case, I want outside SSH access to my server with minimal risk. What is that risk? Password guessing by script kiddies. Many young hax0rs run a few scripts every night that randomly try thousands of different passwords on machines that are accessible over SSH.

The moment your machine is reachable on port 22, these scripts find you and your logs fill up with lines like these:

Dec 22 04:25:54 asterix sshd[19886]: reverse mapping checking getaddrinfo for [] failed – POSSIBLE BREAK-IN ATTEMPT!
Dec 22 04:25:54 asterix sshd[19886]: Failed password for root from port 52523 ssh2
Dec 22 04:31:18 asterix sshd[19892]: Failed password for root from port 55401 ssh2
Dec 22 04:31:58 asterix sshd[19918]: Invalid user oracle from
Dec 22 04:31:58 asterix sshd[19918]: Failed password for invalid user oracle from port 58104 ssh2

If you have a strong root password, you are probably reasonably secure, however in time someone might get in. That is your risk, right there.

The Solution
So how do you stop it? Since you are running Linux, very easily, if you enter the following two iptables commands as root:

# iptables -A INPUT -i eth0 -p tcp –dport 22 -m state –state NEW -m recent –set –name SSH
# iptables -A INPUT -i eth0 -p tcp –dport 22 -m state –state NEW -m recent –update –seconds 120 –hitcount 4 –rttl –name SSH -j DROP

(You might need to change the ‘eth0’ part into your external interface, likely eth1 or ppp0 or similar. )
What does this do? Whenever someone connects to your machines more than 3 times in two minutes, they are blocked for two minutes. This will effectively stop all password guessing scripts; they usually cannot handle this and crash or hang.

OpenSUSE Linux: Creating Self-Signed SSL Certificates

18 06 2009

At some point or another, you’ll likely end up needing an SSL certificate for a Web site somewhere along the line. For a commercial site, your hosting provider can or will help you get this all squared away. This article is not for people in that situation.

What we’re doing here will be to create our own Certificate Authority. Then, we’ll create our own server key and a signing request. Then, we’ll sign our own certificate using the key and certificate from our own Certificate Authority. In other words, we’re not just going to create an SSL certificate, but we’re going to sign that bad boy, too.

This is useful for personal websites that need a little security, or when you’re waiting for your real cert from a real Certificate Authority. Perhaps you need it for transmitting data from an external server to your Intranet. Or perhaps you need it in any of the three hundred thousand seven hundred forty-two other situations that may arise.

Read the rest of this entry »

Quick and easy backup with lftp

5 12 2007

No matter what Linux distribution you are using, chances are you’ll find more than one graphical FTP client in its repositories, but if you are looking for a powerful command-line FTP tool, your best bet is lftp. Of course, you can always use the good old ftp command, but lftp takes the task of managing files and directories using the FTP protocol to a new level. To see what I mean, let’s use lftp to write a script that creates a local backup copy of a Web site.

Read Rest..

Article By:

How To: Manage Your Own Subversion Repository In Leopard

17 11 2007

Some of us linux users use both Linux and Apple. Because I deal with both Linux, Mac and Microsoft OS’s in my networks, I like to keep configuration files and source code for my custom apps in SubVersion. I came across a great article for MAC OS X Leopard SVN setup.

Mac OS X 10.5 Leopard ships with Subversion 1.4.4 pre-installed. It also ships with Apache2 pre-installed. It does not, however, ship with a pre-installed subversion repository configuration.

So let’s say you want to create your own subversion repository host on your Leopard box your own source code management goodness?

You could go to the subversion homepage and download the free svn book and sort through the instructions trying to figure out how they apply to you… Or you could follow these simple directions which I’ve laid out for you.

Make a Repository

The first thing you need to do is to make a repository. Actually, for my needs, I had to make multiple repositories, so these instructions will set everything up to make that work. It really only changes two steps anyway, so it isn’t a big deal.

Now I decided to make my repository collection root directory be in /Users/Shared/, but you can really make it be anything you want, including the ever popular /usr/local. Just be sure to replace /Users/Shared/ with your directory of choice whenever necessary.

Anyway, I opened Terminal and entered the following commands:

$ sudo mkdir /Users/Shared/svn
$ sudo mkdir /Users/Shared/svn/reposname
$ sudo svnadmin create /Users/Shared/svn/reposname
$ sudo chown -R www:www reposname

Note that you can create multiple repositories by following these directions but replacing every instance of reposname with the name of the repository you want to use. Thus, if you have multiple repositories, you will have multiple directoris in /Users/Shared/svn

Make Access

Most directions do this later, but I’m going to do it now because I think you are smarter than that.

You might want to create a passowrd file, unless you want full public access to your repository. For our purposes, simple http basic authentication is fine, but remember that the password is only weakly encoded and the traffic isn’t encoded at all, so a snooper could get to the information if you access your computer outside of your own computer.

So if you do want to use authentication, create the password using the following command, substituting username for a user name of your choice, and following the directions for password creation:

$ sudo htpasswd -cm /etc/apache2/svn-auth-file username

To add other users to the file, just ditch the c switch in the -cm options to htpasswd. The c stood for create, and since the file has been created you don’t want it anymore.

Note that you can put the svn-auth-file anywhere you want, but this seemed like a good place for it in my mind. (Just remember where you hid it from yourself if you put it anywhere else.

Apache Configuration

Navigate to /etc/apache2/other and use your favorite command line text editor as root to make a file named anything you want (I chose svn.conf, but you could name it foobar_banana.conf and it would still work!):

$ cd /etc/apache2/other
$ sudo vim svn.conf

Now that you are editing this file as root, you want to make it contain the following bits, and save:

LoadModule dav_svn_module /usr/libexec/apache2/

<Location /svn>
    DAV svn

    SVNParentPath /Users/Shared/svn

    AuthType Basic
    AuthName "Subversion repository"
    AuthUserFile /etc/apache2/svn-auth-file
    Require valid-user

Note that you can leave off all the authentication related stuff if you didn’t want authentication on your repository. Also note that you need to fix the SVNParentPath and the AuthUserFile if you varied from my directions.

Restart Apache

Now restart Apache. This can be done in the Sharing panel of the System Preferences application. Just click to turn off, and then back on, Web Sharing.

Now, if you didn’t make a mistake, you should be ready! Try going to http://localhost/svn/reposname (where you need to put the repository name you chose earlier instead of reposname!) and see what happens.

If you are lucky you’ll see revision 0 of your repository. But most people are human and will have made a typo that results in an error. For hints on what created the error, trying checking out /var/log/system.log and /var/log/apache2/error_log for hints as to what you did wrong. (And as a bonus, the Console application works great for monitoring thes logs as they are writen to!)

Where From Here?

And now you are ready to use your repository. At this point I figure you already know how to use SVN and don’t need my help anymore. But if you need to know how to use SVN, just refer to their book, which tells you everything you need to know, including how to make your server better!

EDIT (11/6/07): Forgot to encode my character entities in the example script source. I fixed this so that the <Location> tag actually shows now.

Article By: Paploo