OpenBSD Journal

Darren Tucker: t2k13 report - ssh improvements

Contributed by pitrh on from the ssh! quietly awesome dept.

The fourth developer to contribute to our Toronto 2013 hackathon series was Darren Tucker (dtucker@), who works mainly on OpenSSH:

None of the other folks who work on ssh could make it to t2k13, so it wasn't a good time for large changes. Instead, I spent time investigating some bug reports, small patches and pulling the recent changes from OpenBSD into Portable OpenSSH. This included:

* a switch of ssh, sshd and ssh-agent to use clock_gettime(2) with CLOCK_MONOTONIC for timers such as ServerAliveInterval, ClientAliveInterval and the recently added time based rekeying in RekeyLimit as suggested by markus@.

This means that they'll still work correctly over clock steps. I also added a fallback to use time(3) in the Portable for platforms that don't have it so they'll still work as well as they did previously.

* a crash in sftp when tab-completing filenames with multibyte characters. The crash turned out to be a known and fixed bug in libedit when it's built with wide character support. With that fixed, sftp merely failed rather than crashed because it attempted to build up a quoted string byte by byte rather than character by character. Using mlben(3) allowed it to work. (bz#1990)

* a problem reported by tedu whereby ControlMaster processes with ControlPersist don't exit after being closed via the ~. escape sequence on bad networks, preventing a new one from starting (turns out this is also bz#1917). This turned out to be much more involved than I initially thought and took quite a while to figure out. Here's the description I sent with the patch:

In addition to deleting things, tedu is also good at breaking ssh
muxing.  In today's edition, it's disconnecting via escape sequences on
broken networks.

When your network changes or goes away and you disconnection with ~.
ssh sends a channel close.  normally this isn't a problem because the
ssh goes away immediately thereafter.  when you do it in a mux client,
the mux client goes away but the mux master stays up.  normally that's
not a problem either, because the mux master is similarly wedged and
can be ~.'ed too.  that is, unless you also use controlpersist, which
naturally tedu does.

when all of these things happen together the ssh mux master, which is
backgrounded, hangs around waiting for the channel close confirmation
from the server, which isn't going to happen because, hey, the network is
busted.  that wouldn't be a problem either except that the backgrounded
mux master won't exit until all its channels are closed, and until it
exits the controlmaster socket remains there preventing you from making
a new one.  the net result is that you can't make any new connections
until you find and kill the backgrounded mux master.

you can't just free the channel on ~. because in the case where the
network is not broken you'll get a channel close from the server for a
non-existant channel and the mux master will fatal.

what this patch does is add a new "ABANDONED" state, which is basically the
same as CLOSED or INPUT_DRAINING except it's not counted as an active channel.
the ~. sequence then sends a close on the channel and puts it into this
state.  if the server confirmation comes back the channel is freed as
per normal, but if not it's just kept around but not used.

* some patches from Nathan Osman to support building OpenSSH on Android platforms. (bz#2085 bz#2111 bz#2112 bz#2114)

* some memory leaks reported by Zhenbo Xu which were found with a leak detection tool called Melton. (bz#1967 bz#1969)

plus some other minor fixes. The full list available in the OpenSSH Portable ChangeLog.

(Comments are closed)


Comments
  1. By Anonymous Coward (174.126.247.29) on

    Would it make sense for OpenSSH to be aware of it's location in terms of a DNSSEC cert? the option would be to affirm ones network location before issuing traffic under a particular config.

    or is this better accomplished in PF?

    Comments
    1. By Darren Tucker (dtucker) on

      > Would it make sense for OpenSSH to be aware of it's location in terms of a DNSSEC cert? the option would be to affirm ones network location before issuing traffic under a particular config.

      Sorry, I don't think I follow what you're after here. Could you give me an example?

  2. By Donovan Watteau (88.160.127.178) on http://www.donovan-watteau.fr

    Hi,

    I think you want to mention mblen(3), not mlben(3).
    Very nice article, as usual.

    Cheers.

    Comments
    1. By Darren Tucker (dtucker) on


      > I think you want to mention mblen(3), not mlben(3).

      Indeed (the man page link points to the right place).

      > Very nice article, as usual.

      Thanks!

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]