handyfloss

Already out of ideas for blog posts, I will shamelessly copy some material from my web site.

When connecting to a remote machine (called, e.g., Orpheus), we used to do the following to open a remote X client application:

localmachine> xhost +orpheus
localmachine> ssh orpheus
orpheus> setenv DISPLAY localmachine:0.0
orpheus> xeyes

Doing so is insecure, because 1) all the info sent from/to Orpheus through the xeyes process is transported unencripted (maybe not a big concern with xeyes, but what if the remote application is a dialog where we insert some password?) and 2) xhost only checks for the IP we atribute to Orpheus to accept X input. Any user connected to Orpheus, or even any cracker who knows how to fake a different IP address (that of Orpheus) can send us X input that our computer will accept (e.g., move our mouse, close windows, simulate keystrokes, and display unwanted images in our screen).

The solution would be to forward X traffic over SSH. What we do is basically connect to a machine through SSH, and then accept locally only the X input coming from the remote machine that originates from the SSH process we started.

To do so we must insert the following line into the ~/.ssh/config file in our “localmachine” computer (create the file if it doesn’t exist):

ForwardX11 yes

The next step is more complex, since only the administrator of the remote machine can acomplish it. As root, we have to open the /etc/ssh/sshd_config file (notice the “d”) in the remote machine (e.g. Orpheus), and search for the lines:

#X11Forwarding no
#X11DisplayOffset 10

And set them to:

X11Forwarding yes
X11DisplayOffset 10

After that, we have to restart the SSH daemon. On Debian:

% /etc/init.d/ssh restart

On Slackware:

% /etc/rc.d/rc.sshd restart

A couple of final notes:

The environment variable DISPLAY should NOT be set by ~/.login or some other login script, because this would override the above procedure, and make the X client run over regular TCP. To use the SSH tunneling:

localmachine> ssh -X orpheus
orpheus> xeyes

et voilà!

To take advantage of this system, and make our computer more secure, no machine should be allowed to send X input through xhost, that is, issueing the xhost command should output the following:

localmachine> xhost
access control enabled, only authorized clients can connect

with no “INET:Orpheus.sq.ehu.es”-like lines.

No Comments yet »

Yesterday a new failure from Iberdrola turned the power supply of the whole campus off several times. So, here goes the updated list of blackouts I have been able to compile, with comments if any:

1. 2007-Aug-27 (at least three short power failures, 5-10 minutes apart)
2. 2007-May-19
3. 2006-Oct-21 (they warned beforehand)
4. 2006-Sep-14 (Orpheus fell, the DNSs fell, the DHCP servers fell)
5. 2006-Jul-04 (Orpheus didn’t fall)
6. 2006-Jun-16
7. 2006-Jun-13
8. 2006-Jun-08
9. 2006-Jun-04
10. 2006-May-26 (The card-based automated access to the Faculty broke down)
11. 2005-Dec-21
12. 2005-Dec-13

Summary: 12 blackouts in 621 days, or 51.8 dpb (days per blackout). 100 days since last blackout. Average dpb went up by 4.2.

First post in the series: here

No Comments yet »

Last Saturday night a storm caused a power outage in at least some parts of the campus. My PC at work was not affected (although some colleagues’ were), but communications from the outside were cut all Sunday. This means that I was not able to work from home (had I wanted to, that is), for example.

Here goes the updated list of blackouts I have been able to compile, with comments if any:

1. 2007-May-19
2. 2006-Oct-21 (they warned beforehand)
3. 2006-Sep-14 (Orpheus fell, the DNSs fell, the DHCP servers fell)
4. 2006-Jul-04 (Orpheus didn’t fall)
5. 2006-Jun-16
6. 2006-Jun-13
7. 2006-Jun-08
8. 2006-Jun-04
9. 2006-May-26 (The card-based automated access to the Faculty broke down)
10. 2005-Dec-21
11. 2005-Dec-13

Summary: 11 blackouts in 524 days, or 47.6dpb (days per blackout). 212 days since last blackout. Average dpb went up by 16.5.

First post in the series: here

No Comments yet »

I have been recently (re)made aware of NoMachine’s NX communication programs by my colleage Txema. NX technology is a way of stablishing a connecting from one computer to another one, and create some sort of tunnel through which displayed info (graphics) is transmitted compressed. The communication, of course, is made through SSH secure connection.

Molden opening a file at Arina, a supercomputation cluster I have connected to from Bart, my computer at work, to which I have stablished a NX connection from Heracles, my computer at home. Screenshot taken from Heracles.
(Clic to enlarge)

Veteran Linux users will say “So what’s the big deal?”. Remote connections via telnet, and later with SSH, have been available a long time ago. Exporting the display (that is, making graphical programs opened in the remote computer appear in the local screen) has always been a simple task, and more recently even SSH tunneling has been made available for that task.

However, the key point here is the compression. When running a NX connection, we open a communication channel, running a custom application in the remote machine (for example, we can open the desktop environment, and work as if we were sitting in front of the remote machine), and all the information is compressed, so that the responsivenes of the remote application is as close as possible to applications run in the local computer.

Even though the core NoMachine’s NX code is free software, the client and the server themselves are not, I think. That is a pity, but free alternatives, such as FreeNX are being built upon the free core. From here I wish the best of successes for that project.

No Comments yet »

This post will hardly talk about rocket science, but there’s still a lot of ignorance on the subject.

A lot of people associate p2p with “piracy”, and eMule and BitTorrent with some shady way of obtaining the miraculous software of the big companies like Adobe or Microsoft.

Well, the fact is that p2p is a really advantageous way of sharing digital information through the net. Actually, the philosophy behind p2p is applicable to any process in which information, or some other good, is spread. So what is this philosophy? Simply put, p2p opposes a distributed way of obtaining t the goods, with a centralized one (see figure below).

Figure 1: Scheme of operation of p2p network. From Wikipedia.

I use the BitTorrent p2p technology (with the KTorrent program) quite often, particularly to download Creative Commons music from Jamendo. Lately, I have used KTorrent to download some GNU/Linux CDs, particularly the 4.0 version of Debian, and the beta (and this weekend, the stable) version of Ubuntu Feisty Fawn. With the latter, I have come to feel more deeply the advantages of p2p over centralized distribution of files.

With a centralized way of downloading, there is an “official” computer (the server) that has the “original” version of the information to download, and all the people who want to get the info (the clients) have to connect to that server to get it. The result is quite previsible: if a given piece of software is highly sought, a lot of clients will flood the server, and it will not be able to provide all the clients with the info they request, slowing the transmission down, or even stopping it alltogether for further clients, once saturation is reached. This happened with the release of the Windows Vista beta, when the high demand of the program, and the low resources Microsoft devoted to serving the files, provoked a lot of angry users having to wait for unreasonable periods of time until being able to download it.

This problem could well happen with the release of Ubuntu Feisty Fawn, and in fact this morning connecting to the Ubuntu servers was hopeless. However, unlike Microsoft, Canonical decided to make use of the BitTorrent technology to serve the ISO files, and this made all the difference.

With a p2p way of serving the files, the first clients connect to the server to get the files. However, once they have downloaded a part of the files, they too become servers, and further clients can choose whether to download from the central server or from other clients/servers (usually the decision is taken automatically by the p2p program). As the net of clients grows, and the file flow is balanced, the download speed is maximized for all, and the load on the servers is kept within reasonable limits.

The advantages are clear: each person willing to download some files (e.g. the Ubuntu ISOs) does not become a leech, imposing a burden on the server, but rather a seeder, providing others with the files, and speeding up, not slowing down, the spread of the files. It is, thus the ideal way of distributing files.

However, it has two disadvantages that made Microsoft not use it to spread the Windows Vista beta: since there is no single server, controlled by a central authority, it is not possible to assert how many copies of the files have been distributed. Moreover, since the distribution net is scalable, it can not choke, and thus MS would not be able to claim that the demand for their product was so high that the servers were not able to attend it.

So, for promotional purposes, the p2p is not very good. If your priority is the client, and making the files as widely and quickly spread as possible, then p2p is for you.

No Comments yet »

About 5 months ago I made a post explaining how to use SSH to connect from computer A to computer B without going through the hassle of introducing the password each and every time.

As it happens, my instructions were far from complete, because they relied upon not setting any passphrase, and thus saving the SSH password unencrypted in the hard disk. That way, a malicious user, if able to read your account in computer A, can connect in your name to computer B with no restriction (thanks agapito for pointing this out in a comment to my post).

Next step is, thus, to use use passphrases, but avoiding mayor hassles with ssh-agent.

I will repeat here the instructions in my old post, and extend them. First generate a public/private key pair in computer A:

% ssh-keygen -t dsa

and answer the questions you will be asked, not forgetting to enter a passphrase.

This will create two files in your ~/.ssh/ dir: id_dsa and id_dsa.pub, whith your private and public keys, respectively.

Now, you have to copy the contents of id_dsa.pub into a file named ~/.ssh/authorized_keys in computer B. From that moment on, you will be able to connect to B through SSH without being prompted for your user password in computer B. However, you will be prompted for a password: namely the passphrase that unencrypts the wallet to your actual password (they one you set with ssh-keygen).

To avoid having to introduce this passphrase each time we want to make a connection, we can take advantage of ssh-agent, in the following way. First, we run the agent:

% eval `ssh-agent`

Then we add our key to the agent:

% ssh-add

The above will look, by default, for ~/.ssh/id_dsa, and will ask for the passphrase we introduced when generating it with ssh-keygen.

After the above, all further connections from that terminal (and its children) will benefit from passwordless SSH connections to computer B (or any number of computers that have your A computer’s public DSA key in their ~/.ssh/authorized_keys file). This benefit will be lost whenever ssh-agent stops running, of course.

OK, but I want to have passwordless connections from ALL my consoles!

Then you have to take advantage of the following sintax:

% ssh-agent command

where, command and all of its children processes will benefit from ssh-agent. command could be, of course, startx, or any command you use to start the desktop environment. You will still have to execute ssh-add, and enter the passphrase, but only once in your whole session. You will have to enter the passphrase again only if you log out of the desktop environment and log in again.

OK, but how do I make scripts benefit from this

You will find yourself automating the execution of some scripts sooner or later, for example putting some backups in a cron.

To do so, a ssh-agent must be already running, and you have to make the script somehow hook to it. To do so, include the following code chunks in your scripts:

Perl:

Create the following subroutine:

###################################################
#                                                 #
# Check that ssh-agent is running, and hook to it #
#                                                 #
###################################################

sub ssh_hook
{
  my $user = $_[0] or die "Specify a username!\n";

  # Get ID of running ssh-agent:
  chomp(my $ssh_id = `find /tmp/ssh* -name 'agent.*' -user $user`);
  die "No ssh-agent running!\n" unless $ssh_id;

  # Make this ID available to the whole script, through
  # environment variable SSH_AUTH_SOCK:
  $ENV{SSH_AUTH_SOCK} = $ssh_id;
};

and call it (before any SSH call in the program), like this:

&ssh_hook(username);

tcsh:

setenv SSH_AUTH_SOCK `find /tmp/ssh* -name ‘agent.*’ -user username`

bash:

export SSH_AUTH_SOCK=$(find /tmp/ssh* -name ‘agent.*’ -user username);

In all cases username is the user name of the user making the connection (and having run ssh-agent).

A lot of info was taken from this Gentoo HowTo and this HantsLUG page, and googling for “ssh without password”.

1 Comment »

I have recently downgraded the bandwidth of my internet connection, switching to a flat rate (previously I had a monthly traffic limit, albeit with a wider bandwidth). This means that now I can download to my heart’s content, but it also means that when doing things like upgrading my Debian OS with aptitude, it eats all of my bandwidth, and I can barely do anything else in the Internet, untill all packages are upgraded.

A similar effect can happen when using p2p software like aMule or KTorrent, but these programs have options to throttle down their bandwidth usage (e.g., set maximum download and upload rates).

When dealing with programs that do not have this facility, we can always resort to Trickle, which can set arbitrary limits to any program it is used with. For example:

% trickle -d 20 aptitude upgrade

will run aptitude upgrade as usual, but with a maximum download rate of 20 kB/s. Note: aptitude usually spawns two processes (downloads files in couples, not one by one), and the limit imposed by trickle is applied to each process, so the used download bandwidth will be double that specified in the command line. Or, in other words, if you want aptitude to use X bandwidth, execute:

% trickle -d X/2 aptitude upgrade

2 Comments »

I finally made my new laptop connect with WPA encryption to my WiFi router!!

I could already connect it to WiFi networks with WEP encryption (or no encription at all), but WPA proved harder.

Mini HowTo

1) My setup is the following:

WiFi router: SMC Barricade WBR14-G2
WiFi card in laptop: Intel PRO/Wireles 3945
OS: Ubuntu 6.06 LTS (Dapper Drake)

2) The router settings:

Wireless encryption: WPA/WPA2 Only
Cipher suit: TKIP+AES (WPA/WPA2)
Authentication: Pre-shared Key (yes, I know 802.1X would be more secure… sue me)
Pre-shared key type: Passphrase (8~63 characters)

3) The package one needs to install:

# aptitude install wpasupplicant

4) Making WPA supplicant run:

First, create a config file, by the name /etc/wpa_supplicant.conf, and inside it, write:

ctrl_interface=/var/run/wpa_supplicant
ap_scan=1

network={
  ssid="your_ssid_name"
  scan_ssid=0
  proto=WPA RSN
  key_mgmt=WPA-PSK
  pairwise=TKIP CCMP
  group=TKIP CCMP
  psk="your_preshared_key"
  priority=5
}

At that point, you should make sure that the WiFi is turned on, and that the correct driver is loaded. In my case:

# modprobe ipw3945

Then, to test the WPA supplicant, run:

# wpa_supplicant -Dwext -ieth1 -c /etc/wpa_supplicant.conf

Recall I have used the wext device, instead of the ipw one, that would seem the appropriate one. Well, I read somewhere, that with 2.6.16 kernels and newer, this should be the case. Now I recall that my kernel is 2.6.15… nevermind, it works that way, and not the other (with -Dipw).

Recall also that my wireless device is eth1. Your mileage may vary (but each wireless card model gives rise to a precise device name, don’t worry).

If everything went fine, the output for the above command should be something like:

# wpa_supplicant -Dwext -ieth1 -c /etc/wpa_supplicant.conf
Trying to associate with xx:xx:xx:xx:xx:xx (SSID=’xxxxxxxx’ freq=0 MHz)
CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys
Authentication with 00:00:00:00:00:00 timed out.
Associated with xx:xx:xx:xx:xx:xx
WPA: Key negotiation completed with xx:xx:xx:xx:xx:xx [PTK=CCMP GTK=TKIP]
CTRL-EVENT-CONNECTED - Connection to xx:xx:xx:xx:xx:xx completed (auth)

If you see that “negotiation completed”, it worked (Ctr-C to exit the above).

5) Automating the WPA connection when bringing wireless interface up

Next, I’ll explain the small changes one has to make to /etc/network/interfaces to correctly bring up the interface. As I said, my wireless interface is eth1, so, I added the lines below to the aforementioned config file:

iface eth1 inet dhcp
wireless-essid my_wireless_essid
pre-up wpa_supplicant -Bw -Dwext -ieth1 -c /etc/wpa_supplicant.conf
post-down killall -q wpa_supplicant

And that’s all! Whenever you ifup eth1, you’ll bring up the wireless interface, with WPA encryption working.

4 Comments »

Hace tres días comenté un problemilla que tuve con la conexíon a Internet de Euskaltel.

Pues bien, ahora cuento el final de la historia: el mismo día 18 a la tarde Euskaltel llamó a mi casa para decir que el problema estaba arreglado (dejé el cablemódem encendido, para que hicieran pruebas, si tenían que hacerlas). O en otras palabras: el fallo era de ellos, pero yo no he visto que me hayan pagado el dinero que yo habría tenido que pagarles yo (según ellos) si hubiese venido un técnico y el error hubiese sido mío.

Nota: parece que la tabla de enrutamiento no era, porque sigo teniendo el mismo gateway (lo que no he mirado es la máscara de subred, ¡cachis!).

No Comments yet »

¿Por qué alguien contrataría Euskaltel para su acceso a Internet, en vez de ofertas mucho más competitivas, como Jazztel? Pues está claro: por la atención al cliente, y por la fiabilidad del servicio… ¿no?

Esta mañana mi conexión a Internet me ha dejado de funcionar. Tengo contratada banda ancha a 1Mb con fibra óptica de Euskaltel. La asignación de IP la hacen, como casi todas las ISPs, con DHCP. Pues bien, cuando mi ordenador pedía (a través del cable-módem) una IP, el servidor DHCP me la daba (por lo tanto la conexión funcionaba), pero luego no podía conectarme a nada.

Ya, ya sé: mala configuración de los DNSs. Pues no. El servidor DHCP me daba los DNSs correctos automáticamente. He probado a hacer ping a los servidores de DNS, e incluso a la máquina que me ha adjudicado la IP por DHCP (que obviamente sé que está funcionando correctamente), y ningún ping ha obtenido respuesta. Y tampoco es el firewall, porque las conexiones salientes están prácticamente sin restringir. Estoy por pensar que es la tabla de enrutamiento, ya que mis paquetes salían por una puerta de IP xx.yy.96.1, cuando mi IP era xx.yy.108.zz. Estoy no quiere decir que estén en diferentes subredes (96 y 108 pueden pertenecer a una misma subred), pero si lo fuera, eso explicaría mis problemas, además de demostrar un fallo gordo por parte de algún “genio” de Euskaltel.

Pues bueno, llamo al 1718 (incidencias), y me atiende un tío que lo primero que me dice es que reinicie el ordenador. Joder, tío, que no estoy usando Windows. Conversación:

- Reinicia el ordenador - dice él.
- Es que no uso Windows, uso Linux - contesto
- Reinicia el ordenador, es para reiniciar el módem.
- ¿Y no vale con desenchufar el módem?
- Reinicia el ordenador
- ¿Y si desenchufo el cable RJ45 del ordenador?
- Reinicia el ordenador

Ante su cerrilidad, apago el ordenador, y me quedo con las ganas de decir que a ver si no vale con hacer ifdown eth0 && ifup eth0. Lamentablemente, dudo que supiera qué es un ifconfig aunque uno le mordiera el culo.

Su siguiente consejo es, obviamente, apagar el módem, luego encenderlo, y luego encender el ordenador. Ahora que lo pienso, me queda la duda de si quería que al encender el módem el ordenador estuviera encendido (recien reiniciado), y luego volver a reinicial el ordenador, con el módem encendido… Duda irrelevante, porque eso de reiniciar el módem ya lo había intentado yo, pero bueno.

En fin, que el problema (obviamente) ha seguido igual. Me ha dicho que si quería me mandaban un técnico, y yo le he dicho que, a menos que yo llame de nuevo no (me paso lo mismo, creo, hace un tiempo, y se solucionó “ello solo”).

Lo más gracioso de la conversación fue el final:

- Por si acaso le aviso que si va el técnico y el error está en su ordenador, le cobraríamos XXX - me suelta el tío.
- Ya, y si viene el técnico, y el problema resulta ser culpa de Euskaltel, ¿cuánto cobro yo a Euskaltel? Si el problema fuese de uds, me cobrarían el mes igual, ¿verdad? - le contesto.
- Sí - me dice, un poco “apenado”, pero sin cortarse un pelo.
- Ya veo, muy listos son uds.

Durante un milisegundo me pareció de lo más normal que un técnico viniera y me lo arreglase gratis, pero que si la culpa era mía, me lo cobrasen, porque igual soy un patán que se ha cargado el ordenador.

Pero luego me he dado cuenta de que tienen un morro que se lo pisan. Si el fallo es mío, estaría bien que cobraran… pero solo si cuando el fallo es de Euskaltel te libraran, por ejemplo, de pagar ese mes de conexión. Pero no. No importa si te cortan arbitrariamente la red, si de vez en cuando está saturada, si hay algún fallo: te lo arreglan “gratis” y ya está. Pero si es al revés tienes que pagar… ¡Qué listillos!

1 Comment »