Archive for the ‘Network’ Category

Using SSH and SCP without entering password

November 7th, 2009 3 comments
Print Friendly, PDF & Email

When administrating a lot of Unix servers, there are some situation when you need to run a script from one server to another without entering a password. For example, let’s say that you need to take a cold backup of a Oracle database, but before starting it, you need to stop the application running on another server. In your Oracle backup script, you could “ssh” to application server and run a script that would stop the application before starting the backup.  But to do that with a script, you need a way to log on the application server without having to enter a password.

In this article, we will demonstrate how to configure SSH in such a way that it will allow you to log from one server to another, without having to enter a password.  Some environment are using the OpenSSH version on their Linux servers and the commercial Tectia SSH on the AIX servers. OpenSSH and Tectia SSH don’t have the same keys format and depending on the version you are running,  making an automated connection between these two version can become tricky. In our examples, we will demonstrate the setup require, so that user “robert” is able to log from server1 to server2 without having to enter a password in a mixed environment of OpenSSH and Tectia SSH.

OpenSSH server configuration (/etc/ssh/sshd_config)

If you are using OpenSSH and you have secure your ssh environnent, chance are that you disable direct “root” access to your server with the line “PermitRootLogin no” in your ssh daemon configuration file. If you change that line with “PermitRootLogin without-password”, then direct login to “root” would still be refuse.  But, if you have configure your server to accept public key identification (PubkeyAuthentication yes) and that the proper setup is done, you should be able to log on the server with no password.  Below is the Openssh configuration file that I use for all the examples below.

Port                     22
Protocol                 2
SyslogFacility           AUTH
SyslogFacility           AUTHPRIV
LoginGraceTime           120
PermitRootLogin          without-password
PubkeyAuthentication    yes
HostbasedAuthentication  no
PasswordAuthentication  yes
RhostsRSAAuthentication  no
IgnoreRhosts             yes
StrictModes              yes
UsePrivilegeSeparation  yes
AllowTcpForwarding       no
X11Forwarding            yes
Subsystem sftp           /usr/libexec/openssh/sftp-server

The OpenSSH version used for all the examples below is ;

# ssh -V
OpenSSH_4.3p2, OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008

Tectia SSH server configuration (/etc/ssh2/ssh-server-config.xml)

The only action needed to permit public key authentication for users is to list ‘publickey’ as an allowed authentication method in the ssh-server-config.xml file:

  <authentication action="allow">
    <auth-publickey />

Other authentication methods can also be allowed. Place the least interactive method first.

For all the Tectia SSH examples below we used the following version ;

# sshg3 -V
sshg3.bin: SSH Tectia Client 6.1.3 on powerpc-ibm-aix5.1.0.0
Build: 59
Product: SSH Tectia Client

Automating SSH connection from OpenSSH to OpenSSH


Read more…

Categories: Network

Secure Shell Filesystem

October 4th, 2009 No comments
Print Friendly, PDF & Email

sshfsIn this article, we are looking at SSHFS, the Secure Shell Filesystem. We can use it to mount a remote filesystem using the SSH Protocol.  So the information flowing between the two systems is completely encrypted. SSHFS is a client based application, so beside the SSH server, there is nothing to installed on the remote server to use it.  FUSE is a linux kernel module that allow non-privilege user to mount their own filesystem without the help of any kernel code. One of the interesting feature of SSHFS is that you can securely mount a filesystem over the internet, this is impossible with Samba and not very secure with NFS. If you like more information on SSHFS, you can visit the  SSHFS homepage and the Wiki of the SSHFS package. There is also a YouTube video that show how to use SSHFS on a Fedora system. For those interested in a windows version of sshfs, there is a free version available at the Dokan site, you need to install the Dokan Library first, then install SSHFS. I have done some simple test with it and I didn’t had any problem.

Installing fuse and fuse-sshfs

FUSE and FUSE-SSHFS use the ssh protocol, so SSH needs to be installed on our client system. The only required package on the remote system,  is “openssh” (may work with other version of ssh). The package FUSE and FUSE-SSHFS  don’t need to be install on the remote system, only on the local server.  The first thing we  need to do is to get the latest version the “fuse” at this page and “fuse-sshfs” packages from this page and install them on our local system. The package “fuse” is now part of the RedHat/Centos 5.4, but you still need to get “fuse-sshfs” cause it isn’t included. Should the other site be unresponsive, you can download the rpm from Linternux site.

RedHat/Centos 5 fuse-2.7.4-1.el5.rf.i386.rpm fuse-sshfs-2.2-5.el5.i386.rpm
RedHat/Centos 4 fuse-2.7.4-1.el4.rf.i386.rpm fuse-sshfs-2.2-1.el4.rf.i386.rpm
RedHat/Centos 3 fuse-2.7.4-1.el3.rf.i386.rpm fuse-sshfs-2.2-1.el3.rf.i386.rpm
Fedora 10 fuse-2.7.4-2.fc10.i386.rpm fuse-sshfs-2.2-5.fc10.i386.rpm
Fedora 11 fuse-2.7.4-3.fc11.i586.rpm fuse-sshfs-2.2-2.fc11.i586.rpm

# ls -l
total 296
-rw-rw-r-- 1 jacques jacques 255149 Sep  6 13:15 fuse-2.7.3-1.el5.rf.i386.rpm
-rw-rw-r-- 1 jacques jacques  43203 Sep  6 13:15 fuse-sshfs-1.9-1.el5.rf.i386.rpm

# rpm -ivh fuse*
warning: fuse-2.7.3-1.el5.rf.i386.rpm: Header V3 DSA signature: NOKEY, key ID 6b8d79e6
Preparing...             ########################################### [100%]
1:fuse                   ########################################### [ 50%]
2:fuse-sshfs             ########################################### [100%]

Read more…

Categories: Network, Storage

Setting up your own NTP server

July 24th, 2009 6 comments
Print Friendly, PDF & Email

As a system administrator, we must ensure that time synchronization is working at all time. Time synchronization have been proven to be helpful when we try to trace a chain of events that occurs on multiple servers or when trying to synchronize time sensitive-transactions. In this article, we will setup one NTP (Network Time Protocol) server running on RedHat/Centos 5, but it could be applied to the major Linux distribution.  As always, I have tried to make the article to be used a reference source, so that we can come back when ever you will play with the NTP tools.

The configuration have been done on my Linux server at home (gumby –  We will setup a NTP   that will synchronize with NTP servers on the internet and it will answer NTP query on my internal network ( This will allow desktop or laptop to synchronize with this NTP server.

Brief history of NTP

The NTP protocol was born on the Unix operating system around the 1980’s and have been initiated by Dave L. Mills. Currently there are two versions of NTP that can be used intermixed, the version 3 is very stable and it run on a number of operating systems. The version 4 have some enhancements and better support for the latest operating systems. There is also a simplified version of NTP called SNTP (Simple Network Time Protocol RFC2030), but it provides a reduced precision due to a simpler algorithms. Some earlier version of NTP included some programs starting with xntp (like xntpd), with version 4 the naming convention were changed and now all the ntp programs included with package, start with ntp. For more information you can consult the NTP home page.

Functionality overview

NTP use a hierarchical time synchronization structure. The hierarchical level of the time synchronization are called stratum. At the top of this hierarchy, there is a daemon that provide the most accuracy. Atomic clock are stratum zero, it is by far the most accurate method of keeping time with a precision of less than a second lost every 100 million years.  All NTP time server devices are referred to as stratum 1 devices. This is because they are on the next level (strata) down from an atomic clock (a stratum 0 device). Devices that a NTP time server synchronises are known as stratum 2 devices and these too can distribute their time signal to other devices which become stratum 3 and so on.

In large organization, they should be at least one or two NTP servers that synchronize with time server on the internet NTP servers (probably located in the DMZ).  Some NTP servers located in the corporate network, could then synchronize their time with the NTP servers located in the DMZ and be used as corporate NTP servers. This will ensure that all the clients have the same date and time.  Before continuing, I would like to state that the NTP protocol use UDP port 123. To be able to synchronize with its trusted time servers and to respond to client query the firewall configuration must allow UDP traffic to destination port 123.

Read more…

Categories: Network