Mr.Novell\’s Blog

Welcome Back!

bscott — Thu, 31 Aug 2017 03:41:30 +0000

After about 10 years of being away from this blog, I am back but will be starting a new blog.

I’ve been at many companies over the years and now managing and running my own Engineering team. Stay tuned…

GroupWise and openSUSE 11.3

bscott — Thu, 16 May 2013 16:51:05 +0000

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)

bscott — Fri, 23 Sep 2011 20:42:00 +0000

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

bscott — Fri, 23 Sep 2011 19:26:13 +0000

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}"

url = "https://chart.googleapis.com/chart?chs=200x200&chld=M|0&cht=qr&chl=#{data}"

puts "Your secret key is: #{secret}"

puts url

Running this produces:

Your secret key is: 4rr7kc47sc5a2fgt

https://chart.googleapis.com/chart?chs=200x200&chld=M|0&cht=qr&chl=otpauth://totp/myserver?secret=4rr7kc47sc5a2fgt

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!

bscott — Fri, 23 Sep 2011 00:48:43 +0000

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

bscott — Thu, 02 Dec 2010 23:06:56 +0000

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

Give iotop a try.

SSH Access – Prevent password guessing

bscott — Tue, 27 Jul 2010 19:28:04 +0000

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

bscott — Wed, 09 Dec 2009 02:14:30 +0000

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


    DAV svn

    SVNParentPath /Users/Shared/svn

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

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

Snipts from: CodeThought

Google Chrome on OpenSuSE 11.2

bscott — Wed, 02 Dec 2009 01:21:03 +0000

Google has released official builds of Google Chrome for Linux and Mac OS X
Here is how you install this puppy on openSUSE 11.2

zypper ar -t YUM http://dl.google.com/linux/rp

zypper in google-chrome-unstable

OpenSUSE Linux: Creating Self-Signed SSL Certificates

bscott — Thu, 18 Jun 2009 17:13:41 +0000

Overview

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.

Certificate Authority

The first thing that you’ll need is root access to the server. SSH in and head somewhere secure like /root.

Next, we’ll go ahead and generate our own Certificate Authority key. In this step, we are impersonating someone like Verisign or Thawte. Well, not impersonating, but we are going to do the same thing for ourselves that they would normally do.

To create our key, we’ll run this command:

openssl genrsa -des3 -out ca.key 4096

When we do that, it looks something like this:

[1257][root@mail:~/cert]$ openssl genrsa -des3 -out ca.key 4096
Generating RSA private key, 4096 bit long modulus
...............................................................................................................................++
.................................................++
e is 65537 (0x10001)
Enter pass phrase for ca.key: [enter a pass phrase here for the CA key]
Verifying - Enter pass phrase for ca.key: [verify the same pass phrase here]
[1258][root@mail:~/cert]$

Note that those pass phrases are something you make up right then. You are not authenticating anything, but rather setting up a pass phrase for authenticating later.

Next, we’ll need to use that key to create a certificate. Before we do this, the information that you will enter here is NOT the information you will enter later for your own server. Remember, we are emulating a Certificate Authority here. When we generate our server certificate, we will put in the real information which must differ from what is here. With that, let’s whip out the certificate. Notice that we are making it good for 3650 days, or 10 years. Adjust to your taste. So let’s make the cert, now. This is done with the following command:

openssl req -new -x509 -days 3650 -key ca.key -out ca.crt

And doing this may resemble something like this:

[1306][root@mail:~/cert]$ openssl req -new -x509 -days 3650 -key ca.key -out ca.crt
Enter pass phrase for ca.key: [enter the CA pass phrase from above here]
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:US
State or Province Name (full name) [Some-State]:WA
Locality Name (eg, city) []:Redmond
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Microsoft Corporation
Organizational Unit Name (eg, section) []:
Common Name (eg, YOUR name) []:www.microsoft.com
Email Address []:bill.gates@microsoft.com
[1307][root@mail:~/cert]$

Our Server Key and CSR

Next up on the list is to create a key that corresponds to our server. The first one we made was for the Certificate Authority. This one will be generated by and for our own server. We will do that with this command:

openssl genrsa -des3 -out server.key 4096

The output should look familiar:

[1310][root@mail:~/cert]$ openssl genrsa -des3 -out server.key 4096
Generating RSA private key, 4096 bit long modulus
................................++
....++
e is 65537 (0x10001)
Enter pass phrase for server.key: [enter a pass phrase here for our server key]
Verifying - Enter pass phrase for server.key: [verify the same pass phrase here]
[1313][root@mail:~/cert]$

Again, those pass phrases are something you make up right then. You are not authenticating anything, but rather setting up a pass phrase for authenticating later.

Now… let’s see… oh yeah. Now, we have to create a signing request, or CSR, from the server key we just made. This signing request will usually make a trip to a genuine Certificate Authority to have the key signed and a real, verified, bonafide signed certificate returned back to us. So, to generate our signed certificate, we’ll need to first have a signing request so we can make the signed cert. See how that works?

To create the CSR, we do this:

openssl req -new -key server.key -out server.csr

Now remember, kids. This is the part where we do put in our actual real information because the server does in fact belong to us. Put in the real domain where it says “Common Name (eg, YOUR name) []:”. Fill out everything correctly. And so we do:

[1313][root@mail:~/cert]$ openssl req -new -key server.key -out server.csr
Enter pass phrase for server.key: [enter the pass phrase here for our server key from above]
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:US
State or Province Name (full name) [Some-State]:UT
Locality Name (eg, city) []:Eagle Mountain
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Suse Blog
Organizational Unit Name (eg, section) []:
Common Name (eg, YOUR name) []:www.suseblog.com
Email Address []:my-address@suseblog.com [put in your real email address here]

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
[1323][root@mail:~/cert]$

Sign the Certificate

Now, we are going to take all these files and make them do some voodoo. We are going to sign the signing request using the Certificate Authority certificate and key that we made at the beginning. What we will get is our perfectly forged signed certificate. OK, not perfectly, because we are not a real CA. But we’ll get a pretty darn good signed cert that will work for us rather nicely.

The command we’re going to run looks like this:

openssl x509 -req -days 3650 -in server.csr -CA ca.crt -CAkey ca.key -set_serial 01 -out server.crt

And when we run it, we see something hopefully resembling this:

[1326][root@mail:~/cert]$ openssl x509 -req -days 3650 -in server.csr -CA ca.crt -CAkey ca.key -set_serial 01 -out server.crt
Signature ok
subject=/C=US/ST=UT/L=Eagle Mountain/O=Suse Blog/CN=www.suseblog.com/emailAddress=my-address@suseblog.com
Getting CA Private Key
Enter pass phrase for ca.key: [enter the CA pass phrase from above here]
[1332][root@mail:~/cert]$

Generate server.key That Won’t Prompt for Password

Now, we have a little problem. Our server.key file will cause apache2 to prompt us for a password every time it starts. We need to fix it so that doesn’t happen. We’ll do that with these three commands:

openssl rsa -in server.key -out server.key.insecure
mv server.key server.key.secure
mv server.key.insecure server.key

When we run these commands, here’s our output:

[1354][root@mail:~/cert]$ openssl rsa -in server.key -out server.key.insecure
Enter pass phrase for server.key: [enter the pass phrase here for our server key from above]
writing RSA key
[1354][root@mail:~/cert]$ mv server.key server.key.secure
[1354][root@mail:~/cert]$ mv server.key.insecure server.key
[1354][root@mail:~/cert]$

Placing the Files

At this stage, you should now have a bunch of files. These, in fact:

[1354][root@mail:~/cert]$ ll
total 32
drwxr-xr-x  2 root root 4096 2008-06-02 13:54 .
drwx------ 10 root root 4096 2008-06-02 13:35 ..
-rw-r--r--  1 root root 2529 2008-06-02 13:07 ca.crt [CA certificate]
-rw-r--r--  1 root root 3311 2008-06-02 12:58 ca.key [CA key]
-rw-r--r--  1 root root 2049 2008-06-02 13:32 server.crt [our server certificate]
-rw-r--r--  1 root root 1748 2008-06-02 13:23 server.csr [our server signing request]
-rw-r--r--  1 root root 3243 2008-06-02 13:54 server.key [our password-less server key]
-rw-r--r--  1 root root 3311 2008-06-02 13:13 server.key.secure [our passworded server key]
[1355][root@mail:~/cert]$

Just having them doesn’t get us anywhere, so let’s get them installed. First, we are going to change some permissions, because we don’t want just anyone having access to these files. To apply the appropriate permissions, run this:

chmod 0600 server.key.secure server.key server.csr server.crt

Now, here’s where things depend on the distribution that you are using. I will describe what I am doing so that if you are not on OpenSUSE, you will still be able to get this working.

In OpenSUSE, the apache2 config directory is located at /etc/apache2. Underneath that, there are a handful of directories. The three we care about are /etc/apache2/ssl.crt, /etc/apache2/ssl.csr, and /etc/apache2/ssl.key. The server.crt needs to be moved to /etc/apache2/ssl.crt. The server.csr file needs to be moved to /etc/apache2/ssl.csr. And the server.key file needs to be moved to /etc/apache2/ssl.key:

[1348][root@mail:~/cert]$ mv server.key /etc/apache2/ssl.key/server.key
[1349][root@mail:~/cert]$ mv server.crt /etc/apache2/ssl.crt/server.crt
[1349][root@mail:~/cert]$ mv server.csr /etc/apache2/ssl.csr/server.csr
[1349][root@mail:~/cert]$

Yep, pretty complex stuff, moving files.

Now, we need to make a handful more edits to some files, and we’re just about there.

System Configuration

First thing is to edit /etc/sysconfig/apache2. Search through that file for the directive called APACHE_MODULES. Make sure you see ’ssl’ in there. If not, add it. Then, search through the file and find APACHE_SERVER_FLAGS. Make sure it has ‘SSL’ in it. If not, add it. Save and close the file.

You can also manage apache’s modules with the ‘a2enmod’ command. To view the list of loaded modules, run ‘a2enmod -l’.

Next, open up the config file that tells apache2 which ports to listen on. In OpenSUSE, this file is /etc/apache2/listen.conf. Rip that bad boy open. You will see the following line:

Listen 80

Add a new line for port 443, our HTTPS port, so that it looks like this:

Listen 80
Listen 443

Then, look for the following line:

NameVirtualHost *:80

Add a new line for port 443, our HTTPS port, so that it looks like this:

NameVirtualHost *:80
NameVirtualHost *:443

Save and quit.

Virtual Host Configuration

In OpenSUSE, it’s really easy to have virtual hosts on a machine. I have like 10 on mine. One of them is my blog, www.suseblog.com. Well, to make this easy, in OpenSUSE, the virtual domain configuration files are located in /etc/apache2/vhosts.d, each with their own name. My www.suseblog.com configuration file is called suseblog.conf. To set up SSL for this virtual host, just duplicate the file and give it another name. In my case, I named it ssl-suseblog.conf.

Now, we’re going to open up that file and add like 4 lines to it. No sweat.

At the top of the file, there is a line that looks like this:

Change the port from 80 to 443, so it looks like this:

Then, go down a ways and add these lines:

SSLEngine on
SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
SSLCertificateFile /etc/apache2/ssl.crt/server.crt
SSLCertificateKeyFile /etc/apache2/ssl.key/server.key

Save and quit on that one, too.

Configure Firewall

We can configure this thing perfectly, but if the firewall doesn’t know to let traffic through, we will not have HTTPS access to the server. Let’s check the firewall really quick to make sure.

Fire up YAST. Go to the Security & Users option on the right, and select FIREWALL from the left. If you do not have a firewall running on the machine, you can just exit now. If you do, you will need to go to ALLOWED SERVICES. In the SERVICES TO ALLOW drop-down on the right, select HTTPS Server. Then click ADD. Then click NEXT, and finally FINISH. You should now have port 443 opened for HTTPS business.

Now, let’s go ahead and restart apache and enjoy our new self-signed self-generated SSL cert on our HTTPS service:

[1426][root@mail:/etc/apache2]$ /etc/init.d/apache2 restart
Syntax OK
Shutting down httpd2 (waiting for all children to terminate)          done
Starting httpd2 (prefork)                                             done
[1427][root@mail:/etc/apache2]$

Conclusion

Well, we’ve concluded. Enjoy.

More info on the mod_ssl page

Article By: SuseBlog