GroupWise and openSUSE 11.3

16 05 2013

Here is a little howto install the GroupWise 8 client on openSUSE 11.3

STEP 1: Prepare openSUSE 11.3 for the Novell GroupWise 8 client
(as root)
zypper in openmotif openmotif22-libs libstdc++33
(for 64bit-Systems, the “-32bit” versions of openmotif22-libs and libstdc++33 are required)

STEP 2: Download latest Novell GroupWise client
Latest GroupWise client available here

STEP 3: Install the Novell GroupWise 8 client
(as root)
unzip *.zip
rpm -Uhv *.rpm
(alternative, you can click your way around and install using the GUI)





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 http://www.collab.net/downloads/community/
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 me@example.com

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
end
# check the validation code is correct
abort "Invalid" unless validation_code == ROTP::TOTP.new(secret).now.to_s
# user has validated so we'll give them their shell
Kernel.exec ENV['SSH_ORIGINAL_COMMAND'] || ENV['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 me@example.com

That should do it!

Testing it out

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

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.

Article: moocode.com





MrNovell is back!

23 09 2011

Hey All,

I know it’s been long while since I posted but I have a lot of new ideas that I want to post about and I’ll give an update of what I been up to the past year or so.

Stay Tuned!





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 59.163.108.38.static-chennai.vsnl.net.in [59.163.108.38] failed – POSSIBLE BREAK-IN ATTEMPT!
Dec 22 04:25:54 asterix sshd[19886]: Failed password for root from 59.163.108.38 port 52523 ssh2
Dec 22 04:31:18 asterix sshd[19892]: Failed password for root from 120.105.81.155 port 55401 ssh2
Dec 22 04:31:58 asterix sshd[19918]: Invalid user oracle from 120.105.81.155
Dec 22 04:31:58 asterix sshd[19918]: Failed password for invalid user oracle from 120.105.81.155 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.





Subversion and Snow Leopard

9 12 2009

Along with so many others, I upgraded to Snow Leopard. Overall the upgrade went without a hitch. However, I noticed that my Subversion repository was no longer available from Subclipse or via the Web Browser. Not good.

So I did some digging around and upon finding this article from Patrick Rice http://patrick-rice.net/daybook/2009/09/20/subversion-snow-leopard-etc/ I was up and working again in a few minutes.

Apparently with the Snow Leopard upgrade, the Apache mod_dav_svn configuration was removed from /etc/apache2/other/svn.conf. Patrick references the following article. It’s extremely educational and informative: How To: Manage Your Own Subversion Repository In Leopard. The details still apply in Snow Leopard, as well.

Following these articles I just created a new /etc/apache2/other/svn.conf.

LoadModule dav_svn_module /usr/libexec/apache2/mod_dav_svn.so

<Location /svn>
    DAV svn

    SVNParentPath /Users/Shared/svn

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

Restart the Apache server (via Sharing in the System Preferences application). And you should have your repository back.

Snipts from: CodeThought








Follow

Get every new post delivered to your Inbox.