Re: [Curdle] Client-side SSH_MSG_EXT_INFO: Use it or lose it principle!

Ron Frederick <> Sun, 26 April 2020 17:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 779603A0AE6 for <>; Sun, 26 Apr 2020 10:34:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3VZeAaOmnc04 for <>; Sun, 26 Apr 2020 10:33:59 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::1033]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 370603A0AE4 for <>; Sun, 26 Apr 2020 10:33:59 -0700 (PDT)
Received: by with SMTP id fu13so5723501pjb.5 for <>; Sun, 26 Apr 2020 10:33:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=mail; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=2Ohs05WwCVNYnsiYcN/mU+OJq+MHLEM3WQ0vae+vb84=; b=VKmKxHpV8PYfD0iwO6zqTRCBdqTl0AtXAMrJd/u0G6IB5cZjXeUvxhT876qiDcUsz5 NcuOvTbObmnTM7Sc5cYXDF43DI9rildngjiDTLXzqgDAabetfsyjf8EwYJkvQRiolili EdhZUBp1JyYDAHsmM5zW91STB2XKqxmsW2vVw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=2Ohs05WwCVNYnsiYcN/mU+OJq+MHLEM3WQ0vae+vb84=; b=K/+rllx/3QQ/Getvmpm3DhrBuyp/toRAQGdKEXk01g2zItIyC1d87J1YUBptxzWOXS q5QvGmHnQrW/etCOYM/Tr0UVAJK43iUSzqthdNKGy9+gOJ6Rs72oiAB1S+thscgHu2bD cRKlNxSVhXRKHklNIAj0Ra6OWGSWc6GqAyPfXoFynmMmMhBlHMCSf+2wcV0MsarJvdPU 1nhVGzTTJ0YFSNlEm4e2if8mkzXKDzWGxFOsq4y+EJcZmU3IP99RM4lpxj/MThiS2w/y gCEpgn4MmXNyvemmSfMdP+/ghkilUb8BVoie9SPtBxwfP5PNMUyMthO0ddMiOBXVJ1wz zX+w==
X-Gm-Message-State: AGi0PubZ/Pq2ptJ6tlIqkNzCAj590TH2ynD7vhemUSfdOlPRGV2cFRds Z/prJPH3vnrEb0mKw///An3jNw==
X-Google-Smtp-Source: APiQypKzf/2EEVK2o6yppfs15CgYvsdNR0Mh/lbfGLX8BYtRCk4PuytAVYFX5CQ3W1Jfi+ESDQrD6w==
X-Received: by 2002:a17:902:b78b:: with SMTP id e11mr19161271pls.311.1587922438294; Sun, 26 Apr 2020 10:33:58 -0700 (PDT)
Received: from ([2603:3024:18fa:4000::2]) by with ESMTPSA id c59sm9799197pje.10.2020. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 26 Apr 2020 10:33:57 -0700 (PDT)
From: Ron Frederick <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_B51794CF-B5F1-47CF-BDA8-2092A3C6CA71"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Sun, 26 Apr 2020 10:33:56 -0700
In-Reply-To: <>
Cc: curdle <>,, Damien Miller <>
To: denis bider <>
References: <>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <>
Subject: Re: [Curdle] Client-side SSH_MSG_EXT_INFO: Use it or lose it principle!
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "List for discussion of potential new security area wg." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 26 Apr 2020 17:34:03 -0000

Hi Denis,

On Apr 26, 2020, at 5:03 AM, denis bider <> wrote:
> it has come to my attention that at least one SSH server implementation (a) advertises support for SSH_MSG_EXT_INFO as defined in RFC 8308, and (b) disconnects on actual receipt of an EXT_INFO message from the client.
> This happens when we define a general mechanism, but then the most widely used implementations only use certain aspects of it. Lots of implementations now support EXT_INFO sent by the server because it's needed for RSA-SHA2 signatures, but only a handful implementations send EXT_INFO by the client.
> Bitvise SSH Client sends EXT_INFO if the server supports it. It's free to use or test with - but it runs on Windows and lots of people don't want to test with that.
> It's possible that your implementation has no need for any of the extensions that would appear in EXT_INFO from the client. However, if you wish for this extensibility to be available in the future, then if your client supports EXT_INFO, I would strongly suggest that it sends it.
> If you want to send a client-side EXT_INFO that takes minimal effort, I suggest:
> 1. Ensure that your SSH client can correctly handle SSH_MSG_GLOBAL_REQUEST received at any point. Your client should not disconnect when it receives this message, or act like it received a channel open failure if it receives a global request when it's waiting for a channel open confirmation. These are the two most common error modes relating to global requests.
> 2. Once you have ensured the above, if the server supports EXT_INFO, send a client-side EXT_INFO implementing the extension "global-requests-ok" as defined in this draft:
> <>
> This tells the server that your client properly implements global requests so that the server can use them for things like active keep-alives.
> Implementing this would take minimal effort and would help ensure that client-side EXT_INFO remains an available extension mechanism 10 years down the road for SSH.

I’ve made this change in the AsyncSSH “develop” branch as commit <>, and will roll this into the next release. Most of the support was already in place as I already had common code for generating and parsing EXT_INFO on both the client and server. The changes are as follows:

    - AsyncSSH now advertises that it will accept EXT_INFO from clients when acting as a server

    - AsyncSSH will send the global-requests-ok extension when acting as a client and talking to a server that supports EXT_INFO from clients

Since AsyncSSH doesn’t actually have any heuristics around disabling the use of global requests based on client software/version, it doesn’t actually do anything right now when it receives the ‘global-requests-ok’ extension. However, I confirmed it successfully parses received extensions, so it should be easy to process future extensions from the client when this is needed.

I also specifically tested this against the Bitvise server (thanks for making that available for free for non-commercial use!), and it seems to work well.
Ron Frederick