Posts tagged ·



Multiplexed SSH sessions for quicker connection

Comments Off

If you need to open multiple SSH connections to the same host, it can get tedious to re-authenticate for every one. And even with public key authentication and no password, the extra channel eats a bit of bandwidth. The solution is multiplexed SSH sessions: Authenticate once, and the following connections to the same host goes over the same session. It’s dead easy to set up:

In your ~/.ssh/config file add the following lines. (Make sure that file has user permissions only, i.e. 600).

Host *
   ControlMaster auto
   ControlPath ~/.ssh/master-%r@%h:%p

It takes effect immediately. SSH twice to the same host to verify.

Comments Off

Personal Fedora 15 Installation Guide


Here my notes for my Fedora 15 install, again based on Mauriat Miranda’s guide. After you’ve gotten the DVD, this assumes you’re installing on a new 64 bits system, rather than upgrading.

A pleasant addition to the installation process is the ability to add the standard repositories (and any other repositories if you like). This means after a finished install, all basic packages will be up to date.

Third Party Repositories
You’ll need them for various patent encumbered libraries and apps, for playing MP3, DVD, etc.

sudo rpm -ivh
sudo rpm -ivh

Main Packages
For normal use

yum -y install audacity autossh digikam feh geeqie gimp gnupg gnucash gthumb gtkpod htop hugin ImageMagick k3b-extras-freeworld kdebase kdegraphics kino ktorrent lame-mp3x libcddb liberation-fonts-common liberation-mono-fonts liberation-narrow-fonts liberation-sans-fonts liberation-serif-fonts mplayer mencoder mjpegtools mozplugger mp3gain obexfs libreoffice-calc libreoffice-writer parcellite pidgin-otr thunderbird ufraw ufraw-gimp xine xine-lib-extras xine-lib-extras-freeworld xmms xmms-faad2 xmms-mp3 xmms-pulse

For development

yum -y install ant arj bash-completion dosbox dvdauthor dvgrab easymock easytag emacs enblend git gitk gnome-terminal gnome-system-monitor gnuplot htop iftop java-1.6.0-openjdk java-1.6.0-openjdk-javadoc java-1.6.0-openjdk-plugin java-1.6.0-openjdk-src joda-time joda-time-javadoc kdiff3 kover ncftp OpenEXR OpenEXR_Viewers python-dateutil python-mox qemu-launcher qtpfsgui quicksynergy rdesktop rssh subversion transcode unrar vcdimager vdr-mp3 vlc w3m wine wireshark-gnome

MPlayer Codecs

wget -O /tmp/all-20110131.tar.bz2
mkdir -p /usr/lib/codecs
tar -jxvf /tmp/all-20110131.tar.bz2 --strip-components 1 -C /usr/lib/codecs/

DVD Playback

wget -O /tmp/libdvdcss-1.2.10-5.fc15.x86_64.rpm
wget -O /tmp/libdvdcss2-1.2.10-5.fc15.x86_64.rpm
yum --nogpgcheck localinstall /tmp/libdvdcss2-1.2.10-5.fc15.x86_64.rpm /tmp/libdvdcss-1.2.10-5.fc15.x86_64.rpm

Change the SSHD port

You might want to run SSHD on a different port than 22 to avoid the worst influx of random attacks. For this example, let’s go for port 222.

In /etc/ssh/sshd_config, uncomment the Port setting, and change the number to 222.

Port 222

In /etc/sysconfig/iptables, add a line to accept incoming connections on this port. If you like, you can always keep the old as well.

-A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 222 -j ACCEPT

Then, tell SELinux to accept this port by executing as root

semanage port -m -t ssh_port_t -p tcp 222
semanage port -l | grep ssh

Finally, restart the SSHD and iptables daemons. You can now test the new port by logging in locally:
/etc/init.d/sshd restart
/etc/init.d/iptables restart

ssh -p 222 localhost

Adding users

In the last versions of Fedora, the default user and group IDs moved from starting at 500 to start at 1000. However, you might want to keep the old IDs for compatibility with old external drives, NFS mounts, etc. You can and new users with custom user/group IDs simply by

adduser -u 500 myuser

Transferring from an old system

Finally, if you have and old system you need to transfer stuff from, you might want to remember:

  • Crontabs: /var/spool/cron
  • SSH keys: /home/*/.ssh

You might also want to reinstall or retune a few other settings:

Backup over ssh/rsync with rssh restricted user

1 comment

For a backup system to work and be of value when something goes wrong, it needs to have these properties:

  • Fully automated: If you have to think about, you will forget or skip it.
  • Off site storage: RAID will not prevent fire or theft; nor accidentally deleting the wrong file.
  • Secured transfer and access: The backup drive can also be stolen or corrupt.

For the transfer, this already restricts the number of tools to pick from: scp, sftp, rsync. And assuming the files to transfer are large, while bandwidth is limited and/or uptime of source/destination systems are limited is only one left: rsync. It is the only tool which is able to resume a previous transfer.

Rsync can use the ssh protocol to transfer files, thus securing the connection. Furthermore, it can utilize the automated authentication through public key. It does require an ssh server on either source or destination though, which will have to be available on the Internet. Thus it’s necessary to take a few security precautions. Not running sshd on the standard port 22 will already filter out a lot of attacks, so let’s pick another port, e.g. 222.

** First try

For this example, let’s assume a pull-backup, that is the destination machine requests files from the source (user foo at where the original backup file is located. Typically, this will happen on a regular interval, through a cron job. For example, we could imagine running this command every hour (assuming some lock file so we don’t disturb an ongoing sync):

rsync --bwlimit=25 --checksum --partial -e "ssh -p 222" -r /backup

  • bwlimit will limit the transfer to 25 kilo bytes / second, to avoid saturating the line.
  • checksum verifies the file checksum, rather than assuming they are the same only based on size and date.
  • partial enables resuming the download.
  • -e “ssh -p 222″ sets the SSH port used by the source.
  • -r syncs recursivly into directories.

The problem with the last option, though, is that it will overwrite existing files on the destination. Imagine a backup file getting corrupt on the source; it will now propagate the same error to the destination and render both files useless. Thus, instead of syncing a whole directory, we’ll have to find a way to select files to transfer. I wont go into that here, so maybe it will be a later post.

** Automated login

For the above line to work as part of a cron job, the destination has to be automatically authenticated. Public key authentication with SSH is fairly simple to set up. On the destination machine (which is the client in the ssh connection), run this command to generate a key. Do not set a password. Then copy the key over to the source machine (still assuming it runs SSH on port 222).

ssh-keygen -t dsa

scp -P 222 ~/.ssh/

On the source machine, copy the keyfile to its correct location. Assuming .ssh and authorized_keys do not already exist.

mkdir ~/.ssh
chmod 700 ~/.ssh
cp /tmp/ ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

You should now be able to log in from destination to source without having to enter a password:

ssh -p 222

** Restricted shell

The basic feature of ssh is to give you a shell on the remote host. However, in our situation, we’ve just granted the destination machine, and anybody there full access to our machine. We might want to restrict this a bit; only allowing the rsync command to run, without other access. rssh handles this. On the source machine, install rssh, and make sure whatever user is using this shell is in the rsshusers group.

yum install rssh

usermod -a -G rsshusers -s /usr/bin/rssh foo

Modify /etc/rssh.conf and enable rsync access by uncommenting allowrsync.

** Ready to backup

Now everything should be ready to run. I’ll still skip some of the details of the backup script, but assume there is a file on the source machine which lists which file to copy. (Alternatively, lists all file so we can compare what we have and don’t have on the destination). Furthermore, it is assumed that each backup file comes with a corresponding checksum file, e.g. .MD5. The beginning of a script might look like this:

alias backup="rsync --bwlimit=25 --checksum --partial -e 'ssh -p 222' --protocol=29"

backup /tmp
[Determine which file to transfer next, e.g. filename.tar.gz]

backup /backup
backup /backup

There’s a few things to note here:

  • An alias, backup, is used to avoid repeating all the options every time.
  • Since we run sshd on port 222, we have to use the -e option. However rssh will not accept this. The option –protocol 29 is used to work around this incomparability in rsync / rssh. (Unfortunately, it seems rssh is not maintained any more).
  • The list file is assumed to contain the list of available backup files, so we can compare to the files already on the destination machine.
  • The main file and its .md5 file is transferred separately, with the .md5 last. This is so we can use that as a flag to mark a finished transfer. If the transfer of the main file is interrupted, we can resume it when the .md5 is not yet there.

Parsing /var/log/secure


If found an old post from the Fedora Linux Legacy blog interesting: “ssh log parsing and monitoring”. It includes several grep strings and small awk scripts to extract specific pieces of information from the /var/log/secure authentication log.

Some of my favourites:

# List out successful ssh login attempts
cat secure | grep 'Accepted' | awk '{print $1 " " $2 " " $3 " User: " $9 " " }'
cat secure* | sort | grep 'Accepted' | awk '{print $1 " " $2 " " $3 " User: " $9 " IP:" $11 }'

# List out successful ssh login attempts from sudo users
cat /var/log/secure | grep 'session opened for user root' | awk '{print $1 " " $2 " " $3 " Sudo User: " $13 " " }'

# List out ssh login attempts from non-existing and unauthorized user accounts
cat /var/log/secure | grep 'Invalid user'

# List out ssh login attempts by authorized ssh accounts with failed password
cat /var/log/secure | grep -v invalid | grep 'Failed password'