For someone who used and abused ftp, now living with sftp suddenly reminds me how insecure was ftp.
When scripting a linux ftp client, we use redirection to send the commands.
Not only the commands but also the credentials are in clear text.
With sftp, the commands can be saved in a batch file. However, sftp doesn't allow us to send the credentials via this batch file to enforce us to use a more secure encrypted authentication method.

Here is the shell script to automate a sftp session and it should run unattended.

#!/bin/bash
# transfer.sh - sftp auto session
cat << EOF > tmp$$
cd /upload
put report.csv
cd /download
get access.log
quit
EOF
sftp -b tmp$$ -i $HOME/.ssh/id_rsa stranger@citadel
rm -f tmp$$

The batch file is tmp$$ and the shell script creates it on the fly as a temporary file which will be discarded at the end.

The -i parameter indicates the private key.
The default location of the private key is $HOME/.ssh/id_rsa and sftp will search here if we don't specify it.
Actually in the script, we don't need to specify it.
But if we consider to add this script to the crontab, forgetting to specify the absolute path may give unintended result.

Obviously, the remote hostname is citadel and the remote login is stranger.

The next step is to create a public/private key pair.

debstar:~$ ssh-keygen -t rsa -f ~/.ssh/id_rsa

Generating public/private rsa key pair.
Enter file in which to save the key (/home/debstar/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in .ssh/id_rsa.
Your public key has been saved in .ssh/id_rsa.pub.
The key fingerprint is:
c1:21:e 3:01:26:0d:f7:ec:52:0e:0c:90:9b:6e:d8:47 debstar@debadmin

Again, the parameter -f ~/.ssh/id_rsa is redundant because it's the default location.

Then, we have to copy the public key to the remote server.
Precisely its content has to be inserted into the remote file /home/stranger/.ssh/authorized_keys.
We can copy it manually with scp or sftp, but there is an utility called ssh-copy-id to do it painless.

debstar:~$ ssh-copy-id -i $HOME/.ssh/id_rsa.pub stranger@citadel

At this time, if we run the script, it will not ask the password for the remote user but it will ask for the passphrase of the private key.
The solution is to cache somewhere this passphrase with the help of an agent.
To use this agent, we have to run it and add our passphrase into its cache.

debstar:~$ ssh-agent -s > /tmp/ssh.agent
debstar:~$ . /tmp/ssh.agent && rm -f /tmp/ssh.agent
debstar:~$ ssh-add $HOME/.ssh/id_rsa

The passphrase is asked once and for all.
Now we can run the script without typing a passphrase or a password.

... and one more thing, Linux rocks.

Dear all, here is my 2c tips.

Firstly, let me tell you the reasons for which I need to build a package from source :

1. I use Debian Sarge with a quite outdated package version,
2. I need to install a recent version,
3. using the apt tools is preferred,
4. downloading a .deb file and install it doesn't work because of dependencies.
   
   

You may also need to build a package in unstable or testing version if for one reason or another, a recent version is required.

The package in question is Squid because in 2.5.x versions, the authentication scheme used for parent proxy is only Basic HTTP. However NEGOTIATE, KERBEROS and NTLM handling exist only in 2.6.x+ versions.
The 2.5.x versions worked for me before because my parent proxy was an MS-Proxy then MS ISA 2000. Now, they changed it into MS ISA 2004 without the Basic HTTP authentication scheme (security policy) so the need to upgrade.

This example is to build the .deb packages for the last stable version of Squid, at this writing 2.6.1-3. You need to download the files advised by http://packages.debian.org. I choosed the testing version in lieu of unstable because the version in testing is now the stable version of Squid. The files are : squid_2.6.1-3.diff.gz, squid_2.6.1.orig.tar.gz and squid_2.6.1-3.dsc

Issue the command :

$ cat squid_2.6.1-3.dsc

and you'll find the developpement libraries required to build the packages. For me I had to install these :

# apt-get install libpam0g-dev libldap2-dev dpatch po-debconf libdb4.3-dev fakeroot

Here is the steps to build the .deb files needed :

$ dpkg-source -x squid_2.6.1-3.dsc
$ cd squid-2.6.1/
$ gunzip -c ../squid_2.6.1-3.diff.gz| patch
$ fakeroot debian/rules binary

All the binary packages are in parent directory, Actually :

$ ls ../*deb
squid_2.6.1-3_i386.deb
squid-cgi_2.6.1-3_i386.deb
squidclient_2.6.1-3_i386.deb
squid-common_2.6.1-3_all.deb

The next step is to put these .deb files somewhere and update the apt database :
Insert this line in your /etc/apt/source.list. For one liners :

# echo "deb file:/home/debstar/mirror ./" >> /etc/apt/sources.list

$ mv *deb /home/debstar/mirror
$ dpkg-scanpackages /home/debstar/mirror /dev/null | gzip -f9 > /home/debstar/mirror/Packages.gz
# apt-get update
# apt-get install squid-common squid

Et voilà, it may complains of a bash script not found : log_daemon_msg but at least you are now using a recent stable release without upgrading to Sid.


$Id: Signature $
Nirina Michel RATOANDROMANANA

Debian is my 80/20 way.

If you have a network of windows clients and want to build a backup server with GNU/Linux, this 2 cents tip is for you. You need rsync, samba version 3, quota and cwrsync for windows clients.
First, the principles.
(*) Windows clients backup their files via rsync onto the backup server.
(*) If a user want to restore a file, his/her home directory can be browsed inside the network neighborhood as read only.
(*) Configure properly quota so the backup server won't run out of disk space.

On the server side, you need to install samba, winbind, quota, quotatool & rsync.

apt-get install samba winbind quota quotatool rsync

Then you configure you /etc/samba/smb.conf according to your network settings which is for samba and winbind while with /etc/rsync.conf, you don't need to change it. In /etc/samba/smb.conf, the following lines are essentials :

...
[homes]
   comment = Home Directories
   browseable = no
   writable = no
...

Seemlessly, these lines are available here and you just need to uncomment them. It's time to configure quota : You only need to edit /etc/fstab and, accordingly to your partitions (I put the homedir of the domain users under /home/DOMAIN and with its own partition) :

/dev/hda6   /home/DOMAIN   ext3   defaults,usrquota   0          0

This little bash script is helpfull when it's time to apply the quota rule for each domain user thanks to quotatool and wbinfo utilities :

#!/bin/sh
for i in `wbinfo -u`; do
    quotatool -u $i -bq 200M -l '250 Mb' /home/DOMAIN/
    # soft limit of 200 MBytes and hard limit of 250 MBytes
done

On the client side, we need to install cwrsync in a directory e.g C:\CWRSYNC. This batch can be scheduled to run once a day :

SET CWRSYNCHOME=C:\CWRSYNC
SET CYGWIN=NONTSEC
SET HOME=%HOMEDRIVE%%HOMEPATH%
SET PATH=%PATH%;%CWRSYNCHOME%
; The interresting thing begin here
rsync %USERNAME%@backup:
; To list the files on the server
rsync -auvzP /dir_to_backup/ %USERNAME%@backup:
; Copies the files in the directory onto the server
; If you want to assign a drive in the command above

Now, you can run this batch script to check evrything is okay.