What more could you want?
Admin
Determine the architecture of your system
Mar 4th
So, how can you tell if the system you are using is 64-bit capable under Linux or just x86?
It’s easy. Run the following command:
$ cat /proc/cpuinfo | grep -y flags
In the output, look for the ‘lm’ (that’s L M) flag.
$ cat /proc/cpuinfo | grep -y flags
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc pni monitor ds_cpl cid cx16 xtpr lahf_lm
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc pni monitor ds_cpl cid cx16 xtpr lahf_lm
The ‘lm’ flag stands for “Long Mode” and is only present on 64-bit processors, and determines that you have the capability of running a 64-bit OS. This is from thefollowing:
/usr/include/asm/cpufeature.h: #define X86_FEATURE_LM (1*32+29) /* Long Mode (x86-64) */
Particularly, on my local system, which runs 32-bit Ubuntu Feisty, I found that the file containing this was in /usr/src/linux-headers-VERSION/includes.
It seems I may have a box to rekick soon, just to give it a whirl.
/cs
Plesk and root email
Feb 28th
God help you if you have Plesk.
But, if you do an you need to receive the system messages emailed to root, simply execute these commands as root on your RHEL server:
# echo `hostname` >> /var/qmail/control/locals
# /etc/init.d/qmail restart
After this, log into the CP, and click Server->Edit. Change the Administrator Email to the address you want root’s mail sent to, and voila! it goes.
This will also work for postmaster and mailer-daemon.
/cs
Passwordless Remote Login with SSH keys
Feb 23rd
I log into my server several times a day through SSH. Sometimes, it gets a little frustrating trying to type that oh-so-secure random password every time. I’m a hunt’n'peck typist, and typically get my password wrong a few times.
So, I’ve implemented an SSH key setup that I use to connect between machines.
Here’s how:
First things first, on your local box, create a public/private key pair:
$ ssh-keygen -t rsa -C thom
Once you have done that, you will be prompted for a filename in which to save the key pair, and an optional password for the key itself. I think the password negates the use of the key, and chose to leave it blank.
Now, cat out the public key. Mine is located at ~/.ssh/id_rsa.pub:
$ cat ~/.ssh/id_rsa.pub
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAsFwZH6hxcjQiErOT+GKJc1T2LZS62gHGPvr4bcy
Y3m5sWoqpz09Kn82ch7SJCG4yxswix9Hy/vvTa09YUqGdBISxkvaz8BZk7fC1YdOTt6R/2cc5CJK
7xMVuBlTvMIXkzQPQ+N1CQx2DOBbeGgqESU7uiahXZYN8HbF5DAwG73CfJMmkNF8lEWQXx
7F2o/R56G8//gx1swHMC/hVYY9zXdRj3zy7ladK7kQ7L6ST06d7ayXd7jnLwSvJRuXiUiLDfBPDTlik
WUruL0egkAoHxyrcCX+vtPJnJXK5hQFG6P7d975xJZLGecEhwMg5qpDmTWcycqEfBEvxd8YVo
AlWJQ== thom
Log into your remote server as you always have, but for (hopefully) the last time. Assuming you have already ssh’d into the box, there should be a .ssh/ directory in the remote user’s home directory. Paste your local public key into the ~/.ssh/authorized_keys file on the remote machine. Create the file if it doesn’t already exist.
Make sure that the authorized_keys file has permissions of 600. Issue the following commands to make sure:
$ chmod 600 ~/.ssh/authorized_keys
$ ls -l ~/.ssh/authorized_keys
Now, you need to make sure sshd is configured to allow for key-based entry. In the /etc/ssh/sshd_config file on your server, make sure the following options are set:
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
I would recommend at this point also making sure that the option “PermitRootLogin no” is set, as allowing root SSH login is a pufickly hu-yooge! security risk!
Now that those options are in place, go ahead and restart sshd for your system. On Linux, issue this command as root:
# /etc/init.d/sshd restart
Now, if everything progressed according to plan, when you login to the remote server, you should be greeted with a shell prompt, not a password prompt.
If you are still having problems, check your work. The .ssh directory’s file permissions should look similar to this:
$ ls -lh ~/.ssh
total 16K
-rw——- 1 thom thom 388 Jan 3 18:01 authorized_keys
-rw——- 1 thom thom 887 Jan 3 18:14 id_rsa
-rw-r–r– 1 thom thom 230 Jan 3 18:14 id_rsa.pub
There you are! No more fumbling with passwords, and still just as secure as ever! Now, I would suggest creating an encrypted USB disk on which to back up your RSA keys.
Labeling your Encrypted USB Partitions
Feb 22nd
So, the other day, I plugged in my USB drive with the encrypted partitions I created, and realized I was tired of having to wonder which one was which before checking the size or contents.
The reason it’s an issue is because I created two encrypted partitions. One is 5MB for SSH and GPG keys and whatnot, and the other is the 512M partition discussed in the article.
To alleviate the naming issue, I found the device-mapper object that corresponds to each partition and issued the following command for watch corresponding name and device-map. Device-mapper basically uses a generic process to map one block device to another:
sudo tune2fs -L nameOfEncryptedPartition /dev/mapper/Luks_crypto_partitionID
Now, when I plug in my USB drive, I am greeted with “enc1″ and “enc2″, which are the set labels for the partitions, rather than a random selection by udev labeling each as disk-N, where N is a digit.
Problem solved.
/cs
Create a Self-Signed Cert with OpenSSL
Feb 17th
Every once in a while, the need arises for a certificate without the exorbitant price tag that comes with Thawte or Verisign. Of course, those outfits will give you a certificate that matches the CA certs built in to common browsers like Firefox and Safari. Or IE. But I don’t like IE. But for a personal email account over SSL or for an admin site for your company, why not create a self-signed certificate?
Using openssl one can do a multitude of cool things, including creating your own self-signed certificate.
Here’s an example of using a self-signed cert for web content.
For the exercises presented here, you’ll need access to the following:
- An Apache Webserver. It will match the configuration options I have presented here.
- A domain name. Just an example.com in your hosts file will work, or visit Network Solutions to purchase one.
- Access to the command line on the server that has your Apache install, with appropriate permissions to edit the configuration.
For my examples, I will be running Red Hat Enterprise Linux 4 (Update 6) and Red Hat’s Apache version for the implementation, and will be running Ubuntu 7.04 Desktop for some of the command examples. Typically, there shouldn’t be much difference in the commands run, but the implementation can vary from distro to distro. Ubuntu and Debian’s stock Apache implementations and configuration are very complex compared to Red Hat’s.
Once you have the requisites taken care of, then let’s get a little familiar with the openssl command.
Open up two terminals, and issue the following command:
$ openssl req -x509 -days 365 -newkey rsa:1024 -keyout hostkey.pem -nodes -out hostcert.pem
Press enter. You’ll see that this will spit out a LOT of information. To sum up, it basically says “Please tell me some information.” You’ll be prompted for the following information:
- Country Name (2 letter code)
- State or Province Name (full name)
- Locality Name (eg, city)
- Organization Name (eg, company)
- Organizational Unit Name (eg, section)
- Common Name (eg, YOUR name)
- Email Address
Some key things to note are that the state should be fully typed out, ie, Texas, not TX. Also, the Common Name is the name of the URL that will be using the certificate, such as secure,ozymo.com.
This will create a hostcert.pem and hostkey.pem file containing the certificate and the ke, respectively:
$ ls -lah *.pem
-rw-r–r– 1 chuck chuck 1.4K 2008-02-17 15:09 hostcert.pem
-rw-r–r– 1 chuck chuck 891 2008-02-17 15:09 hostkey.pem
OK – so, we have our certificate and key now. Let’s give them a couple tests to make sure they work properly.
In the same terminal we just used, let’s issue these two commands to test continuity between the cert and the key:
$ openssl x509 -in hostcert.pem -noout -modulus
$ openssl rsa -in hostkey.pem -noout -modulus
These commands will spit out a modulus of the cert and key, and if they are the same, then the cert and the key match. If they differ, something has gone terribly wrong.
Another test we can set up includes creating a test server and test client, and this is where that other terminal you opened comes in. In the first terminal, which we have been using, issue the following command:
$ openssl s_server -accept 9000 -cert hostcert.pem -key hostkey.pem
This command will be followed by some output and the word “ACCEPT”. This means it is listening on port 9000. Now go to the other terminal, and run the following command as root or with sudo:
$ sudo netstat -ntpl | grep :9000
tcp 0 0 0.0.0.0:9000 0.0.0.0:* LISTEN 1668/openssl
As you can see, the server is listening. In the other terminal, run this command to make a connection. I have included some of the output, as I really wanted to illustrate only two key points in this example:
$ openssl s_client -connect localhost:9000 -CApath /etc/grid-security/certificates | grep handshake
depth=0 /C=US/ST=Texas/L=XXXXXX XXXX/O=The PiRS Network/OU=ozymo.com/CN=www.ozymo.com/emailAddress=chuckstearns@ozymo.com
verify error:num=18:self signed certificate
verify return:1
depth=0 /C=US/ST=Texas/L=XXXXXX XXXX/O=The PiRS Network/OU=ozymo.com/CN=www.ozymo.com/emailAddress=chuckstearns@ozymo.com
verify return:1
SSL handshake has read 1414 bytes and written 252 bytes
As you can see on line three of the ouput, there was a verification error because we have a self-signed certificate, but, on line 8, you can see that the SSL handshake was indeed successful.
So, let’s get this configured in an Apache vhost so that we can have secure, encrypted content. Sounds like fun, right?
First, you will need to upload the certificate. Do this in whichever manner suits you. I used scp.
Log into your server via SSH. Open the Apache configuration file in which your SSL vhosts reside. Add the following lines to enable the certificate we just created:
SSLEngine On
SSLCertificateFile /path/to/hostcert.pem
SSLCertificateKeyFile /path/to/kostkey.pem
I leave the rest of the configuration up to you, as it is your server.
Now, all that has to be done is to restart Apache, and visit the common name you used in the cert with the prefix https://
Remember that you will receive a cert error, because it it self-signed and not registered with any CA. Maybe we’ll cover creating a CA in a later entry.
/cs