Setting up a private, encrypted and authenticated chat server with Ytalk over SSH

My friends and I have had for a long time the intention of creating our own not-megacorporation-based communications services (i.e. chat, video, etc). Today we got around to a first version of that, and since during the course of investigations leading to getting the server to work I saw people having trouble, I thought it might be worth posting my experience.

The basic characteristics of our chat server setup are:

• A dedicated machine as the SSH/Ytalk server (a Raspberry pi in our case)
• The server has a user account for every person taking part in the chat.
• Password logins are not allowed. Authentication is based on RSA identities.
• Chat activity actually takes place among SSH sessions within the server. That is, the chat is among local user accounts of the server.

I will try to be both concise but explicit enough so that you can reproduce our results. So, for the sake of the explanation, say we are three people wanting to chat: alice, bob and myself, luis. In my server, a raspberry pi, I start with the default user account pi, which has superuser priviledges. The base system is Debian 7.0. The procedure is divided in the following sections:

1. Software installation and setup
2. User accounts creation and configuration
3. Trial of the chat server

Software installation and setup

1. As usual, start by upgrading your system:
sudo apt-get update
sudo apt-get upgrade

2. Now proceed with the actual packages. I include the SSH server for completeness:
sudo apt-get install ytalk openssh-server
apt-get will ask your confirmation on installing additional packages, in particular, openbsd-inetd and talkd. This is fine.
3. Here comes the interesting part: The stock talkd configuration for inetd makes a few assumptions that impede ytalk working right after installation. First, we need to create a dummy user account, belonging to the tty group:
sudo usermod -a -G tty talkd

4. Then you need to update the /etc/inetd.conf configuration file of inetd so that it invokes talkd in the proper way. The lines:
talk dgram udp wait nobody.tty /usr/sbin/in.talkd in.talkd
ntalk dgram udp wait nobody.tty /usr/sbin/in.ntalkd in.ntalkd
Must be turned into:
talk dgram udp4 wait talkd.tty /usr/sbin/in.talkd in.talkd
ntalk dgram udp4 wait talkd.tty /usr/sbin/in.ntalkd in.ntalkd
(Thanks to this bug report and this tutorial for their illuminating details!)
5. For sanity, check that the file /etc/hosts assigns the IP address 127.0.0.1 to your hostname, which you can find in the file /etc/hostname.
6. Finally enable inetd:
sudo service openbsd-inetd restart

7. To disable password-based logins into the server, add/modify the following lines in your /etc/ssh/sshd_config file:
ChallengeResponseAuthentication no
PasswordAuthentication no
UsePAM no
PermitRootLogin no
(Taken from this blog post). This will force all chat users (and the server owner as well!) to register their SSH public keys, putting them into their user’s ~/.ssh/authorized_keys file.

User accounts creation and configuration

1. The machine owner will have to create the user accounts for each chat participant, and place their individual public keys into their home directories. The creation is very simple:
sudo adduser alice

2. Then comes the registration of the user’s public key to enable logging into the server. The user (i.e. alice) needs to send the contents of its local ~/.ssh/id_rsa.pub file (the public key) to the server owner, through any means available (email, etc). The server owner then does:
sudo -u alice -i
mkdir ~/.ssh
chmod og-wrx ~/.ssh
vim/nano/emacs ~/.ssh/authorized_keys #The contents of the public key are inserted into this file
chmod og-wrx,u=rw ~/.ssh/authorized_keys


Trial of the chat server

Usage of the server is very simple: Log into the machine and do:
ytalk alice

Your partner will receive a ytalk notification. To reply, your partner only needs to do:
ytalk luis

And now both you and your partner will be chatting together. Pressing the escape key at any moment will bring up ytalk‘s menu. For more information, read the man pages.

In a nutshell: Add permissions with configuration files in /etc/sudoers.d

I have been trying to set default permissions for my own user in my machine ((K)Ubuntu 11.10), in order to setup automation scripts for i.e. mounting filesystems at logon, changing permissions, etc. After looking around, I found very useful posts like this one and this other, and I decided to put my conclusions on the following short list:

• You need to use sudo visudo to edit the base sudoers file.
• If you run sudo visudo you may notice there is a line that reads #includedir /etc/sudoers.d. Never mind the # character, this line is enabled, not commented out as one may unsuspectingly assume. Just don’t touch it.
• To create a new set of permissions, follow these steps:

1. Create a configuration file, elsewhere not in the /etc/sudoers.d directory. Don’t name it with ‘~‘ characters or periods (‘.‘). Example:

$ nano mount_conf

2. Fill it up with the settings you will use. This thread does a nice introduction at making these settings up. Example:

# Enable me to mount/umount simply
Host_Alias HOST = your_machine_name. You can get it by running cat /etc/hostname

Cmnd_Alias MOUNT    = /bin/mount,/bin/umount
Cmnd_Alias FILEPERM = /bin/chown

your_username HOST=(root) NOPASSWD:MOUNT,FILEPERM

3. Save it, and now prepare it for moving it into the /etc/sudoers.d directory:

$sudo chown root:root mount_conf
$sudo chmod 0440 mount_conf
$sudo mv mount_conf /etc/sudoers.d/

4. Check everything went fine, by running sudo -l. Example output:

$sudo -l
Matching Defaults entries for luis on this host:
 env_reset

User luis may run the following commands on this host:
 (ALL) ALL
 (root) NOPASSWD: /bin/mount, /bin/umount, (root) /bin/chown

Hopefully you’ll be able to mount and umount filesystems, and also change ownership of files, if you follow the example. You will still need to prepend sudo to the invocation of the command, but then it won’t ask for your password.

Hello world!

Welcome to my blog!

In here you will find thoughts and experiences I get from life, technical discussions and tips I learn from my studies and job.

This is the beginning of the realization of an idea I had for quite a bit of time, about solidifying some of my ideas somewhere before they go into oblivion.

I hope you will enjoy/find useful the contents of this blog, feel free to lurk around…

 

Accelerate your (matrix) computations with ACML on (K)Ubuntu 11.10

(This is an extension of this post)

I had to build the Meep FDTD simulator from MIT for my thesis project, even though it is available in Ubuntu from the “stock” repositories. One of the most common uses of the FDTD method is the one-shot computation of the broad-band spectrum of a response (variable) of the structure being simulated, by means of the harmonic inversion of the transient simulation (basically, a Fourier Transform, although it can get more complex than that). This operation requires the assembly and solution of a (large) linear system, which warrants the use of an optimal runtime configuration for your platform. In my case, it is based on an AMD FX-8120 CPU, which runs at its best with the ACML libraries. In order to transition smoothly from the stock BLAS and LAPACK libraries of your Linux system, here’s what you’ll do:

1. Visit the AMD ACML download page, download the latest version targeted for the Gfortran compiler. If in doubt because of the “int” suffix, check this out. In my case, it is acml-5-1-0-gfortran-64bit (no int64).
2. Unpack and install the package. This should be a no-brainer. Note the installation directory. For me, it is /opt/acml5.1.0
3. Determine your CPU’s capabilities by running:  /opt/acml5.1.0/util/cpuid.exe. In particular, check for FMA3 or FMA4 capabilities. My CPU has FMA4 support.
4. Determine the best variant of the ACML libraries to use:

• If you have any FMA support, focus on the gfortran*_fma* directories. Else, focus on the gfortran* directories. In my case, gfortran64_fma4*
• If yours is a multicore processor and you would like to take advantage of this (highly recommended), look for the ones above which have the _mp suffix. My choice is gfortran64_fma4_mp.

5. Create the alternatives entries to replace the stock or standard ones. To suit your case, you’ll need to modify the paths in the commands below as is appropriate (matching text colors if it helps):

sudo update-alternatives --install /usr/lib/libblas.so libblas.so /opt/acml5.1.0/gfortran64_fma4_mp/lib/libacml_mp.so 60 --slave /usr/lib/libblas.a libblas.a /opt/acml5.1.0/gfortran64_fma4_mp/lib/libacml_mp.a
sudo update-alternatives --install /usr/lib/liblapack.so liblapack.so /opt/acml5.1.0/gfortran64_fma4_mp/lib/libacml_mp.so 60
sudo update-alternatives --install /usr/lib/liblapack.so.3gf liblapack.so.3gf /opt/acml5.1.0/gfortran64_fma4_mp/lib/libacml_mp.so 60
sudo update-alternatives --install /usr/lib/libblas.so.3gf libblas.so.3gf /opt/acml5.1.0/gfortran64_fma4_mp/lib/libacml_mp.so 60

Note: If you don’t use the multi-processor libraries (_mp suffix), the target libraries go with no suffix as well (so their names are libacml.a, libacml.so).

6. Test your configuration: either in octave or numpy , create a large (ej. 5000 x 5000) matrix A and compute its SVD:

a = rand(5000, 5000)
svd(a)

Hopefully you’ll see, in your favorite system resources viewer, all cores in your machine being utilized.

I have been able to successfully compile MIT’s harminv against these optimized libraries, and I hope you will be able to do the same with your codes.