I am trying to connect my Linux machine to Amazon VPC using end to end IPSec tunnel. I have set all the required VPC objects on Amazon side and now plan to set my Linux Laptop as a VPN gateway. But the only doubt I have is that my Laptop is behind NAT. Though I have opened and re-directed the necessary ports on my NAT device I am not sure if this thing is going to work.

Please let me know if this setup can work. I am trying to follow the following guide

http://openfoo.org/blog/amazon_vpc_with_linux.html

From what I understand so far in order to make this guide work for my setup I need to do some extra configuration. I have also found out that IPSec supports tunnels behind NAT devices but I am not sure if Amazon VPC will support such configuration.

Any help in this matter is highly appreciated.

First thing is that we need to run boxgrinder on CentOS if we would like to build a CentOS AMI and on Fedora if we would like to build a Fedora AMI. The good thing about boxgrinder is that it uses the latest pvgrub kernel images provided by Amazon which basically lets you boot into your own kernel. So gone are the days when we had to use Amazon EC2 kernel. Thanks to Marek Goldmann for making this possible in boxgrinder 0.5

Without wasting much time let’s get started. I am going to build a Fedora 13 AMI for EC2 in this article but you can do the same stuff using CentOS. First of all we will have to install some required packages which are basically the dependencies.

# yum -y install git parted wget rpmdevtools appliance-tools \
sudo libguestfs ruby  rubygems ruby-libguestfs guestfish \
 yum-utils e2fsprogs

Next we need to install the EC2 AMI tools

#  rpm -Uvh http://s3.amazonaws.com/ec2-downloads/ec2-ami-tools.noarch.rpm

Then we need to install couple of gems for boxgrinder which will let us build a AMI for EC2. The following are the gems

# gem install boxgrinder-build
# gem install boxgrinder-build-fedora-os-plugin
# gem install boxgrinder-build-ec2-platform-plugin
# gem install boxgrinder-build-s3-delivery-plugin

Now we need to create a appliance definition file which will be used to build our AMI. This file is basically written in YAML format. The following is the file which I used:

name: Fedora13EC2
summary: My Fedora on EC2
os:
 name: fedora
 version: 13
hardware:
 partitions:
   "/":
     size: 2
packages:
 includes:
   - bash
   - kernel-PAE
   - grub
   - e2fsprogs
   - passwd
   - policycoreutils
   - chkconfig
   - rootfiles
   - yum
   - vim-minimal
   - acpid
   - dhclient
   - iputils
   - openssh-server
   - openssh-clients
   - httpd
   - system-config-firewall-base

Save this file in a directory appliances/ with the name Fedora13EC2.appl. Now we need to create a file which will store our AWS credentials and other important paths to certificate and private key. These are required by boxgrinder to put the image in S3 and register it with EC2.

# vi $HOME/.boxgrinder/plugins/s3
access_key: yourawsaccesskey                        # required
secret_access_key: youawssecretkey             # required
bucket: myownfedora-box                               # required
account_number: youramazonaccountnumber  # required
path: /mnt/images                                 # default: /
cert_file: /root/.ec2/yourcertificate.pem   # required only for ami type
key_file: /root/.ec2/yourprivatekey.pem  # required only for ami type

We need to create the directory /mnt/images which will store the AMI.

# mkdir /mnt/images

Finally we can fire boxgrinder to build the AMI.

# boxgrinder-build appliances/Fedora13EC2.appl -p ec2 -d ami

It will run for few minutes and will end up with something like:

I, [2010-08-07T06:21:58.693095 #17381] INFO — : Image successfully registered under id: ami-

That’s it. So simple right? Now you run this AMI and enjoy !

I would like to encourage people to look into this project. This is really awesome. For more information you can go through the following links
http://community.jboss.org/wiki/BoxGrinderBuildPluginsDeliveryS3
http://community.jboss.org/wiki/BoxGrinderApplianceDefinitionFiles
http://community.jboss.org/docs/DOC-14384
http://cloudpress.org/2010/07/21/boxgrinder-build-0-5-0-release-with-fedora-13-on-ec2-support-and-stormfolio-update/
http://cloudpress.org/2010/06/24/judcon-2010-boston-slides/

In my next post I will cover my experience with passing user data scripts to EC2 AMI while starting the instance and much more to come. Happy hacking

I personally never expected many folks to turn up because of two reasons. One been that many colleges in Bangalore were having end semester exams plus we don’t have much Fedora folks here in Bangalore. Initially we (Me, Ankur, Hiemanshu , Dipjyoti and Rangeen) had a hard time finding out the office. Point to remember GPS in India will not be accurate enough with all these narrow lanes everywhere.

Finally we found the place and till then FSMK folks also started turning up. I would like to specially mention Vignesh, Prabodh and Naveen from FSMK core team who turned up for the party and assisted with the logistics. We had few other people some friends of Rangeen , students of Prabodh’s previous college CMRIT and other FSMK members.

We started with the discussion about why people should use Linux and not Windows. I never expected to start with such discussion in a Fedora release party but I love to be part of such discussion. It was great. Many questions were thrown on us. Why Linux? Linux? Is it user friendly enough? Why would a normal user plan to switch to Linux? People there who were using Fedora for past 4 years had such questions. I respect all the points given by them.

We started answering one by one. Inputs were given by Naveen on how the current scenario is changing and government bodies across India are encouraging FOSS in schools and engineering colleges. The current projects by Knowledge Commons and MHRD were been discussed with all the participants.

Me and Rangeen told the participants about how things (hardware) works out of the box these days with Fedora. How easily if you plug a mobile broadband card you can be sure that it will work without any hassle (all thanks to the great NetworkManager). We discussed why latest hardware sometime doesn’t work on most of the Linux distributions and how things are now changing. Times have changed and we should look towards improving things instead of blaming about them (my personal opinion).

Naveen introduced us to the FSMK activities currently going on. I personally got to know lot from that and looking forward to contribute to the cause FSMK is supporting.

While the hot discussion on various topics related to Linux/Windows was going on we ordered pizza’s for all of us. I would like to mention here how happy was the pizza girl over phone that she told me to not pick her phone after few minutes. She loved my Kannada ring tone

Once the dust of doubts and questions settled down Ankur started giving the Fedora 13 DVD/Live CD media to all the members. We also copied ISO for others who brought USB stick. I personally got DVD 32bit ISO from Ankur. Thanks a lot Ankur because I am writing this blog post from a Fedora 13 loaded laptop 

After that we briefly discussed the new features in Fedora 13 among the participants and touched few special points from the release notes handouts given to them by Ankur and Rangeen

Pizzas had arrived by that time and we ate them all!! It was great having pizza and garlic bread-sticks with jalapeño. Finally we all exchanged our phone numbers and promised to stay in touch

Overall turn out was around 10 + we four Fedora folks (Me, Rangeen, Hiemanshu and Ankur). That was a good figure. We have now aligned ourself with the FSMK and we plan to conduct some good workshops as soon as the college re-opens in Bangalore. Fedora is going to spread everywhere in the air of Bangalore I am sure. We are looking for contributors and FSMK is also planning their strategy on the same grounds. I hope to see some good action coming in next few weeks.

Oh yes, I don’t want to miss this part. After the release party ended me and Hiemanshu planned to end up in pub (purple haze in Kormangla). Ankur and Rangeen didn’t supported us so we went there alone. Hiemanshu had I believe 2 different cocktails and me 1 pitcher of Foster’s

Drink beer use Fedora our motto!! Few pictures were shot by Me, Rangeen, Dipjyoti and Ankur. You can find them here:

http://picasaweb.google.com/dipjyoti.ghosh/Fedora13ReleaseParty#

http://picasaweb.google.com/sherry151/

http://picasaweb.google.com/sanjay.ankur/Fedora13ReleaseParty

I have been running my Eucalyptus private cloud on a single laptop till now and knew that I can’t use brother’s laptop as node because it has windows 7 and fedora 12 was running inside VM. So I started installing eucalyptus 1.6.2 on that VM via source and finished eucalyptus as well euca2ools installation. Created that VM as the head running Cloud controller, cluster controller, storage controller and walrus. Next I switched to my laptop from scratch installed eucalyptus and configured it to run as node. My laptop is super cool. It’s been 4 years I have had this machine but the good thing it has the special processor flags which gives VT support so that I can run fully virtualized VM in KVM (kvm_intel).

The next thing which started bothering me was I didn’t had much space on my laptop left to store the instance copies when it boots up and later runs. But I have a 500 GB hard drive which I can use for this purpose. Created a directory on one of the partitions in my external hard drive and inside my node’s eucalyptus.conf

INSTANCE_PATH="/media/f5a889e3-9300-4565-9cb3-9d14b79ad124/images/"

The other thing I changed in my eucalyptus.conf was the VNET_BRIDGE interface which by default is xenbr0. This works good for XEN but not for KVM. Changed it to following:

VNET_BRIDGE="virbr0"

Then I remember that console thing didn’t worked for me when I first tried eucalyptus on KVM+Fedora 12 sometime back and for that to work I was suggested a patch at the forums. Applied that patch on my /opt/eucalyptus/usr/share/eucalyptus/partition2disk and all was set.

The next big thing to work out was my networking. The two laptops could have been connected to each other via a ad-hoc network but I prefer a cable connection as it makes the image transfer faster. I have a cross cable with me so I used it to connect both the laptops. The cross cable connection was available inside my VMware VM via bridged connection. The only thing I did different was the gateway IP inside my head (brother’s laptop fedora 12 VM running inside VMware) I gave my laptop’s eth0 IP. This was done because my instance will get a IP on the subnet 192.168.122.0/255.255.255.0 and my network was on 192.168.1.0/255.255.255.0. Once I did that I started the instance and later when it booted was able to ssh to it with my private key (password less login).

The other problem I had was sharing internet connection at the same time. I use a reliance usb device for internet connectivity. I attached that to my laptop started the connection created a simple squid proxy configuration which allows 192.168.1.0/255.255.255.0 and configured the same proxy on the fedora 12 VM in my brother’s laptop. This made internet as well as yum (had to made a proxy entry in /etc/yum.conf) working on the VM which was required to install some RPMS from the repos.

Sounds cool, eh? Let’s see a picture of this setup.

In the picture above you can see my laptop on the left hand side connected to my external 500 GB maxtor hard drive, reliance USB device and my brother laptop on the right via cross cable wire.

Though the setup worked and I was able to boot instance and login to them I was not able to see my EBS volume inside the VM. I have updated my forum entry for the same and you can find more information about it here. Let me know if you have any suggestions for me.

Please note that this is a small private cloud facility running out of my home and its scalable so if you got a laptop or a machine which you would like to add to this cloud do let me know.

Signing off for now but the love for machines still not ends up going to office to play more with those.

I have seen lot of people blogging about eucalyptus specifically on Ubuntu Server edition. Well to be frank eucalyptus is a great software and it works with almost al latest linux distributions. Though I haven’t found time to test all the available linux distribution as I am stuck with work and Fedora but I have tested it on centos 5.4 and Fedora 12. Works great!

Few problems I have always faced but the IRC channel for eucalyptus on freenode as well as the online forums have been really helpful in solving my doubts.

I plan to write my experiences with eucalyptus on this blog in times to come. Besides eucalyptus creating virtual appliances in a automated way is also one of the areas I have worked on paste few weeks. This is all specific to fedora right now using boxgrinder. It is a alternative to vm-builder which ubuntu folks have got.

I am a strong support of the fedora project and love the way how the fedora community is structured and functions. Have been associated with it since the beginning (Fedora core 1).

In the end, for now, I would just like to say, cloud computing is the future and open source is the best medium we have all got to implement it.

Cast your vote go to : https://admin.fedoraproject.org/voting

Cambridge was out yesterday night (IST).

And just when the download was about to finish for me I got my Directory Services exams result and I was told that I have passed the exam. w000t. That was the last hurdle in the way to become RHCSS.

Finally I can call myself Redhat Certified Security Specialist.

How awesome all this looks. Brand new fedora on my laptop and desktop machines and RHCSS!!!

For verficiation:-

http://www.redhat.com/training/certification/verify/?rhce_cert_display:certno=804006843818597&rhce_cert_display:verify_cb=Verify

Thanks for accepting me . Those who would like to know more about me just have a look here.

Hope to get some meaningful posts in the future.

Till then Enjoy!

The setup goes something like this:-

I have two RHEL5.2 machines one is station1 and the other is server1. The station1 machine sends the log for local6 facility of any type of priority to server1. But the log send over to server1 is going to be encrypted via stunnel package. Let’s see how:-

Setup at server1

This is going to be our central log server for local6 log facility. First of all we will install the rsyslog package which though comes with RHEL5.2 but is not the default:-

#yum install rsyslog
#service syslog stop
#yum remove sysklogd
#service rsyslog start
#chkconfig rsyslog on


Next we configure rsyslog such that it listens for connections on tcp/61514

#vi /etc/sysconfig/rsyslog


Edit it such that at line 6 it shows:-

SYSLOGD_OPTIONS="-m 0 -t 61514"


Now we need to add this port 61514/tcp to our semanage ports. This will be done via the following command:-

#semanage port -a -t syslogd_port_t -p tcp 61514


Later we can see if the above command have succesfully worked or not by issuing the following command:-

#semanage port -l | grep syslogd_port_t


The output of the above command will be something like this on a default installation of RHEL5.2

syslogd_port_t tcp 61514
syslogd_port_t udp 514


This tells that port 514/udp and port 61514/tcp are SELinux managed for the type syslogd_port_t. Okay that’s what we wanted. For securing the log server we want it to run on a tcp port and that’s why we did all this starting from editing /etc/sysconfig/rsyslog to semanage. Note that all our setups have SELinux in enforcing mode so it’s necessary that we take proper care of SELinux.

Next we restarted the rsyslog service.

#service rsyslog restart


Now we need to configure stunnel on server1 so that it accepts connections from the client on some fix port and forward them to port 61514/tcp running on server1. We will ensure via the iptables that the port 61514/tcp is not directly exposed to the network as well as port 514/udp.

#iptables -A MYCHAIN -p tcp --dport 60514 -j ACCEPT
#service iptables save


This rule opens up port 60514/tcp on server1. This will be the port where stunnel running on server1 will listen for client connections and later forward them to locally running rsyslog service at 61514/tcp.

The package for stunnel was installed default in a base installation of RHEL5.2 so that was not a big deal but if it’s not there in your setup ensure that you have stunnel installed.

After the installation is done we need to configure stunnel. The configuration directory for stunnel is empty but it’s package provide one sample conf file which can be used. To use the provided conf sample just follow the below commands:-

#cd /etc/stunnel
#cp /usr/share/doc/stunnel-4.15/stunnel.conf-sample stunnel.conf


Next we edited the stunnel.conf file according to our requirements and when we completely edited it that’s how it looked:-


; Certificate/key is needed in server mode and optional in client mode
cert = /etc/stunnel/stunnel.pem
key = /etc/stunnel/stunnel.key

; Service-level configuration
[ssyslog]
accept = 60514
connect = 61514


The section [ssyslog] specify which port stunnel will listen to and then which port it will forward the connection too. The destination port is of the local interface (127.0.0.1) as far as I know, haven’t digged much into it so I am not sure. Please feel free to comment on it.

There are number of other variables on top that configures alot of stuff. First is the filepath for the stunnel security certificate, then is the filepath for the stunnel security certificate key, next comes the directory under which stunnel will run (this makes stunnel run in a chroot jail, that’s good for security reason but it’s only available on windows host), after that the user and group with which the application will run and the pid file name and path for stunnel it actually is /stunnel.pid but that’s relative to /var/run/stunnel now, after that we had some performance tuning options which actually came enabled default in the sample conf file so I thought of keeping them up, after that verify=2 is used to verify the other end of the tunnel, the verification is done by checking the security certificate of the other end of the tunnel upto depth level 2 so that checks whether the security certificate of the other end (the client end, in our case station1) is actually signed by the same Certificate Authority (CA) as the one specified by the next option that is CAfile.

Now we need to create the directory in which stunnel will store it’s pid file and will also run in chrooted jail provided by that directory. The group/owner permission of that directory are also important (as specified in stunnel.conf):-

#mkdir /var/run/stunnel
#chown nobody:nobody /var/run/stunnel


Now we need to work on the security certificate stuff. Stunnel uses both self-signed or third party signed certificates. We went with the trusted third party signed certificate. For this we already had a private Certificate Authority running in our network which was used to sign/revoke security certificates of clients in the network.

So first of all we created the key to be used for the certificate and then we generated a certificate signing request for the stunnel certificate and later send that to the certificate authority to sign and return back to us. The certificate authority also sent us a copy of there own certificate which was also kept in /etc/stunnel for configuration purposes. The following command helped in the above task:-

#cd /etc/stunnel
#openssl genrsa -out stunnel.key 2048
#openssl req -new -key stunnel.key -out stunnel.csr
#scp stunnel.csr root@certificate.example.com:/etc/pki/CA


At certificate.example.com we issued the following commands:-

#cd /etc/pki/CA
#openssl ca -in stunnel.csr -out stunnel.pem
#scp stunnel.pem cacert.pem root@server1.example.com:/etc/stunnel/
#rm -f stunnel.*


Note that after we have recieved the signed certificate and CA certificate the first thing we did was secure those by strictly changing there file permissions as shown below:-

#chown root:root /etc/stunnel/*
#chmod 600 /etc/stunnel/*


That was sufficient. Well if you are not running a local CA I would suggest you do run it or have a commerical 3rd party trusted authority sign your certificate. For a small setup self sign certificate will do the job so no need for Certificate author
ity. Also note that the step I mentioned above are completely custom as I want them to be it might be that your setup is different then you have to use different commands and options.

That’s all about stunnel on the server side. Now was the time to start the tunnel, so that’s done just by running the command stunnel.

#stunnel
#ps aux | grep stunnel


The first command runs the tunnel and the next command is given to make sure if stunnel is running in the background successfully or not. The output should be something like this

nobody 4476 0.0 0.3 5060 984 ? Ss 16:46 0:00 stunnel


If you want to make sure that stunnel runs automatically on every boot up just put these lines in /etc/rc.d/rc.local of your system (at the bottom):-

/usr/sbin/stunnel


That’s it the job at server1 is done and now it’s time to proceed at the client side.

Setup at station1

First the same steps as performed on server1 installing rsyslog package and removing the stock sysklogd package via the following commands:-

#yum install rsyslog
#service syslog stop
#yum remove sysklogd
#service rsyslog start
#chkconfig rsyslog on


Now we need to configure the stunnel package on the client side too. As mentioned earlier stunnel comes with the default installation of RHEL5.2 but if it’s not installed just make sure you have it installed. Stunnel actually is part of official RHEL5.2 distribution. Next as done earlier copy the sample configuration file provided by the stunnel package to the stunnel configuration directory.

#cd /etc/stunnel
#cp /usr/share/doc/stunnel-4.15/stunnel.conf-sample stunnel.conf


Edit the file such that it looks as shown below:-

; Certificate/key is needed in server mode and optional in client mode
cert = /etc/stunnel/stunnel.pem
key = /etc/stunnel/stunnel.key

; Service-level configuration
[ssyslog]
accept = 127.0.0.1:61514
connect = 192.168.122.2:60514


The major difference between the stunnel.conf of station1 and server1 is that the stunnel.conf of station1 contains a variable client = yes that differentiates server end and client end in a stunnel.

First we will create the chroot directory in which stunnel will run. As done in the configuring the server section above:-

#mkdir /var/run/stunnel
#chown nobody:nobody /var/run/stunnel


Now it’s time to make the security certificate for this end of the tunnel. We will proceed in the same way as we did while setting up the server end. First we will generate a 2048 bit key. One particular thing which I forgot to mention about this key is that it’s not a password protected key. If it’s compromised that end of the tunnel is compromised. We could have protected the key with a password by specifying option like -des3 to the genrsa command but then we would have to give the password for the key when we ran stunnel that asks alot of overhead when we say our tunnel will automatically start on boot. In that case we have to manually feed in the password for the tunnel to get started.

#cd /etc/stunnel
#openssl genrsa -out stunnel.key 2048
#openssl req -in -key stunnel.key -out stunnel.csr
#scp stunnel.csr root@certificate.example.com:/etc/pki/CA


At certificate.example.com the following commands were issued:-

#cd /etc/pki/CA
#openssl ca -in stunnel.csr -out stunnel.pem
#scp stunnel.pem cacert.pem root@station1.example.com:/etc/stunnel
#rm -f stunnel.*


Now as we did during setting up the server end we secure the configuration file and the certificate files at the client end by modifying the file permissions accordingly:-

#chown root:root /etc/stunnel/*
#chmod 600 /etc/stunnel/*


Now we can start the stunnel at the client end too via the simple command stunnel. If we want to start the tunnel automatically on every boot up it’s simple just add the line /usr/sbin/stunnel in /etc/rc.d/rc.local at the end. To verify that stunnel is running properly or not just issue the old command ps aux | grep stunnel and see if there is any process owned by user nobody with the name stunnel.

Now we will configure the rsyslog service at the client so that it re-directs all the logs for local6 facility to 127.0.0.1:61514 where stunnel will read them up and send them to 192.168.122.2:60514. Note here that 192.168.122.2 is actually server1 but instead of specifying the name I preferred IP address as DNS can be un-available in my setup.

The below line I added in /etc/rsyslog.conf:-

local6.* @@127.0.0.1:61514


Save and exit and then restart rsyslog:-

#service rsyslog restart


Now to test the setup we issued the following command at station1 and while that was running we sniff the packet via wireshark available in RHEL5.2 to intercept what was getting transferred between the two tunnel ends:-

logger -i -p local6.info -t deependra "This is a test log message sent over stunnel"


The output was clearly seen at server1 in /var/log/messages as

Jul 28 18:24:30 station1 deependra[3460]: This is a test log message sent over stunnel


While the communication was happening between the two ends of the tunnel I sniffed the packets transferred between the two ends and it was all encrypted from what I saw.

That’s how I was able to secure my log server communication with clients. There are much better and inbuilt ways to provide security of log server which comes with rsyslog that you can check out at rsyslog website. ]]> http://jeevanullas.in/blog/2008/07/securing-log-server-in-rhel/feed/ 0 http://jeevanullas.in/blog/2008/07/ntp-server/ http://jeevanullas.in/blog/2008/07/ntp-server/#comments Mon, 28 Jul 2008 06:47:00 +0000 jeevanullas http://jeevanullas.in/blog/2008/07/27/ntp-server/ It’s been long since I am using NTP server in my installations here. So I thought to document my setup a bit in order to explain myself what’s going on and to help others world wide so that they can also have a secure setup for Time server in Linux.

Time server is a important part of a network as everybody might be knowing. It is a must if we want to have a network setup which will later consists of kerberos or DNSSEC. It is also needed in windows environment but the configuration for that need not be done in the default case.

I have my test server running latest updated version of Fedora 9. First of all I make sure that my setup have the ntp package. Actually ntp comes default with Fedora distribution so I had no problem in getting the package.

Next step was to make sure I have the correct configuration file setup. So I took a backup of the original file that is /etc/ntp.conf first.

mv /etc/ntp.conf /etc/ntp.conf.bak

Next I wrote the following in a new /etc/ntp.conf

server 127.127.1.0
fudge 127.127.1.0 stratum 1
crypto pw redhat randfile /dev/urandom
keysdir /etc/ntp
restrict default ignore
restrict 127.0.0.1
restrict 192.168.122.0 mask 255.255.255.0 nomodify noquery
driftfile /var/lib/ntp/drift


I know the above options are not the best of the breed but I will explain. First of all if we used our local hardware clock as the time source and then declared it to be at stratum 1 via the fudge line. That may sound madness to everybody. This was done just for testing purpose. Don’t do this in your production servers. Please use reliable time source which can be found at http://support.ntp.org/bin/view/Servers/StratumTwoTimeServers

The next line is the crypto line which tells that my ntpkey files are protected with a password redhat and that the filesource which is used for generating random seed data is /dev/urandom. Note that the password attribute is a important one so this file which /etc/ntp.conf should have a strict permission.


#chmod 640 /etc/ntp.conf
#chown root.ntp /etc/ntp.conf


Now the next line tells the directory where all the ntpkey_* files are stored. In fedora 9 it defaults to /etc/ntp/crypto but I used /etc/ntp which is default in RHEL 5.

Next three lines controls the access to the NTP server. The first of them restricts everybody to use the time server or remotely configure the time server. Next restrict line opens up restrictions for the local interface that is 127.0.0.1 This address can do anything no restrictions apply on it. The last restrict line opens the network 192.168.122.0/24 to use the time server to get time service but it can’t modify or query (status query on time server) the time server itself. That means any client in the 192.168.122.0/24 can configure 192.168.122.1 as it’s reliable time source but it can’t use to connect to that server via ntpq or ntpdc utility.

The last line specify the file name which contains the latest estimate of clock frequency error. This file is owned by ntp user.

In the next step we switch to directory /etc/ntp and generate the host keys and IFF parameters as we are going to use IFF identity scheme in this setup.


#cd /etc/ntp
#ntp-keygen -T -I -p redhat


The above command generates the key files and IFF parameters file. The host key file is protected with a password redhat that we also mentioned in /etc/ntp.conf. The list of files which were generated in my case are listed below


ntpkey_cert_station1.example.com
ntpkey_IFFpar_station1.example.com.3426211635
ntpkey_RSA-MD5cert_station1.example.com.3426211635
ntpkey_host_station1.example.com
ntpkey_iff_station1.example.com
ntpkey_IFFkey_station1.example.com.3426211635
ntpkey_RSAkey_station1.example.com.3426211635


In the above list some are key files and some are symbolic links to them. Next we need to extract the IFFkey so that it can transferred to every NTP clients of this server. We can also protect this key with a password that only we and the NTP client knows.


#ntp-keygen -e -q redhat -p linux > ntpkey_IFFkey_station1.example.com.3426211635
#scp ntpkey_IFFkey_station1.example.com.3426211635 root@server1.example.com:/etc/ntp


The above command generate the IFFkey file but the IFF parameter file itself is protected by a password which we specified in the first ntp-keygen command so with -q we specified that password and with -p we specified the password with which the IFFkey file will be protected (the client needs to know this password). The -e option is used to export the IFFkey.

Now I started the ntpd service and configured it to start automatically at the next boot up. Also I had a custom chain in my iptable based firewall in which I opened the udp/123 port on which ntpd listens.

#service ntpd start
#chkconfig ntpd on
#iptables -A MYCHAIN -p udp --dport 123 -j ACCEPT
#service iptables save

Next was the setup at client side that was pretty easy. First of all I configured as usual the main configuration file /etc/ntp.conf

#chmod 640 /etc/ntp.conf
#chown root.ntp /etc/ntp.conf
#vi /etc/ntp.conf


The client side ntp.conf contained the following:

server station1.example.com iburst autokey
crypto pw linux randfile /dev/urandom
keysdir /etc/ntp


The above lines specify the preferred time server to use be station1.example.com aka 192.168.122.1. The option autokey enables the use of public key cryptography. The next line specify the crypto password with which the client ntpkey_* files will be protected and also specify the random seed source to be used. Next line specify where to find the key data.

Next we generated the client side parameters by the following commands

#cd /etc/ntp/
#ntp-keygen -H -p linux
#ln -s ntpkey_IFFkey_station1.example.com.3426211635 ntpkey_iff_station1.example.com
#ln -s ntpkey_host_server1.example.com ntpkey_iff_server1.example.com


The above generates the host parameters on the client side protected by the password linux and next create some symlinks which later configure the IFF keys at the client side. Note here that the file ntpkey_IFFkey_station1.example.com.3426211635 was sent by the time server which was protected by the password linux.

The list of file with the prefix ntpkey_ in there name at the client side /etc/ntp were finally:-


ntpkey_cert_server1.example.com
ntpkey_host_server1.example.com
ntpkey_IFFkey_station1.example.com.3426211635
ntpkey_iff_server1.example.com
ntpkey_iff_station1.example.com
ntpkey_RSAkey_server1.example.com.3426211933
ntpkey_RSA-MD5cert_server1.example.com.3426211933


Now we started the time service at the client and configured it to start automatically at boot and also open the udp/123 port.


#ntpdate -b station1.example.com
#service ntpd start
#chkconfig ntpd on
#iptables -A MYCHAIN -p udp --dport 123 -j ACCEPT
#service iptables save


The first command in the above code was issued to first synchronize the clock of the client with that of the server then start the time service to later keep that new time in synchronization with the server. It took approx. 5 minutes to get synchronized and after that when issued the fo
llowing command the output was:


#ntpq -cas

#ntpq -c"rv 28241 flags"
assID=28241 status=f624 reach, conf, auth, sel_sys.peer, 2 events, event_reach,
flags=0x83f21


The last command issued returned the flags as 0x83f21 that signifies that the communication with the time server was successful and that IFF identity scheme with cryptography enabled was used.

Client side utilities to check the time configuration are ntpq,ntptrace,ntpdate,nptdc,ntpstat etc.