From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sun Sep 2 16:33:59 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA13607 for ; Sun, 2 Sep 2001 16:33:59 -0400 (EDT) Received: (qmail 10758 invoked by uid 605); 2 Sep 2001 20:30:14 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 10751 invoked from network); 2 Sep 2001 20:30:13 -0000 Received: from carnelian.propagation.net (209.164.120.1) by mail.netbsd.org with SMTP; 2 Sep 2001 20:30:13 -0000 Received: from fiddle (localhost [127.0.0.1]) by carnelian.propagation.net (8.8.5/8.8.5) with SMTP id PAA28063 for ; Sun, 2 Sep 2001 15:37:24 -0500 From: "Howard Chu" To: Subject: cooked mode sessions Date: Sun, 2 Sep 2001 13:36:49 -0700 Message-ID: <001301c133ee$fdc28020$0c01a8c0@fiddle.symas.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Importance: Normal Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit I saw a brief mention of this in the August mail archive, but apparently the idea was discarded: I'd like to see support for client-side input processing, to eliminate the single-character echoing roundtrips that interactive sessions currently have. This should be similar to the Telnet LINEMODE option. For the majority of terminal sessions operating a command-line, there's no reason the client can't do all the input editing and just send complete lines to the server. This kind of feature will improve performance on slow links, and can also lessen the effectiveness of traffic- analysis attacks on a session by eliminating keystroke-timing information. I also saw a Bubble Babble document in the archive, for encoding binary strings as English-readable strings. This kind of feature was present in the S/Key one-time-password system, and also proved to be a vulnerability. If the characters are typed one at a time, the language space is so limited that an eavesdropper can guess the remainder of the password before the user finishes typing it in. The session can then be hijacked without needing the user to complete a login. These vulnerabilities existed with an S/Key login over a cleartext session, so the situation is different in ssh. However, it's still important to be aware of potential dangers. Even though the initial ssh password can be sent in a single packet, no such protection exists for any chained sessions. (E.g., user starts ssh session to machine 1. On machine 1, user starts ssh session to machine 2. If the user must type a password for machine 2, it will be transmitted one character at a time through the machine 1 session.) Adding support for client-side input editing is a win, for both performance and security reasons. -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sun Sep 2 20:58:57 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA15464 for ; Sun, 2 Sep 2001 20:58:57 -0400 (EDT) Received: (qmail 13591 invoked by uid 605); 3 Sep 2001 00:55:13 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 13584 invoked from network); 3 Sep 2001 00:55:12 -0000 Received: from fw.hel.fi.ssh.com (193.64.193.124) by mail.netbsd.org with SMTP; 3 Sep 2001 00:55:12 -0000 Received: from viikuna.hel.fi.ssh.com (viikuna.hel.fi.ssh.com [10.1.0.46]) by fw.hel.fi.ssh.com (SSH-1.27) with SMTP id f8310Ff20957 for ; Mon, 3 Sep 2001 04:00:15 +0300 (EEST) Received: (qmail 21478 invoked from network); 3 Sep 2001 01:00:14 -0000 Received: from unknown (HELO johto.hel.fi.ssh.com) ([10.1.0.48]) (envelope-sender ) by viikuna.hel.fi.ssh.com (qmail-ldap-1.03) with SMTP for ; 3 Sep 2001 01:00:14 -0000 Received: (from sjl@localhost) by johto.hel.fi.ssh.com (8.9.3/8.9.3) id EAA04649; Mon, 3 Sep 2001 04:00:53 +0300 To: Subject: Re: cooked mode sessions References: <001301c133ee$fdc28020$0c01a8c0@fiddle.symas.com> From: sjl@ssh.com (Sami J. Lehtinen) Date: 03 Sep 2001 04:00:53 +0300 In-Reply-To: hyc@highlandsun.com's message of "Sun, 2 Sep 2001 20:35:27 +0000 (UTC)" Message-ID: Lines: 35 X-Mailer: Gnus v5.6.45/XEmacs 21.1 - "Canyonlands" Sender: ietf-ssh-owner@netbsd.org Precedence: list hyc@highlandsun.com ("Howard Chu") writes: > I'd like to see support for client-side input processing, to > eliminate > the single-character echoing roundtrips that interactive sessions currently > have. > This should be similar to the Telnet LINEMODE option. For the majority of > terminal > sessions operating a command-line, there's no reason the client can't do all > the > input editing and just send complete lines to the server. This kind of > feature will > improve performance on slow links, and can also lessen the effectiveness of > traffic- > analysis attacks on a session by eliminating keystroke-timing information. Why can't this be done with the current protocol spec? > I also saw a Bubble Babble document in the archive, for encoding binary > strings as > English-readable strings. This kind of feature was present in the S/Key > one-time-password system, and also proved to be a vulnerability. If the > characters are typed > one at a time, the language space is so limited that an eavesdropper can > guess the > remainder of the password before the user finishes typing it in. Bubble Babble is intended (and currently only used) as an encoding style for fingerprints. So the situation you describe does not apply. Cheers, -- [sjl@ssh.com -- Sami J. Lehtinen -- sjl@iki.fi] [work:+358 20 5007425][gsm:+358 40 864 3001][http://www.iki.fi/~sjl] [SSH Communications Security Corp http://www.ssh.com/] From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sun Sep 2 21:18:54 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA15565 for ; Sun, 2 Sep 2001 21:18:54 -0400 (EDT) Received: (qmail 16078 invoked by uid 605); 3 Sep 2001 01:15:10 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 16071 invoked from network); 3 Sep 2001 01:15:09 -0000 Received: from fw.hel.fi.ssh.com (193.64.193.124) by mail.netbsd.org with SMTP; 3 Sep 2001 01:15:09 -0000 Received: from viikuna.hel.fi.ssh.com (viikuna.hel.fi.ssh.com [10.1.0.46]) by fw.hel.fi.ssh.com (SSH-1.27) with SMTP id f831KCf21088 for ; Mon, 3 Sep 2001 04:20:12 +0300 (EEST) Received: (qmail 23380 invoked from network); 3 Sep 2001 01:20:12 -0000 Received: from unknown (HELO johto.hel.fi.ssh.com) ([10.1.0.48]) (envelope-sender ) by viikuna.hel.fi.ssh.com (qmail-ldap-1.03) with SMTP for ; 3 Sep 2001 01:20:12 -0000 Received: (from sjl@localhost) by johto.hel.fi.ssh.com (8.9.3/8.9.3) id EAA04744; Mon, 3 Sep 2001 04:20:51 +0300 To: SECSH Discussion List Subject: Re: setting environment variables References: <200105101529.LAA08227@syrinx.oankali.net> From: sjl@ssh.com (Sami J. Lehtinen) Date: 03 Sep 2001 04:20:51 +0300 In-Reply-To: slade@shore.net's message of "Thu, 10 May 2001 15:29:31 +0000 (UTC)" Message-ID: Lines: 43 X-Mailer: Gnus v5.6.45/XEmacs 21.1 - "Canyonlands" Sender: ietf-ssh-owner@netbsd.org Precedence: list slade@shore.net ("Richard E. Silverman") writes: > Some questions regarding setting environment variables via SSH ("Connection" > draft, section 4.4). > > "Environment variables may be passed to the shell/command to be started > later." > > This mentions "shell" and "exec" channel requests, but not "subsystem." Is > this deliberate? Do we want to prevent the client from setting environment > variables for subsystem execution? I'm not disagreeing, necessarily -- I can > see an argument from the abstraction and security point of view, as well as > the fact that a subsystem might be implemented as an internal process for > which setting environment variables does not make sense. However, if this is > the intention, I think it should be made explicit. (Of course, the SSH could > be running on an OS which does not have anything like environment variables, > so that it wouldn't make sense for program execution either...) In at least our implementation you can set environment variables during subsystem execution. I agree the wording should be implicit, whatever we decide. > Also, the use of the phrase "the shell/command to be started later" is > misleading, as it implies that only one such will be started. The connection > protocol may start multiple remote shells and/or programs. I assume then that > the use of the "env" channel request builds up an environment-variable state > on the server, which is used for every program execution? If that's so, we > need a way to unset environment variables as well. It is not sufficient to > just set an old variable to the null string, since there is a program-visible > difference between a variable being unset, and being set to the zero-length > string. If you look at the spec, the environment variables are channel specific. And you can only run one command/subsystem/shell per channel. So I'd say we don't need an "unset" message, as typically you can't unset environment variables of a running process outside of the process. Cheers, -- [sjl@ssh.com -- Sami J. Lehtinen -- sjl@iki.fi] [work:+358 20 5007425][gsm:+358 40 864 3001][http://www.iki.fi/~sjl] [SSH Communications Security Corp http://www.ssh.com/] From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sun Sep 2 23:29:11 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA18801 for ; Sun, 2 Sep 2001 23:29:10 -0400 (EDT) Received: (qmail 29418 invoked by uid 605); 3 Sep 2001 03:25:25 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 29411 invoked from network); 3 Sep 2001 03:25:24 -0000 Received: from carnelian.propagation.net (209.164.120.1) by mail.netbsd.org with SMTP; 3 Sep 2001 03:25:24 -0000 Received: from fiddle (localhost [127.0.0.1]) by carnelian.propagation.net (8.8.5/8.8.5) with SMTP id WAA17989 for ; Sun, 2 Sep 2001 22:32:26 -0500 From: "Howard Chu" To: Subject: RE: cooked mode sessions Date: Sun, 2 Sep 2001 20:31:59 -0700 Message-ID: <001601c13428$fd655fa0$0c01a8c0@fiddle.symas.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Importance: Normal Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit > -----Original Message----- > From: ietf-ssh-owner@netbsd.org [mailto:ietf-ssh-owner@netbsd.org]On > Behalf Of Sami J. Lehtinen > hyc@highlandsun.com ("Howard Chu") writes: > > > I'd like to see support for client-side input processing, to > > eliminate > > the single-character echoing roundtrips that interactive > sessions currently > > have. > > This should be similar to the Telnet LINEMODE option. For the > majority of > > terminal > > sessions operating a command-line, there's no reason the client > can't do all > > the > > input editing and just send complete lines to the server. This kind of > > feature will > > improve performance on slow links, and can also lessen the > effectiveness of > > traffic- > > analysis attacks on a session by eliminating keystroke-timing > information. > Why can't this be done with the current protocol spec? Some kind of message is needed to tell the client about pty mode changes. E.g., if the app issues an ioctl to turn echo off, a protocol message is needed to convey this state change. All of the terminal-mode settings that a client sends in its "pty-req" could potentially be sent from the server to the client at any time. There are many other instances where such a message is needed. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Sep 14 15:23:15 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA25002 for ; Fri, 14 Sep 2001 15:23:14 -0400 (EDT) Received: (qmail 20104 invoked by uid 605); 14 Sep 2001 19:22:39 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 20096 invoked from network); 14 Sep 2001 19:22:38 -0000 Received: from mx04.nexgo.de (151.189.8.80) by mail.netbsd.org with SMTP; 14 Sep 2001 19:22:38 -0000 Received: from localhost (unknown [145.254.236.185]) by mx04.nexgo.de (Postfix) with ESMTP id AEBA637B10 for ; Fri, 14 Sep 2001 21:22:34 +0200 (CEST) Received: by localhost (Postfix, from userid 31451) id 366D84A7E; Fri, 14 Sep 2001 21:22:11 +0200 (CEST) Date: Fri, 14 Sep 2001 21:22:11 +0200 From: Markus Friedl To: ietf-ssh@netbsd.org Subject: authentication and debug messages. Message-ID: <20010914212211.A10690@folly> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: ietf-ssh-owner@netbsd.org Precedence: list hi, are messages of type SSH_MSG_DEBUG allowed during authentication? can I replay to a SSH_MSG_USERAUTH_REQUEST message with SSH_MSG_DEBUG and SSH_MSG_USERAUTH_FAILURE? our server currenlty sends debug messages during public key authentication, some clients seem to consider this as protocol violations. i'm not sure how to interpret the drafts, they are not clear about when SSH_MSG_DEBUG messages are allowed. e.g. the userauth draft states: The server MUST respond with SSH_MSG_USERAUTH_SUCCESS (if no more authentications are needed), or SSH_MSG_USERAUTH_FAILURE (if the request failed, or more authentications are needed). so it seems SSH_MSG_DEBUG is not allowed at this point. should SSH_MSG_DEBUG be allowed? at least it would help debugging authentication problems.... -m From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Sep 14 16:25:18 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA25977 for ; Fri, 14 Sep 2001 16:25:18 -0400 (EDT) Received: (qmail 2551 invoked by uid 605); 14 Sep 2001 20:24:43 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 2544 invoked from network); 14 Sep 2001 20:24:42 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 14 Sep 2001 20:24:42 -0000 Received: from [127.0.0.1] (HELO merlin) by vandyke.com (CommuniGate Pro SMTP 3.4.4) with SMTP id 274190; Fri, 14 Sep 2001 14:25:40 -0600 Message-ID: <009901c13d5b$46a8f240$2800a8c0@test.vandyke.com> From: "Joseph Galbraith" To: "Markus Friedl" , References: <20010914212211.A10690@folly> Subject: Re: authentication and debug messages. Date: Fri, 14 Sep 2001 14:24:37 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit > are messages of type SSH_MSG_DEBUG allowed during authentication? > > can I replay to a SSH_MSG_USERAUTH_REQUEST message with SSH_MSG_DEBUG > and SSH_MSG_USERAUTH_FAILURE? > > our server currenlty sends debug messages during public key > authentication, some clients seem to consider this as protocol > violations. i'm not sure how to interpret the drafts, they are not > clear about when SSH_MSG_DEBUG messages are allowed. > > e.g. the userauth draft states: > > The server MUST respond with SSH_MSG_USERAUTH_SUCCESS (if > no more authentications are needed), or SSH_MSG_USERAUTH_FAILURE > (if the request failed, or more authentications are needed). > > so it seems SSH_MSG_DEBUG is not allowed at this point. > should SSH_MSG_DEBUG be allowed? at least it would help > debugging authentication problems.... Hmmm... I would think that higher protocol layers shouldn't be able to constrain lower protocol layers -- which would mean the DEBUG messages can be sent at any time which the transport draft allows them. Similarly, IGNORE messages, or even key exchange messages, should be allowed at anytime the transport draft allows them, regardless of what service is running, or what state it is in. In fact, for the most part, I think the service, such as userauth and connection, are supposed to be pretty ignorant of the transport -- if you think about it, the connection service really isn't tied to the ssh transport, and could run over another transport if someone wanted to. - Joseph Galbraith galb-list@vandyke.com From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sat Sep 15 04:53:43 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA18046 for ; Sat, 15 Sep 2001 04:53:43 -0400 (EDT) Received: (qmail 11105 invoked by uid 605); 15 Sep 2001 08:53:42 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 11098 invoked from network); 15 Sep 2001 08:53:42 -0000 Received: from mx04.nexgo.de (151.189.8.80) by mail.netbsd.org with SMTP; 15 Sep 2001 08:53:42 -0000 Received: from localhost (dialin-145-254-228-141.arcor-ip.net [145.254.228.141]) by mx04.nexgo.de (Postfix) with ESMTP id 4140437AFD; Sat, 15 Sep 2001 10:52:49 +0200 (CEST) Received: by localhost (Postfix, from userid 31451) id F0DC94885; Sat, 15 Sep 2001 10:51:59 +0200 (CEST) Date: Sat, 15 Sep 2001 10:51:59 +0200 From: Markus Friedl To: Joseph Galbraith Cc: ietf-ssh@netbsd.org Subject: Re: authentication and debug messages. Message-ID: <20010915105159.A28361@folly> References: <20010914212211.A10690@folly> <009901c13d5b$46a8f240$2800a8c0@test.vandyke.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <009901c13d5b$46a8f240$2800a8c0@test.vandyke.com>; from galb-list@vandyke.com on Fri, Sep 14, 2001 at 02:24:37PM -0600 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Fri, Sep 14, 2001 at 02:24:37PM -0600, Joseph Galbraith wrote: > > are messages of type SSH_MSG_DEBUG allowed during authentication? > > > > can I replay to a SSH_MSG_USERAUTH_REQUEST message with SSH_MSG_DEBUG > > and SSH_MSG_USERAUTH_FAILURE? > > > > our server currenlty sends debug messages during public key > > authentication, some clients seem to consider this as protocol > > violations. i'm not sure how to interpret the drafts, they are not > > clear about when SSH_MSG_DEBUG messages are allowed. > > > > e.g. the userauth draft states: > > > > The server MUST respond with SSH_MSG_USERAUTH_SUCCESS (if > > no more authentications are needed), or SSH_MSG_USERAUTH_FAILURE > > (if the request failed, or more authentications are needed). > > > > so it seems SSH_MSG_DEBUG is not allowed at this point. > > should SSH_MSG_DEBUG be allowed? at least it would help > > debugging authentication problems.... > > Hmmm... I would think that higher protocol layers shouldn't > be able to constrain lower protocol layers -- which would > mean the DEBUG messages can be sent at any time which > the transport draft allows them. yes, this is what i think, but it get reports that 3.0.x from ssh.com complains about protocol violations if i send SSH_MSG_DEBUG during authentication. -m From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sat Sep 15 06:59:20 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA18695 for ; Sat, 15 Sep 2001 06:59:20 -0400 (EDT) Received: (qmail 24568 invoked by uid 605); 15 Sep 2001 10:59:18 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 24561 invoked from network); 15 Sep 2001 10:59:17 -0000 Received: from noc.untraceable.net (166.84.189.65) by mail.netbsd.org with SMTP; 15 Sep 2001 10:59:17 -0000 Received: from noc.untraceable.net (localhost [127.0.0.1]) by noc.untraceable.net (8.12.0/8.12.0/bonk!) with ESMTP id f8FAxDPH009119; Sat, 15 Sep 2001 06:59:17 -0400 (EDT) Received: (from andrew@localhost) by noc.untraceable.net (8.12.0/8.12.0) id f8FAxDCN009118; Sat, 15 Sep 2001 06:59:13 -0400 (EDT) Date: Sat, 15 Sep 2001 06:59:12 -0400 From: Andrew Brown To: Markus Friedl Cc: Joseph Galbraith , ietf-ssh@netbsd.org Subject: Re: authentication and debug messages. Message-ID: <20010915065912.A9110@noc.untraceable.net> Reply-To: Andrew Brown References: <20010914212211.A10690@folly> <009901c13d5b$46a8f240$2800a8c0@test.vandyke.com> <20010915105159.A28361@folly> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010915105159.A28361@folly>; from markus@openbsd.org on Sat, Sep 15, 2001 at 10:51:59AM +0200 X-Hi-To-All-My-Friends-In-Domestic-Surveillance: hi there, sports fans :) Sender: ietf-ssh-owner@netbsd.org Precedence: list >yes, this is what i think, but it get reports that 3.0.x from >ssh.com complains about protocol violations if i send >SSH_MSG_DEBUG during authentication. off the top of my head, i'd expect that SSH_MSG_DEBUG messages should be allowed at any point. -- |-----< "CODE WARRIOR" >-----| codewarrior@daemon.org * "ah! i see you have the internet twofsonet@graffiti.com (Andrew Brown) that goes *ping*!" andrew@crossbar.com * "information is power -- share the wealth." From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sat Sep 15 09:52:52 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA20195 for ; Sat, 15 Sep 2001 09:52:52 -0400 (EDT) Received: (qmail 13813 invoked by uid 605); 15 Sep 2001 13:52:51 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 13806 invoked from network); 15 Sep 2001 13:52:50 -0000 Received: from fw.hel.fi.ssh.com (193.64.193.124) by mail.netbsd.org with SMTP; 15 Sep 2001 13:52:50 -0000 Received: from viikuna.hel.fi.ssh.com (viikuna.hel.fi.ssh.com [10.1.0.46]) by fw.hel.fi.ssh.com (SSH-1.27) with SMTP id f8FDqmf28350 for ; Sat, 15 Sep 2001 16:52:48 +0300 (EEST) Received: (qmail 15231 invoked from network); 15 Sep 2001 13:52:48 -0000 Received: from unknown (HELO johto.hel.fi.ssh.com) ([10.1.0.48]) (envelope-sender ) by viikuna.hel.fi.ssh.com (qmail-ldap-1.03) with SMTP for ; 15 Sep 2001 13:52:48 -0000 Received: (from sjl@localhost) by johto.hel.fi.ssh.com (8.9.3/8.9.3) id QAA28137; Sat, 15 Sep 2001 16:53:25 +0300 To: ietf-ssh@netbsd.org Subject: Re: authentication and debug messages. References: <20010915105159.A28361@folly> From: sjl@ssh.com (Sami J. Lehtinen) Date: 15 Sep 2001 16:53:24 +0300 In-Reply-To: markus@openbsd.org's message of "Sat, 15 Sep 2001 08:53:50 +0000 (UTC)" Message-ID: Lines: 20 X-Mailer: Gnus v5.6.45/XEmacs 21.1 - "Canyonlands" Sender: ietf-ssh-owner@netbsd.org Precedence: list markus@openbsd.org (Markus Friedl) writes: > On Fri, Sep 14, 2001 at 02:24:37PM -0600, Joseph Galbraith wrote: > > > are messages of type SSH_MSG_DEBUG allowed during authentication? > > Hmmm... I would think that higher protocol layers shouldn't > > be able to constrain lower protocol layers -- which would > > mean the DEBUG messages can be sent at any time which > > the transport draft allows them. > > yes, this is what i think, but it get reports that 3.0.x from > ssh.com complains about protocol violations if i send > SSH_MSG_DEBUG during authentication. > > -m That is a bug, then. -- [sjl@ssh.com -- Sami J. Lehtinen -- sjl@iki.fi] [work:+358 20 5007425][gsm:+358 40 864 3001][http://www.iki.fi/~sjl] [SSH Communications Security Corp http://www.ssh.com/] From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Sep 17 03:51:20 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA06044 for ; Mon, 17 Sep 2001 03:51:20 -0400 (EDT) Received: (qmail 7218 invoked by uid 605); 17 Sep 2001 07:50:29 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 7211 invoked from network); 17 Sep 2001 07:50:27 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 17 Sep 2001 07:50:27 -0000 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id 84B8C834E93; Mon, 17 Sep 2001 09:50:24 +0200 (MET DST) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id JAA05673; Mon, 17 Sep 2001 09:50:24 +0200 (MET DST) To: Andrew Brown Cc: Markus Friedl , Joseph Galbraith , ietf-ssh@netbsd.org Subject: Re: authentication and debug messages. References: <20010914212211.A10690@folly> <009901c13d5b$46a8f240$2800a8c0@test.vandyke.com> <20010915105159.A28361@folly> <20010915065912.A9110@noc.untraceable.net> MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (Niels Möller) Date: 17 Sep 2001 09:50:23 +0200 In-Reply-To: Andrew Brown's message of "Sat, 15 Sep 2001 06:59:12 -0400" Message-ID: Lines: 8 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 8bit Andrew Brown writes: > off the top of my head, i'd expect that SSH_MSG_DEBUG messages should > be allowed at any point. I agree. /Niels