Secure Shell Login

• Installation: apt-get install openssh-server

• Configuration: /etc/ssh/sshd_config (see also /etc/pam.d/sshd)

• Restarting: /etc/init.d/ssh restart

• Logs: /var/log/auth.log

OpenSSH, the secure shell service is used to create encrypted tunnels between a client machine and the server. All traffic going through the tunnel is encrypted and thus resistent to eavesdropping.

There are two important aspects of ssh tunnels to understand. First, you must insure you are talking to the actual server when authenticating. If you don't, a proxy can pretend to be the server and happily acts as a man in the middle reading all traffic in clear. In details, it works as such. The client thinks it is talking to the server and send its authentication information which the proxy happily uses right away to connect to the server. The client then starts to send messages encrypted with the client/proxy key to the proxy. The proxy decrypts the message and encrypts it with the proxy/server key before forwarding it to the server. When the proxy gets the response, it decrypts it and encrypts it with the client/proxy key before forwarding it back to the client.

The second important aspect of ssh tunnels is that all applications on the client machine are configured to use a local client port while for the services on the server the connection is coming from a local server port. This is of particular importance for domain name resolution because the DNS queried by the client and server machines will most likely be different.

Once sshd is installed on the server, there are two things to do. First, from the local console, use the ssh-keygen command to retrieve the server ssh key fingerprint and publish it to the people that will be allowed to remotely login into the server. Contributors will use the fingerprint to check they are connecting directly to the actual server. For example:

ssh-keygen -lf /etc/ssh/ssh_host_rsa_key.pub
2048 c2:0d:b3:19:bf:cf:c8:09:f7:bd:76:dc:67:cd:59:7b \
    /etc/ssh/ssh_host_rsa_key.pub (RSA)
    

Second, review the configuration file (/etc/ssh/sshd_config) and edit the settings to match your requirements. The sshd daemon offers to authenticate a user using one of many schemes. It is important to note that, so far, it does not offer to authenticate through a combinaison of schemes. Each scheme has advantages and drawbacks that you need to take into concideration while designing the access policy. For example

The risk of a compromised client is very real when all contributors have just enough skills to administrate their own machines, a laptop they carry around everywhere. Ideally, both are valuable and should be used together by the sshd daemon.

The steps to configure an ssh server and client to use RSA public/private key for authentication.

man ssh-keygen
man ssh_config
	

man sshd_config
          

ssh-keygen -q \
  -f ~/.ssh/hostname_rsa -b 2048 -t rsa
	  

sudo apt-get upgrade sshd
diff -u sshd_config.prev \
    /etc/sshd_config
+ Protocol 2
+ PasswordAuthentication no
+ PubkeyAuthentication yes
+ AuthorizedKeysFile    \
    %h/.ssh/authorized_keys
sudo /etc/init.d/ssh restart

ls -la ~/.ssh
drwx------   .
-rw-r--r--   config
-rw-------   hostname_rsa
-rw-r--r--   hostname_rsa.pub
-rw-r--r--   known_hosts
	  

ls -la ~/.ssh
drwx------ .
-rw------- authorized_keys

ssh -v hostname
...
debug1: Next authentication \
    method: publickey
debug1: Offering public key: \
    /Users/username/.ssh/hostname_rsa
debug1: Server accepts key: \
    pkalg ssh-rsa blen 277
debug1: Authentication succeeded \
    (publickey).
...
	

vi /etc/ssh/sshd_config
+ LogLevel VERBOSE
tail -f /var/log/auth.log
...
... Found matching RSA key ...
... Accepted publickey for \
    username from client \
    port 50818 sstitle
... pam_unix(sshd:session): \
    session opened for user username \ 
    by (uid=0)
... User child is on pid ...
      

Tip: At some point, you might be temped to update sshd or its configuration through a secure shell connection instead of at the local console. In that case, it is recommended to add a cron job that will restore previously known working configuration after a few minutes before logging out. Just in case.

Secure Shell Tunnels

Port 22 is open in the firewall for secure shell login. We will also use it to tunnel all traffic to services on the Virtual Private Network. This also has the advantage of encrypting all traffic regardless of services provided. The server needs to permit tunnels or you will see "permission denied" messages.

diff -u sshd_config.org \
    /etc/ssh/sshd_config
+PermitTunnel yes

ssh -fN \
 -L localport:hostname:hostport \
 hostname
	

tail -f /var/log/auth.log
	  

At that point, you can open any secure shell tunnel you want. Two tunnels are open to access e-mails, one for IMAP and one for SMTP. One tunnel is open to access the private web site. The following code is thus added in the client ~/.bash_profile.

# http://wiki.metawerx.net/wiki/SSHTunnelTroubleshooting
function hostname_tunnels {
    ssh -fN -i ~/.ssh/hostname_rsa \
      -L 9930:localhost:993 -L 5870:localhost:587 \
      -L 8000:localhost:80 hostname
}
    

The first number of the "-L" ssh command line option is the port on the client machine, the hostname between ":" will be resolved on the server machine and the second number is the port to access on the server machine.

Invoking hostname_tunnels from a terminal command line will create the tunnels. Those tunnels will be open until the ssh process is killed. It is possible to also create auto closing ssh tunnels with some more shell scripting if required.

The Mail client is configured with the following parameters.

The private website can be accessed by typing "http://localhost:8000" into your favorite web browser's url bar.

Tip: test the tunnel with the webserver first. It will be easier to debug tunnel related issues rather than mail setup.

Mailman Mailing lists

• Installation: apt-get install mailman

• Configuration: /etc/mailman/mm_cfg.py

• Restarting: /etc/init.d/mailman restart && /etc/init.d/apache2 restart && /etc/init.d/postfix restart

• Logs: /var/log/apache2/access.log, /var/log/apache2/error.log

• Archives: /var/lib/mailman/archives

Mailing lists are used to communicate information to a known and managed set of receipients in a push model. They usually gather questions, answers and the train of thoughts through list threads.

We will create one mailing list called "dev" for contributors to exchange information, questions and answers in a public forum.

Mailing lists are a typical case of mailing aliases and could be setup as such. Most times though, it becomes cumbersome to administer mailing list as plain aliases. Mailmain simplifies the management of mailing lists and adds many more features such as archiving for example.

The steps to create a new mailing list consists of running newlist nameOfMailingList and add appropriate aliases for postfix to find. After this is done, it is usually easier to use Mailman's web interface (i.e. CGI scripts) to configure and manage mailing lists. It is enabled by adding a couple aliases into the apache configuration as such:

...
ScriptAlias /cgi-bin/mailman /usr/lib/cgi-bin/mailman
Alias /pipermail /var/lib/mailman/archives/public
...

	

Fortylines Mailman's web interface is not available publicly and runs on the private web site. It means it is only available through http://localhost:8000/cgi-bin/mailman/ after the ssh tunnels have been started. As a result, if the web_page_url is not properly set in the mailing list configuration, some links will appear broken because pointing to the actual public domain instead of localhost:8000. This can be fixed with the following commands

echo "web_page_url = 'http://localhost:8000/cgi-bin/mailman/'" > listName.conf
sudo /usr/sbin/config_list -i listName.conf listName

Another solution is to create a new list with a different url for the web interface and the email domain.

/usr/sbin/newlist -q -u localhost:8000 -e domainName listName

A publicly open mailing list will usually define the following aliases in /etc/aliases

listName:              "|/var/lib/mailman/mail/mailman post listName"
listName-admin:        "|/var/lib/mailman/mail/mailman admin listName"
listName-bounces:      "|/var/lib/mailman/mail/mailman bounces listName"
listName-confirm:      "|/var/lib/mailman/mail/mailman confirm listName"
listName-join:         "|/var/lib/mailman/mail/mailman join listName"
listName-leave:        "|/var/lib/mailman/mail/mailman leave listName"
listName-owner:        "|/var/lib/mailman/mail/mailman owner listName"
listName-request:      "|/var/lib/mailman/mail/mailman request listName"
listName-subscribe:    "|/var/lib/mailman/mail/mailman subscribe listName"
listName-unsubscribe:  "|/var/lib/mailman/mail/mailman unsubscribe listName"

Of course, as usual, the aliases look-up database needs to be updated.

/usr/bin/newaliases

Later versions of mailman require a "site-wide" mailing list called mailman. If that "mailman" mailing list is not present, the mailman service will refuse to start. Since by default, all lists are public, you will be required to make that list private after creation (see /usr/bin/config_list).

To check mailman was installed and configured correctly, you can send a test e-mail the list. This can be done from the command line with the mailx utility (you will have to install either Ubuntu's package mailx or mailutils).

echo "Hello" | mailx -s "test message" listName

It is sometimes useful to add members to a list through a shell command line and this can be done with the following command line:

sudo sh -c 'echo "newMemberEmailAddress" | /usr/sbin/add_members -r - "mailingList"'
	

And more often than none, it is useful to reset the mailman main password with the command line:

/usr/sbin/mmsitepass