Starting a GNU Screen session via SSH’s ~/.ssh/config //at 05:50 //by abe

This is more or less a followup to this blog posting of mine about AutoSSH and GNU Screen from nearly ten years ago — which by the way is still valid and still the way, I use SSH and GNU Screen.

Recently a friend asked me how to automatically start or reconnect to a GNU Screen session directly via OpenSSH’s configuration file. Here’s how to do it:

Add an entry to ~/.ssh/config similar to this one:

Host screen_on_server
    Hostname server.example.org
    RequestTTY yes
    RemoteCommand screen -RD

and then just call ssh screen_on_server and you’ll get connected to an existing screen session if present, otherwise you’ll a new new one.

Should work with tmux, too, but might need commandline different options.

Cool new feature in OpenSSH 5.7: scp between two remote hosts //at 02:55 //by abe

Just a few days after OpenSSH 5.7 was released upstream, our (Debian’s as well as Ubuntu’s) tireless OpenSSH and GRUB maintainer Colin Watson uploaded a first package of OpenSSH 5.7 to Ubuntu Natty and to Debian Experimental.

Besides the obvious new thing, the implementation of Elliptic Curve Cryptography which promises better speed and shorter keys while staying at the same level of security, one other item of his changelog entry stuck out and caught my attention:

• scp(1): Add a new -3 option to scp: Copies between two remote hosts are transferred through the local host.

That’s something I always wondered why it didn’t “just work”. While it still doesn’t seem to detect such a situation by default, it’s now at least possible to copy stuff from on remote box to another without ugly port forwarding and tunneling hacks.

Further cool stuff in the changelog:

• sftp(1)/sftp-server(8): add a protocol extension to support a hard link operation. It is available through the “ln” command in the client. The old “ln” behaviour of creating a symlink is available using its “-s” option or through the preexisting “symlink” command.

Colin++

Perfect Team: autossh and GNU Screen //at 01:06 //by abe

SSH is definitely one of my most often used tools, not only for system administration at work but also on the road with my netbook, an EeePC 701 running Debian Sid.

On the road, it often happens that I have a flaky WLAN or UMTS connection, so I often have to kill (via <Enter>~.) and reconnect my SSH session due to a changed IP address or so.

First step against problems arising from using SSH over unreliable network connections is of course GNU Screen. Second step is use SSH keys and ssh-agent to not needing to type the password on every reconnect.

But it’s still very annoying to kill the SSH connection and call ssh again manually. For luck there is autossh, a wrapper around SSH which regularily checks via two tunnels connect to each other on the remote side if the connection is still alive, and if not, it kills the ssh and starts a new one with the same parameters (i.e. tunnels, port forwardings, commands to call, etc.).

It’s quite obvious that this is perfect to be combined with screen’s -R and -d options (Reattach if a detached screen is around, else start a new screen; detach a currently attached screen), so I found myself very often typing (or fetching it from the commandline history :-):

autossh -t sym.noone.org 'screen -Rd'

-t is necessary to allocate a terminal device on the remote machine which is not done by default if you directly call a command via ssh.

In comparision to OpenSSH, autossh needs the single quotes, because otherwise it would parse -Rd as options to parse to ssh and bail out. That’s not a real problem, but when you’re used to just type ssh -t sym.noone.org screen -Rd without any quotes, you’ll run into this then and when.

Update, 25-May-2010, 14:55: As Carsten Hey points out, autossh also supports the -- option to declare that all following options and parameters must be passed to ssh itself. (End of Update)

Typing that often and mistyping it then and when cries for an shell alias or an shell function. So I came up with the following shell function:

asc() {
    autossh -x -a -t "$@" 'screen -RdU'
}

I used a function instead of an alias in case of autossh will in future regard all parameters given after the command as part of the command as ssh does.

The additional options -x and -a disable X and SSH Agent forwarding which both don’t work if you reattach to an already running screen.

And if you’re using Zsh as I do, you can even add some more format string magic to set the window title more or less to the expanded alias, eh, function:

function asc() {
    # Set the title to something more obvious, e.g. the expanded
    # alias, eh, function
    print -Pn "\e]0;%n@%m: autossh -t $* 'screen -RdU'\a";
    autossh -x -a -t "$@" 'screen -RdU'
}
compdef asc=ssh

Update, 25-May-2010, 14:59: As Hauke points out in a comment, Zsh users should also declare that asc should have the same tab completion as ssh itself. The example above has been updated accordingly. (End of Update)

In the meantime on the EeePC I use asc on the commandline more often than ssh itself. And I nearly no more type autossh. (The most common exception here is autossh hostname tail -F /path/to/some/logfile.)

Using that function you can also add common ssh options for tunneling, etc. — I use it most often like this:

asc -D 1080 sym.noone.org

This opens a SOCKS proxy on localhost, port 1080 and that way I can surf via the host I’m connecting to by SSH.

There’s one small drawback though: You didn’t expect that I can just invent some new three letter command without a namespace clash, did you? There is a free game called Advanced Strategic Command whose binary (and Debian package) is named asc, too. If you have that game installed, you can always call it using its full path, e.g. /usr/games/asc on Debian.

P.S.: My whole grml based .zshrc is also available via git at git.noone.org as well as on github.

Fedora Legacy useless? //at 15:16 //by abe

For a (much too long) time, we ran our three AMD 64 bit virus scanners and spam filter boxes with Fedora Core 4. Since the the official support ended a few months ago when Fedora Core 6 Test 2 came out, so we decided to switch them over to support through the Fedora Legacy Project.

For testing purposes we first switched over one of the three boxes. But the test failed: Although the changes (as documented on the Fedora Legacy home page) seemed to work fine, not a single update came until the end of last week, even though there were partially remotely exploitable security issues in OpenSSL, OpenSSH, gzip, etc. during that time. There were also no announcements on the list since FC4 switched over to the Fedora Legacy Project, not for FC4 nor for any other distribution maintained by the Fedora Legacy Project.

So what the heck does the Fedora Legacy Project if not security updates?

I would be very happy if I could switch over those boxes to Debian or even Ubuntu, but there’s no BiArch support (running 32 bit applications on 64 bit operating systems transparently) in Debian (and therefore neither in Ubuntu) yet without a lot of manual fiddling and chroots, so we can’t run our 32 bit virus scanners on those 64 bit boxes with a debianesk operating system yet.

Today we’ve upgraded the last of those three boxes to Fedora Core 5.

Mailing lists made my day //at 13:58 //by abe

Today actually two mailing lists made my day:

First Theo de Raadt’s mail to the FreeBSD security mailing list:

Date:       Mon, 02 Oct 2006 14:00:11 -0600
From:       Theo de Raadt <deraadt@cvs.openbsd.org>
To:         freebsd-security@freebsd.org
Subject:    Re: FreeBSD Security Advisory FreeBSD-SA-06:22.openssh 
Message-ID: <200610022000.k92K0B5P009759@cvs.openbsd.org>

> The OpenSSH project believe that the race condition can lead to a Denial
> of Service or potentially remote code execution
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Bullshit.  Where did anyone say this?

Why don't you put people in charge who can READ CODE, and SEE THAT
THIS IS ABSOLUTE BULLSHIT.

and Colin Percival’s dry reply pointing out who made the “ABSOLUTE BULLSHIT”:

Date:       Mon, 02 Oct 2006 14:25:05 -0700
From:       Colin Percival <cperciva@freebsd.org>
To:         Theo de Raadt <deraadt@cvs.openbsd.org>
Cc:         freebsd-security@freebsd.org
Subject:    Re: FreeBSD Security Advisory FreeBSD-SA-06:22.openssh
Message-ID: <452183B1.7000306@freebsd.org>

Theo de Raadt wrote:
>> The OpenSSH project believe that the race condition can lead to a Denial
>> of Service or potentially remote code execution
>                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Bullshit.  Where did anyone say this?

The OpenSSH 4.4 release announcement says that, actually:

 * Fix an unsafe signal hander reported by Mark Dowd. The signal
   handler was vulnerable to a race condition that could be exploited
   to perform a pre-authentication denial of service. On portable
   OpenSSH, this vulnerability could theoretically lead to
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   pre-authentication remote code execution if GSSAPI authentication
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   is enabled, but the likelihood of successful exploitation appears
   remote.

Colin Percival

Well, looks like an exquisite own goal. (Found by Squeeeez.)

Then, _rene_ cited a mail from the current Debian Project Leader Anthony Towns on debian-devel in #debian.de, who thought that »Switzerland was some foreign word meaning “snowy place”«:

Date:       Tue, 3 Oct 2006 15:52:38 +1000
Subject:    Re: Bits from the DPL: Looking forward
From:	    Anthony Towns <aj@azure.humbug.org.au>
Message-ID: <20061003055238.GA4841@azure.humbug.org.au>

On Tue, Oct 03, 2006 at 03:39:20PM +1000, Anthony Towns wrote:
> BSPs in Vienna (Switzerland) [3], 

I was assuming, of course, that "Switzerland" was some foreign word
meaning "snowy place", but apparently it's actually a country all of
its own, entirely separate to Austria...

On Tue, Oct 03, 2006 at 03:43:52PM +1000, Anthony Towns wrote:
> (b) Firmware vote
> proposal, as amended by Manon Srivastava (Message-id:

And while _Manon des sources_ might've been a neat French film, I don't
think it's actually got all that much to do with Manoj...

Cheers,
aj

And contrary to the usual biases, this geographic unawareness comes from Australia (which is unequal to Austria ;-) and not from the US. :-)

Guys, you all made my day. Kind regards from a currently not so snowy snowy place. :-)