Reverse SSH to twart over-zealous firewalls

I guess it is not very uncommon, since it has happened twice to me, in two sites I have worked. “Over-cautious” sysadmins decide that the University, Institute, Corporation, or whatever, would be safer if connections to the [[LAN]] from outside of it were banned, including the [[Secure Shell|port 22]]. In an effort to avoid making security trample service (how considerate!) the usual solution to allow remote conection is to use [[VPN]].

While VPN might have some advantages over SSH, I prefer the latter by far, and don’t think a proper SSH setup has any lack of security, specially comparing to poorly implemented VPNs. For example, I would never trust something as vital as VPN software to a private company, yet most popular VPNs are proprietary (at least the University of the Basque Country uses the Cisco VPN). It is at least paradoxical that a free and open SSH implementation as e.g. [[OpenSSH]], tested in such a throughout way, and for so long, is dumped, and a black-box solution developed by a profit-driven organization is used instead.

But I digress. I am not interesting in justifying why I want SSH. What I want to show here is a trick I learned reading Esentially, allows one to connect (with SSH) from machine A to machine B, even if machine B has all ports closed (so SSH-ing using another port would be useless either).

The idea (see below) is to connect from machine B to A, which is allowed (and is also the exact reverse of what we actually want to do), in a way that opens a canal for a “reverse” connection from A to B:

(In machine_B)
% ssh -R 1234:localhost:22 username_in_A@machine_A

Then we will be able to use port 1234 (or whatever port we specify in the ssh -R command above) in machine A to connect to machine B, as long as the original ssh -R holds:

(In machine_A)
% ssh username_in_B@localhost -p 1234

The picture shows it better:

SSHing from A to B (dashed red arrow) is disallowed, but the reverse (in black) is not. The ssh -R command line (see code above), opens up the link between ports 22 and 1234 (two-headed black arrow), so that a ssh -p to port 1234 in machine A will redirect us to machine B. If we are asked for a password (at the ssh -p stage), they are requesting the one for machine B, since we are being redirected to machine B.

Please, recall that the above recipe is no less secure than a regular SSH from A to B (if it were allowed), since anyone SSHing to port 1234 in machine A will be automatically redirected to machine B, but undergoing the same security checks as usual (password, public/private key…). Note also that I am talking about what is possible, not necessarily desirable or comfortable. It’s just another tool if you want to use it.


My Ubuntu Jaunty Jackalope upgrade plan

Well, not much of a “plan”, but bear with me.

Ever since using [[Debian]] and [[Ubuntu]], I have installed the OS just once per computer. All software upgrades, including full releases, have been done through upgrades, not re-installations. This means that I have never actually had the need to download any ISO besides the first one used when I bought the computer.

This is fine, but I always felt the compulsion to share my bandwidth with fellow Linux users, and relieve some load from the [[Canonical Ltd.]] servers. So for every new Ubuntu release, I have downloaded one or more (amd64, i386, desktop, alternate…) Ubuntu CD ISOs via BitTorrent, and kept them uploading for some time. However, the full BT download of the ISO is a waste of bandwidth, and unless my later upload share is greater than 1.0, I will have been overloading the servers, not relieving them.

Now, with Jaunty Jackalope, I have a way to fix this. I could have done similarly with previous releases, but I didn’t. Here’s the deal: download the ISO and share it with BitTorrent, but don’t upgrade from the Internet as well. Upgrade from the ISO I just downloaded! In the past I would be reluctant to do this, among other things because I don’t want to waste a physical CD for that. However, the Ubuntu upgrade instructions say how to mount the ISO (yes, mounting ISOs is not new. I’ve done it in the past), then upgrade from the mounted image. Once the upgrade is done, I can keep seeding the ISO with BitTorrent.

With this procedure I can use bandwidth more efficiently (I download the required software just once), and I can still share the ISO with other people. Moreover, there is another plus: the ISO is just 699 MB, whereas the upgrade manager in Ubuntu tells me that for the upgrade I will need to download more than 1 GB! The difference is due to the ISO being somehow compressed, I think. I will report on the size of the file system mounted from the ISO (which should be much more than 1 GB).

Update: Well, actually the internet upgrade involves more packages. If you upgrade from the CD, you are still required to download 800 more MB to complete the upgrade, so no magic there.


La jungla de internet móvil: simyo contra Movistar, Vodafone y Orange

Ya comenté en un post anterior los pros y contras que encontraba para contratar Orange o simyo como proveedor de internet móvil. Finalmente escogí simyo, con quien no tengo en principio queja, excepto que en general es más lento e irregular de lo que esperaba (pero temo que sea un problema inherente al uso de red de telefonía móvil).

Con el tiempo he ido viendo cada vez más anuncios de internet móvil, por la calle y en televisión. Obviamente los que más machacan con el tema son los ladrones de Movistar, como con todo con lo que creen que pueden sacar tajada engañando proveyendo de un servicio a la gente.

Lo que me indigna es lo absolutamente vergonzosas que son las ofertas de los principales operadores (Movistar, Vodafone y Orange), respecto a otras como la de simyo. Por ello, voy a hacer una mínima comparativa, y que el lector saque conclusiones.


Se ha comparado un producto de cada empresa, teniendo como características una tarifa plana hasta cierto volúmen de datos mensual. Tras ese gasto la velocidad ofrecida baja en todos los casos, pero no se cobra más por ese volúmen extra. Los precios son con IVA.


Compañía Ancho de banda Precio Límite datos Velocidad tras límite Permanencia
simyo 3.2 Mbps 28.99 € 5 GB 128 kbps 0
Movistar 3 Mbps 45.24 € 1 GB 128 kbps 18 meses
Vodafone 3 Mbps 45.24 € 1 GB 128 kbps ns/nc
Orange 3.6 Mbps 45.24 € 5 GB 128 kbps 18 meses

Notas adicionales

  • El módem USB de simyo es libre. Los demás son cada uno exclusivo de su compañía.
  • Vodafone excluye expresamente el tráfico [[peer-to-peer|p2p]] ([[file sharing|compartición de ficheros]]). Simyo lo permite expresamente, diciendo que pudiera ralentizarse en caso de congestión de red.


¿Hace falta añadir algo?

Comments (8)

Installation of simyo Huawei E220 under MacOSX

I recently subscribed to [[simyo]]’s mobile internet service. I was considering also [[Orange (brand)|Orange]], as explained in a previous post (es), but simyo’s offer is better.

I am writing how to make the modem simyo provides (the commonplace [[Huawei E220]]) on MacOSX first, because apparently the [[Personal identification number|PIN]] has to be deactivated for the modem to work in Linux. I have to admit that in MacOSX installation was a breeze.

Software installation

Start MacOS, then plug the USB modem. A window will open automatically, with two objects inside: “MobileConnect” and “User Manual”. The former is the installer binary, and the latter is a folder with the manuals in PDF format (for me, they were in English and Spanish).

Clicking on the “MobileConnect” icon the installer will start, and after being asked to accept an [[Software license agreement|EULA]], then introduce the admin password, then choosing a location for placing the files (actually just a hard disk, not a concrete dir), the installer does its thing.

Profile setting

After that, we only need to configure a connection in the “Mobile Connect” window that opens automatically after installation. For that, click on “Setting…” and create a new profile. If you read the manual (see above), it is easy to fill in the blanks. In short:

  • Profile name: whatever you want
  • Access Point Name: this is the APN value that simyo tells you in some paper (
  • Telephone number: *99#
  • Account name: irrelevant
  • Password: irrelevant

Save the above, then choose the profile you just created in the drop-down list in “Profile name”, then hit the “Connect” button. If after saying “Dialing up, please wait”, it tells you “Connection succesfull!”, then everything is fine!

PIN deactivation

Apparently using the modem under Linux requires that the PIN is deactivated. Doing that under MacOSX is easy: when the “Mobile Connect” window is active, go to the “Manage PIN” drop-down menu in the top bar. There you can find “Activate”, “Deactivate” and “Modify”. Self-explanatory, ain’t it?

Comments (5)

DreamHost makes me happy again: free backups

Perhaps you are aware of my first (and last so far) gripe with [[DreamHost]]: as I wrote a couple of months ago, they wouldn’t let me use my account space for non-web content.

Well, it seems that they really work to make their users happy, and probably other people requested something like that, and read what the August DH newsletter says about it:

In keeping with my no-theme theme, uh oh, I think I just made a destroy-the-universe-LHC-style self-contradiction, here’s a new feature that pretty much has nothing to do with anything I said in the introduction!

Now, you know how we give out a LOT of disk space with our hosting? Well technically that space is only supposed to be used for your _actual_ web site (and email / database stuff) .. not as an online backup for your music, pictures, videos, other servers, etc!

Well, just like every other web host does, we’ve been sort of cracking down on that some lately, and it seems to catch some people by surprise! Nobody likes being surprised, especially in the shower, which is where we typically brought it up, and so now we offer a solution:

You CAN use 50GB of your disk space for backups now! The only caveat is, it’s a separate ftp (or sftp) user on a separate server and it can’t serve any web pages. There are also NO BACKUPS kept of THESE backups (they should already BE your backups, not your only copy), and if you go over 50GB, extra space is only 10 cents a GB a month (a.k.a. cheap)!

Thanks, DreamHost, for showing me that I made a good choice when I chose you!
Update: apparently only [[SSH file transfer protocol|SFTP]] works (or [[File Transfer Protocol|FTP]] if you are idiot enough to enable it), but not scp or any [[Secure Shell|SSH]]-related thing (rsync, …). I hope I find some workaround, because if not that would be a showstopper for me.

Comments (2)

Orange contra simyo

Estoy en proceso de selección de una compañía que me dé acceso a internet móvil. Es decir, poder conectarme a internet a través de la red de telefonía móvil, usando para ello una tarjeta SIM como la de los móviles, y un módem habilitado para usarla.

He seguido (de lejos) la evolución de los precios y servicios ofertados por las compañías de telecomunicaciones españolas, y la verdad es que no podían calificarse más que de estafa, o quizá “robo” es una palabra mejor. Sin embargo creo que ahora mismo es el momento en que los precios empiezan a ser competitivos (aunque no los de todas las compañias). Movistar y Vodafone parecen ofrecer basuras de calibre considerable, pero hay dos productos que me han llamado la atención: Internet Everywhere de Orange, y Tu propio internet móvil de simyo.

Ambas compañías ofrecen un servicio similar, que se puede resumir en:

  • Tarifa plana
  • Velocidad 3.6 Mbps hasta 5 GB mensuales
  • Tras consumir 5 GB se puede seguir navegando a 128 kbps sin coste adicional
  • Módem USB Huawei E220, que he leído que está soportado bien por Linux

La diferencia entre ambas es básicamente el precio (siendo simyo bastante más barata). A continuación resumo puntos a favor y en contra para ambas, y animo al amable lector a que me dé su opinión sobre el tema, si a bien tuviera.



  • Tiene tiendas físicas donde acudir
  • Regala el módem


  • El precio es más caro (39 eur/mes + IVA).
  • Exige compromiso de permanencia de 18 meses
  • Siendo una de las tres compañías que forman el oligopolio de las operadoras móviles en España (con Vomistar y Robafone), contratarla supone apuntalar su dominio (y poder para abusar del cliente), y ahogar a la competencia minoritaria



  • Mucho más barato: 24.99 eur/mes + IVA).
  • El módem es libre (el de Orange creo que no).
  • Me gusta más su política de funcionamiento, la idea de “no frills”, y lo que conlleva.
  • Aunque respaldada por KPN, simyo es una compañía minoritaria en España. Por ello, contratar sus servicios activa una sana competencia en el mercado.


  • Sólo puede accederse a la compañía por internet.
  • El módem hay que comprarlo, por 99 eur + IVA.

Todo lo anterior podría resumirse simplistamente en que Orange te regala los 99 euros del módem, mientras que simyo te cobra 14 euros menos al mes. Si esto fuera cierto, en 7 meses uno habría amortizado el módem en simyo (y tengamos en cuenta que Orange pide 18 meses de permanencia, y simyo 0). En los 18 meses de permanencia de Orange uno habrá gastado 18×39 = 702 eur (más IVA), mientras que en simyo habrían sido 99+18×25 = 549 eur (más IVA). Esto supone un ahorro de 150 euros en año y medio.

Comments (2)

X forwarding through SSH

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 ""-like lines.


Blackout summary VII

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


Blackout summary VI

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


Remote graphical applications with NX

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.


« Previous entries Next Page » Next Page »