7 Haziran 2010 Pazartesi

qsheff handboook

WHAT IS qSheff?

qSheff is a content scanner which can work with qmail e-mail server. It can
also be used as qmail-queue interface to execute other content scanners.
E-mails that contains spam or virus are blocked at SMTP level. Transfers clean
e-mails to queue.

Because qSheff runs at SMTP level, it fairly reduces servers load by cutting
e-mails before entering queue. For the best performance, it's fully coded in
pure C language.

qSheff offers much better features than alternatives.

Features:

. ClamAv antivirus (With direct domain-socket communication)
. Option to run external content filter or antivirus (custom program)
. Ability to pass internal variables to external programs in the form
  of %%mailfrom%%, %%mailto%%, %%remoteip%%, %%msgfile%% and %%tempdir%%
. Header and body filtering with the support of regular expressions
. Attachment filtering
. Protecting e-mails from predefined origin with ignore list (ignore list)
. Quarantine support for spam and virus
. Ability to store all e-mail traffic to local disk
. Subject tagging for MUA's to write their own filters
. Deleting content of infected e-mails and delivering to user with subject
  tag and predefined message
. Blocking e-mails with broken headers
. Detailed logging within one line
. Logging to custom file or to syslog server
. Clean C source code which is open to further development
. Easy error detection and debugging
. Ability to run with qmail-queue symbolic link after qmailqueue patch
. Support for custom error patch. Can respond with user-defined error codes,
  can return the name of the virus or spam-catching rule
. Ability to inactivate filtering for e-mails from local
. Basic countermeasures for DOS attacks


WORKING THEORY

Without any plugins, qSheff can work like described below:

SMTP  --> tcpserver --> qmail-smtpd --
                                     |
                                      --> qmail-queue -->
                                     |
Local --> MUA --> qmail-inject -------


A qmail system with qsheff installed is shown below:

SMTP  --> tcpserver --> qmail-smtpd --
                                     |
                                      --> qSheff --> qmail-queue -->
                                     |
Local --> MUA --> qmail-inject -------

qmail picture: http://www.nrg4u.com/qmail/the-big-qmail-picture-103-p1.gif

In qmail, e-mail can enter queue in two ways: 1. If e-mail is from remote SMTP
server, with qmail-smtpd, 2. If e-mail from local user, with qmail-inject.
In both ways an e-mail enters queue through qmail-queue. qSheff stays on this
common point and directs all e-mail traffic to itself. There are to ways to
insert qSheff between qmail-queue and qmail-smtpd/qmail-inject

a. qmail-queue is renamed to qmail-queue.orig and qmail-queue is symbolic-
  linked to qSheff:

  # mv /var/qmail/bin/qmail-queue /var/qmail/bin/qmail-queue.orig
  # ln -s /var/qmail/bin/qmail-qsheff /var/qmail/bin/qmail-queue

  From this point, when qmail-smtpd or qmail-inject tried to run qmail-queue,
  qSheff is run with symbolic link and e-mail is delivered to qSheff via
  standart input. After processing own tasks, qSheff runs qmail-queue.orig and
  delivers e-mail from standart output. E-mail goes its way likewise.

b. qmail is patched with qmailqueue patch. This patch is included within qSheff
  distribution under contrib/ folder. With this patch qmail checks for
  QMAILQUEUE environment variable and runs the program claimed there. If
  QMAILQUEUE is defined as /var/qmail/bin/qmail-qsheff, qSheff is run by
  qmail-smtpd or qmail-inject directly. After processing own tasks, qSheff
  runs qmail-queue and delivers via standart output. E-mail goes its way.

qsheff proceeds to one of the below after processing own tasks:

a. Spam or virus is found.

  a) If Subject tag or virus tag is activated, subject is tagged and e-mail
  is delivered to user. If infected, e-mail content is completely replaced
  with a descriptive text and delivered to user afterwise.

  b) If subject tag or virus tag is inactive, responds with PERMANENTLY REJECTED
  If qmail is patched with "custom error patch", user is responded with a
  predefined error message. If quarantine is activated, e-mail is also
  saved to /var/qsheff/quarantine folder.


b. There is an error

  Then, responds with TEMPORARY REJECTED error.

c. "enable_blackhole = 1" is set

  This time, there is no remote response for the above two situations.

d. E-mail is clean

  E-mail is delivered to queue



PLATFORM SUPPORT

qSheff is written to run on different UNIX platforms. Systems below are teste
successfully.

Solaris 5.8 (gcc version 3.4.2)
OpenBSD 3.5 (gcc version 3.3.2)
FreeBSD 4.10 (gcc version 2.95.4 20020320)
FreeBSD 5.4 (gcc version 3.4.2)
GNU istanbuLX/Linux (gcc version 3.4.2)
Red Hat Enterprise Linux ES release 3 (gcc version 3.2.3 20030502)
GNU/Linux Debian (gcc 3.3.5, Debian 1:3.3.5-12)


INSTALLING

Installing qSheff is pretty easy. Before installing, remove other content fil-
tering software if exists (RAV, simscan, mailscanner, old versions of qSheff..)
Afterwards qmail-queue should be like below:

# ls -l /var/qmail/bin/qmail-queue
-rws--x--x 1 qmailq qmail 12396 Nov 28 13:18 /var/qmail/bin/qmail-queue

In orter to run qSheff, "ripmime" software of PLDaniels should be installed.
Ripmime splits e-mail into header, body and extensions parts. Ripmime can be
downloaded from http://www.pldaniels.com/ripmime/

# fetch http://pldaniels.com/ripmime/ripmime-1.4.0.6.tar.gz
ripmime-1.4.0.6.tar.gz                        100% of  159 kB   31 kBps

# tar -zxf ripmime-1.4.0.6.tar.gz
# cd ripmime-1.4.0.6
# make
# make install
# ripmime -V
v1.4.0.6 - December 12, 2005 (C) PLDaniels http://www.pldaniels.com/ripmime

Antivirus is an optional feature. qSheff, unlike other content filters, can
connect to ClamAv directly via socket for e-mail scanning. Does not run
client software like "clamdscan". This reduces using of system resources and
increases performance of filtering. In order to run other antivirus or
content scanner programs, "custom program" feature is used. Further
information about this feature is given below.

ClamAv can be downloaded and installed from http://www.clamav.net/

For installing and configuring other antivirus software, check their own
documentation.

qSheff can be downloaded from official site.

http://www.enderunix.org/qsheff/

# fetch http://www.enderunix.org/qsheff/qsheff-II-2.1.tar.gz
qsheff-II-2.1.tar.gz                          100% of  129 kB 5208  Bps 00m00s

# tar -zxf qsheff-II-2.1.tar.gz
# cd qsheff-II-2.1

To see installing options:

# ./configure --help
 --enable-debug                 Enable debug messages
 --disable-local-users          Disable the filters for local users
 --enable-syslog                Enable syslog messages
 --enable-backup                Enable backup
 --enable-spam-tag              Enable Spam Tagging
 --enable-virus-tag             Enable virus tagging
 --enable-custom-error          Enable the custom error patch
 --enable-qq-patch              Enable qmailqueue patch

 --with-max-bodyline            Maximum number of lines to filter, default=40
 --with-maxfiles                Maximum numbers of files in a dir.
 --with-qmailgroup              Define qmail group, default=qmail
 --with-qmaildir                Define qmail directory, default=/var/qmail
 --with-clamav                  Enable ClamAv
 --with-clamd-socket            Path to clamd socket, default=/tmp/clamd
 --with-custom-prog             Enable User Defined Program, check qsheff.conf

You can you any of these options.

A typical installation should be like this:

# ./configure --disable-local-users --with-clamav \
   --with-clamd-socket=/var/run/clamav/clamd

Options are described below. Installing should continue like this:

# make && make install
# /usr/local/etc/qsheff-II/install-wrapper.sh

After installing, /var/qmail/bin folder shoul be seen like:

-r-s--x--x  1 root    qmail  36766 17 May 16:57 qmail-qsheff
lrwxr-xr-x  1 root    qmail     27 16 May 15:28 qmail-queue -> qmail-qsheff
-r-s--x--x  1 qmailq  qmail  12396  2 May 15:43 qmail-queue.orig

Options:

 --enable-debug                 Enable debug messages
   Used for printing debugging information to screen in case of any problem

 --disable-local-users          Disable the filters for local users
   qSheff filters local users by default. Bu small corporations does not
   need this. This option deactivates this feature.

 --enable-syslog                Enable syslog messages
   Logging information is sent both to qsheff.log and to syslog. With this
   option, logs can be stored in a remote syslog server.

 --enable-backup                Enable backup
   Enables logging all incoming/outgoing e-mail traffic

 --enable-spam-tag              Enable Spam Tagging
   Instead of rejecting spammed e-mails, qSheff tags subject and delivers
   e-mail to user. Users can store these e-mails in a seperate folder by
   writing their own rules in client side.

 --enable-virus-tag             Enable virus tagging
   Infected e-mail is delivered to user after replacing content with a
   warning text about the virus. This message is predefined as VIRI_CENSOED
   in src/main.h. custom_sign in qsheff.conf is appended to this message
   automatically.

 --enable-custom-error          Enable the custom error patch
   By default, qmail responds to users with "permanently error" in the case
   of spam or virus. Usually this response does not have much information.
   Bu option enables custom-error patch. But qmail should be patched with
   this patch before. Predefined messages are in src/main.h like DEFAULTMSG,
   SPAMMSG and VIRUSMSG. Messages are tagged with "SPAM" keyword or name of
   the virus automatically.

 --enable-qq-patch              Enable qmailqueue patch
   Enables qmail-queue patch. This patch should be applied before. More infor-
   mation is described in Chapter 3 WORKING PRINCIPLES. With this option,
   qSheff is triggered through QMAILQUEUE environment variable, not symbolic
   link. This environment variable usually assigned in /etc/tcp.smtp

 --with-max-bodyline            Maximum number of lines to filter, default=40
   Limits maximum number of lines in an e-mail to filter. Predefined value is
   40. This option is a countermeasure for DOS attacks which can be caused by
   sending very large e-mails. Spam words usually appear in first 10 lines.
   It's not needed to scan all of the body.

 --with-maxfiles                Maximum numbers of files in a dir.
   if --enable-backup is activated, qSheff logs all e-mail traffic. Every OS
   has limit for number of file entries in a folder. If this option is defined,
   qSheff will switch to next folder afterwards. qSheff assumes 32000 by default.

 --with-qmailgroup              Define qmail group, default=qmail
   if qmail is installed with a group id other than "qmail", should be specified
   here

 --with-qmaildir                Define qmail directory, default=/var/qmail
   If qmail is installed other than /var/qmail, should be specified here.

 --with-clamav                  Enable ClamAv
   Activates ClamAv antivirus software. If ClamAv is installed to nonstandart
   folder like /opt/clamav, this folder should be specifed here. Otherwise,
   ClamAv library functions will fail during make.

 --with-clamd-socket            Path to clamd socket, default=/tmp/clamd
   qSheff connects to ClamAv daemon directly throug UNIX socket. Path to socket
   should be specified here if different than /tmp/clamd. Another solution is
   changing LocalSocket variable to "/tmp/clamd" from clamd.conf

 --with-custom-prog             Enable User Defined Program, check
   User can make qSheff run any program or script. 3rd party software, anti-
   virus programs or your own scripts can be run this way. Full path to
   program/script and parameters is given as parameter. Internal variables
   can be passed to custom program like %%mailfrom%%, %%mailto%%, %%remoteip%%,
   %%msgfile%% ve %%tempdir%%. This parameters or path to program can be
   changed within qsheff.conf later.


CONFIGURATION

qSheff configuration files are placed in etc/qsheff-II under install directory

qsheff.conf:

QSHEFFDIR: qSheff folder. Contaions backup, quarantine, spool and tmp folders.
LOGFILE: Specifies the file which qSheff will write logs to.
RIPMIME: Specifies full path to ripmime binary. Automatically detected and
written by qSheff in configure process.
debug_level: Logging level. Default value is 99 and logs everything. If you
set 14, then HEADER debugging informations will not be logged.
  0      ERR       
  2      QUEUE   
  3      VIRUS  
  5      CUSTOM
 11      SPAM 
 13      ATTACH
 15      HEADER
enable_blackhole: If set to 1, no response will be sent to sender of the mail
in case of error, spam or virus
paronia_level: Not yet implemented
drop_empty_from: If set to 1, qSheff rejects mails without a "From:" header.
enable_quarantine: If set to 1, spam or infected mails are quarantined.
enable_ignore_list: If set to 1, does not filter the mail addresses and ip
addresses in ignore list
enable_header_filter: If set to 1, header filter is activated
enable_body_filter: If set to 1, body filter is activated
enable_attach_filter: If set to 1, attachment filter is activated
enable_clamd: If set to 1, ClamAv virus checking is activated
enable_custom_prog: If set to 1, running custom program is activated.
CUSTOM_PROG: Spesifies the full path and parameters of custom program.
CUSTOM_RET_MIN: The minimum return value of custom program in case of a match
CUSTOM_RET_MAX: The maximum return value of custom program in case of a match
For example a custom prog which returns 5 for virus and returns 9 for spam
can be set with 5 as CUSTOM_RET_MIN and 9 as CUSTOM_RET_MAX
CUSTOM_RET_ERR: Value which custom program returns in case of error.
custom_sign: When virus tagging is enabled, this message is appended to the
warning mail. Can be company logo/signature. This message is also contaions
the information message which will be sent to user when "custom error" patch
is applied.
qsheff.attach: The list which attachment filter looks for matching
qsheff.ignore: The list of e-mail and ip addresses which will not be filtered
Regular expressions can be written. qSheff will try to match expressions
with remote side IP and sender email address.
qsheff.rules: Contains qSheff spesific rules. Rules beginning with "h" are
header rules. Rules in the same line like (rule1)(rule2) are operated with
logic AND and rules in different lines are operated with logic OR.


USAGE

After installing qSheff, log file should be examined in order to be sure that
everything is fine.

# tail -f /var/log/qsheff.log
04/05/2006 19:12:39: [qSheff] SPAM, queue=q1146759159-792935-50066, relayfrom=
88.247.172.183, from=`simsek@enderunix.org', to=`simsek@acikakademi.com', subj
=`viagra', size=575, spam=`Subject: viagra', rule=`(Subject:)([vV]iagra)'

17/05/2006 16:59:50: [qSheff] VIRUS, queue=q1147899588-883933-43385, recvfrom=
83.26.32.122, from=`olago@neostrada.pl', to=`biwi@turx.com', subj=`Re: Merry
Christmas!', size=19082, virus=`Worm.Zafi.D',

17/05/2006 17:03:39: [qSheff] HEADER, queue=q1147899819-136265-43522, recvfrom=
84.50.27.182, from=`', to=`', subj=`', size=0,,

If filtering local users is deactivated, attempts from server will not be logged
in log file.

If drop_empty_from=1 is set, attempts without "From:" line will be rejected and
logged with HEADER tag.

If there is an error after qSheff delivers mail to qmail-queue, qmail-queue's
exit value will be logged as exitcode.

17/05/2006 16:24:51: [qSheff] QUEUE, queue=q1147897465-631231-42376, recvfrom=
83.17.118.150, from=`edhzovsc@queretaro.com', to=`alii@linuxxproggramlama.com',
subj=`Fw[36]: Hi !..', size=10240, error=`', exitcode=54


GET HELP

Send your questions about qSheff directly to the maillist. To subscribe send
an empty mail to qsheff-subscribe at lists.enderunix.org reply incoming approval
mail. Maillist address is qsheff at lists.enderunix.org

Maillist archive is at http://news.gmane.org/gmane.mail.qmail.qsheff. Before
asking a question please search list archive and read this document carefully.
Do not forget to check INSTALL and UPGRADE files which are shipped with each
version.

If maillist and documents does not help, you can contact Author directly.

Commercial firms may ask for paid special development.


FAQ

Not yet available.


SUPPORT

You can support qSheff in one of the following ways:

. Provide the required books for the Author
. Support Author financially by ordering books from http://www.acikakademi.com
. Use qSheff and report bugs and wishes to Author
. If installed qSheff with success, provide Author following outputs:
    # uname -a
    # gcc -v
    # /var/qmail/bin/qmail-qsheff -V
. Translate this document to your language


AUTHOR

qSheff has been written by Baris Simsek (simsek at enderunix org). This software
contains patches from other contributors which are mentioned in THANKS file.


12. THANKS

To EnderUNIX for their friendship,
To all users for valuable feedbacks.

for tests:
- Huseyin Yuce
- Omer Faruk Sen
- Afsin Taskiran

for english documentation:
- Doruk Fisek
- Umut Demirhan
- Adnan Sancak

A list of contributors sent some small patches to improve qSheff.
- Atilim Boy 
- Stephan Bielmann

Linux terminalinden ekli e-posta gönderme

Gerekli olduğu durumlarda linux konsolundan bir dosyanın içeriğini e-mail ile göndermek için genellikle mailx kullanırız. Örnek vermek gerekirse:

# cat /etc/apache2/apache2.conf |mail -s apache2.conf emailadresi@alanadiniz.com

Client olarak kullandığınız bilgisayar üzerinde yüklü olan işletim sistemi Windows ise, e-mail'in içerisinde gönderdiğiniz dosya içeriğinin satır sonları ile ilgili sorun yaşayabilirsiniz. Bu gibi durumlarda dosyayı eklenti (attachment) olarak göndermeniz daha sağlıklı olacaktır. Bunun için sisteminizde uuencode var ise eğer (Debian'da içerisinde bulunduğu paket "sharutils". ) Şu komutu kullanabilirsiniz.

#uuencode dosyaadi.uzanti dosyaadi.uzanti| mail -s "baslik" emailadresiniz@alanadiniz.com

Örnek kullanım:

q:/usr/src/qmail/qmail-1.03# uuencode qmail-smtpd.c qmail-smtpd.c |mail -s "qmail-smptd.c ekte" maniaction@gmail.com

q:/usr/src/qmail/qmail-1.03#

#q:/usr/src/qmail/qmail-1.03# uuencode qmail-smtpd.c qmail-smtpd.c |mail -s "qmail-smptd.c ekte" maninthemiddle@gmail.com

Dosyayı bilgisayarınıza indirdikten sonra düzenlemek daha kolay olacaktır.

Aynı şekilde binary formatta çalıştırılabilir dosyaları ya da jpeg resim dosyalarını da gönderebilirsiniz.

SSH FAQ

1. About Secure Shell

This section should answer general questions about Secure Shell and what it does and doesn't do.

1.1. What is Secure Shell?

Secure Shell is a program to log into another computer over a network, to execute commands in a remote machine, and to move files from one machine to another. It provides strong authentication and secure communications over unsecure channels. It is intended as a replacement for telnet, rlogin, rsh, and rcp. For SSH2, there is a replacement for FTP: sftp.

Additionally, Secure Shell provides secure X connections and secure forwarding of arbitrary TCP connections. You can also use Secure Shell as a tool for things like rsync and secure network backups.

The traditional BSD 'r' - commmands (rsh, rlogin, rcp) are vulnerable to different kinds of attacks. Somebody who has root access to machines on the network, or physical access to the wire, can gain unauthorized access to systems in a variety of ways. It is also possible for such a person to log all the traffic to and from your system, including passwords (which ssh never sends in the clear).

The X Window System also has a number of severe vulnerabilities. With ssh, you can create secure remote X sessions which are transparent to the user. As a side effect, using remote X clients with ssh is more convenient for users.

There are two versions of Secure Shell available: SSH1 and SSH2. This FAQ does its best to distinguish when the situation calls for the difference between the two.

1.2 How widespread is its use?

The most current figures available are over 2 million Secure Shell users in over 60 countries. This is not an accurate amount, but an estimate. It also does not necessarily include the different implementations of Secure Shell for different operating systems.

Note that this includes both SSH1 and SSH2 implementations.

1.3 What protocols does Secure Shell use?

It should be noted that the SSH1 and SSH2 protocols are in fact different and not compatible with each other.

For the SSH1 protocol, you can find this information in an old IETF draft available here. It is also available with the latest source distribution for SSH1 at ftp.ssh.com/pub/ssh/ssh-1.2.27.tar.gz.

For the SSH2 protocol, you can find this information in the SSH2 IETF drafts:

http://www.ietf.org/ids.by.wg/secsh.html

The fifth IETF draft for Secure Shell, Generic Message Exchange Authentication For Secure Shell is no longer available and expired after 6 months.

1.4 What encryption algorithms does Secure Shell use?

Secure Shell uses the following ciphers for encryption:

Cipher	SSH1	SSH2
DES	yes	no
3DES	yes	yes
IDEA	yes	no
Blowfish	yes	yes
Twofish	no	yes
Arcfour	no	yes
Cast128-cbc	no	yes

Secure Shell uses the following ciphers for authentication:

Cipher	SSH1	SSH2
RSA	yes	no
DSA	no	yes

Ciphers may be added or deleted later depending on implementations.

1.5 How does Secure Shell authenticate?

Secure Shell authenticates using one or more of the following:

Password (the /etc/passwd or /etc/shadow in UNIX)
User public key (RSA or DSA, depending on the release)
Kerberos (for SSH1)
Hostbased (.rhosts or /etc/hosts.equiv in SSH1 or public key in SSH2)

Since there is quite a big demand for it, there are some patches available for various forms of authentication. It is up to the authors to make those available. If you wish to have a particular type of authentication in Secure Shell, please submit a feature request to the SSH Secure Shell team. For OpenSSH features, please contact the OpenSSH team.

1.6 What does Secure Shell protect against?

Secure Shell protects against (again, from the README):

IP spoofing, where a remote host sends out packets which pretend to come from another, trusted host. Ssh even protects against a spoofer on the local network, who can pretend he is your router to the outside.
IP source routing, where a host can pretend that an IP packet comes from another, trusted host.
DNS spoofing, where an attacker forges name server records
Interception of cleartext passwords and other data by intermediate hosts
Manipulation of data by people in control of intermediate hosts
Attacks based on listening to X authentication data and spoofed connection to the X11 server

In other words, ssh never trusts the net; somebody hostile who has taken over the network can only force ssh to disconnect, but cannot decrypt or play back the traffic, or hijack the connection.

The above only holds if you actually use encryption. Secure Shell does have an option to use encryption of type "none" this is only for debugging purposes, and should not be used.

1.7 What doesn't Secure Shell protect against?

Secure Shell will not help you with anything that compromises your host's security in some other way. Once an attacker has gained root access to a machine, he can then subvert ssh, too.

If somebody malevolent has access to your home directory, then security is nonexistent. This is very much the case if your home directory is exported via NFS.

1.8 What is the difference between SSH1 and SSH2?

The difference between SSH1 and SSH2 is they are two entirely different protocols. SSH1 and SSH2 encrypt at different parts of the packets, and SSH1 uses server and host keys to authenticate systems where SSH2 only uses host keys. SSH2 is a complete rewrite of the protocol, and it does not use the same networking implementation that SSH1 does. Also, SSH2 is more secure.

Because of the different protocol implementation, they are not compatible.

In a nutshell, SSH2 is a rewrite of the SSH1 protocol, with improvements to security, performance, and portability.

1.9 Who maintains Secure Shell?

SSH Communications Security, is the developer of Secure Shell (secsh) protocol and maintains the releases of SSH1 and SSH2. The IETF maintains the Secure Shell standards, which is vendor-neutral. The standards are currently in draft form; once there are two independent implementations available, then they can be submitted as an RFC.

There are currently several implementors, both freeware and commercial, of Secure Shell.

1.10 Can I run Secure Shell legally?

Most likely. It depends on your country's laws for cryptography and which version of Secure Shell that you're using. Check out the information on licensing, cryptography laws, and patents on cryptographic algorithms below.

1.10.1 Licensing

The licensing for SSH2 as of the 2.1.0 release has been completely revised. You can use Secure Shell for free if you are a university user (student, professor, staff, etc) or if you are using it for non-commercial use (playing games, checking personal email, etc.). For any commercial use, you need to have the appropriate license for Secure Shell. Click here for the current licensing information and click here for an FAQ on the licensing from SSH Communications Security.

The UNIX version of ssh 1.2.27 may be used freely for non-commercial purposes and may not be sold commercially as a separate product, as part of a bigger product or project, or otherwise used for financial gain without a separate license. The definition of "commercial use" is generally interpreted as using ssh for anything that would generate financial gain, such as logging into a customers system to do administration, or providing ssh as a secure login to your partners or vendors.

Other licensing is developer-dependent.

1.10.2 Cryptography laws

In some countries, particularly France, Russia, Iraq, and Pakistan, it may be illegal to use any encryption at all without a special permit.

If you are in the United States, you should be aware that, while ssh was written outside the United States using information publicly available everywhere, the US Government may consider it a criminal offence to export this software from the US once it has been imported, including putting it on a ftp site. Contact the Bureau of Export Administration, which is under the Department of Commerce.

There's a really good link that keeps up to date with the Wassenaar Agreement and the cryptography laws throughout the world. Check out Bert-Jaap Koops Crypto Law Survey.

1.10.3 Patents on Cryptographic algorithms

The algorithms RSA and IDEA, which are used by ssh, are claimed as patented in different countries, including the US. Linking against the RSAREF library, which is possible, may or may not make it legal to use ssh for non-commercial purposes in the US. You may need to obtain licenses for commercial use of IDEA; ssh can be configured without IDEA and works perfectly fine without it.

For information on software patents in general, see the League for Programming Freedom's homepage at http://lpf.ai.mit.edu/.

1.11 What operating systems does Secure Shell run on?

From the Secure Shell home page:

For SSH1 and the current release of SSH2 (2.2.0), check out the portability page at http://www.ssh.com/ssh/portability.html. For compatability with OpenSSH, check out http://www.openssh.com/portable.html.

There are also non-commercial ports of Secure Shell for SSH1 including PalmOS, Windows, Macintosh, OS/2, BeOS, WindowsCE, Java, and OpenVMS. See section 2 of this FAQ for information on how to get Secure Shell.

1.12 . Shouldn't I be using only SSH2?

Maintainer's note: Since this brought up an interesting discussion on the mailing list, it seems to be a good idea to incorporate some of the helpful information that folks brought up. Thanks! Also, if someone has a better way to organize this section, please let me know.

The SSH1 protocol is not being developed anymore, as SSH2 is being developed as the standard. Even if you are not using SSH2, many folks are establishing a path towards it. With three implementations (and growing) of SSH2 currently in the works, there is growing support (especially with the SSH2 protocol in IETF draft). However, there are arguments for and against running SSH1.

Note: If you have any additional arguments either way, I'll post them. -AC

There are structural weaknesses in SSH1 which leave it open to additional attacks
SSH1 is subject to a man-in-the-middle attack
SSH1 has more supported platforms
SSH1 supports .rhosts authentication (it's against the draft for SSH2
SSH1 has more diverse authentication support (AFS, Kerberos, etc.)
Performance for SSH2 is not equal to SSH1

Rick Moen posted this software matrix on the mailing list that shows software from diverse authors will perhaps partially explain protocol 1.5's persistence:

Highest protocol version supported in software that is:

Servers

	Straight Proprietary	Gratis-Usage (non-commercial)	Unconditional Gratis-usage	Open Source [1]
OpenVMS	-	-	-	1.5
OS/2	-	1.5	none	none
UNIX	2.0	2.0	none	2.0
Win32	-	2.0	none	2.0

Clients

	Straight Proprietary	Gratis-Usage (non-commercial)	Unconditional Gratis-usage	Open Source [1]
Amiga OS	1.5	1.5	none	none
BeOS	-	1.5	none	none
Java	-	-	none	1.5 [2]
Macintosh	2.0	-	1.5	none
OpenVMS	-	-	-	1.5
OS/2	2.0	1.5	none	none
PalmOS	-	-	1.5	none
UNIX	2.0	2.0	1.5	2.0
Win16	2.0	1.4	none	none
Win32	2.0	2.0	1.5	2.0
WinCE	1.5	none	-	none

[1] As is defined by the Open Source Initiative at http://www.opensource.org/osd.html. The three columns leftwards are breakdowns of all non-open-source categories, i.e., different classes of proprietary licences.

[2] Mats Andersson says MindTerm will soon support secsh 2.0.

Diane Yi of the Beckman Institute had some slides that compare the protocols:
http://www.beckman.uiuc.edu/biss/security/workshops/2000-02/tsld001.htm

If you are installing a daemon, check to make sure your remote clients are connecting to you with the right version of Secure Shell. An SSH1 daemon will only work with SSH1 clients. An SSH2 daemon will work with SSH2 clients. However, an SSH2 daemon built with SSH1 compability will support both SSH1 and SSH2 clients. For more information on building SSH2 with SSH1 compatibility, see Section 9.5

Using ping for N packets! How to

Question: When I execute ping command from the command line, it keeps sending the packets until I hit CTRL-C to terminate the ping command output. How can I execute ping command only for N number of packets and terminate the output automatically?

Answer: Use ping option -c to specify the number of packets. After sending N number of packets, ping command will terminate automatically as explained below.

Ping Command – Interactive Mode

In the following example, you have to press CTRL-C to terminate the ping command output.

$ ping 0
PING 0 (127.0.0.1) 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.023 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.006 ms
64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.004 ms
64 bytes from 127.0.0.1: icmp_seq=4 ttl=64 time=0.005 ms
....

Note: Press CTRL-C to terminate.

--- 0 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 3999ms
rtt min/avg/max/mdev = 0.004/0.008/0.023/0.007 ms

Note: ping 0 — pings the local host.

Ping Command – Non Interactive Mode (Specify number of packets to be sent)

In the following example, ping command will send only 2 packets and you don’t need to press CTRL-C to terminate the output.

$ ping 0 -c 2
PING 0 (127.0.0.1) 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.024 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.006 ms

--- 0 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 999ms
rtt min/avg/max/mdev = 0.006/0.015/0.024/0.009 ms

Ping Command Option -c Usages

Redirect the ping command output to a file

$ ping 127.0.0.1 -c 2 > ping-output.txt

$ cat ping-output.txt
PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.015 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.005 ms

--- 127.0.0.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 999ms
rtt min/avg/max/mdev = 0.005/0.010/0.015/0.005 ms

Redirect to another process. This example shows only the ping output summary (last two lines).

$ ping 127.0.0.1 -c 10 | tail -2
10 packets transmitted, 10 received, 0% packet loss, time 8999ms
rtt min/avg/max/mdev = 0.005/0.006/0.014/0.003 ms

Backport nedir ve nasıl kullanılır?

Backports Nedir?

Backports, Debian için yapılmış bir paket yansısıdır. Testing ve Unstable sürümlerinde oluşturulmuş, yeni yazılımlara ait paketlerin, "stable" sürüm Debian Linux kurulu sistemlerde kütüphane ve paket bağımlılığı sorunu yaşamadan kurulmasını sağlamak amacıyla, stable sürümdeki kütüphanelerle tekrar derlenmiş halini sunar.

Örneklendirmek gerekirse;

Yazının yazıldığı şu tarihte roundcube web mail, stable sürüm Debian paket arşivinde yer almıyor. Fakat ben "Roundcube Webmail" uygulamasını manuel olarak kurmak istemiyorum. Debian paket'ine ihtiyacım var. Eğer sid veya testing paket arşivinden indirip kurmayı denersem biliyorum ki, paket bağımlılıkları ile ilgili birçok sorun çıkacak, bir çoğunu update etmem gerekecek, daha sonra başka bir paket kurulumu sırasında da silmek zorunda kalacağım. Tüm bunlarla uğraşmak yerine "sources.list" dosyasına backports yansısını girip stable sürüm Debian için hazırlanmış paketlerden rahatlıkla kurulum yapabilirim.

Nasıl kullanılır?

/etc/apt/sources.list dosyanızı açıp, metin editörünüzle en alta şu satırı ekleyin:

deb http://www.backports.org/debian lenny-backports main contrib non-free

Dosyayı kaydedip kapattıktan sonra, "apt-get update" komutunu çalıştırarak sisteminizdeki paket listesini güncelleyin. Daha güncel sürümünü yüklemek istediğiniz paket'in adını biliyorsanız şu komutla backports paket arşivinden sorunsuzca yükleyebilirsiniz:

apt-get -t lenny-backports install "paketadı"

"Roundcube Webmail" örneğinden devam edersek şu şekilde:

apt-get -t lenny-backports install roundcube

Eğer update ve backports paket arşivinden kurulum yaparken aldığınız doğrulama hatalarını durdurmak isterseniz aşağıdaki yöntemlerden birini uygulayabilirsiniz:

apt-get install debian-backports-keyring

veya

gpg --keyserver hkp://subkeys.pgp.net --recv-keys 16BA136C
gpg --export 16BA136C | apt-key add -