From sacadmin Tue Jan 16 09:24:47 2007 Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0GHOlZG004095; Tue, 16 Jan 2007 09:24:47 -0800 (PST) Received: (from darrenm@localhost) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6/Submit) id l0GHOlfC004088; Tue, 16 Jan 2007 09:24:47 -0800 (PST) Date: Tue, 16 Jan 2007 09:24:47 -0800 (PST) From: Darren J Moffat Message-Id: <200701161724.l0GHOlfC004088@sac.sfbay.sun.com> To: PSARC@sac.sfbay.sun.com Cc: ssh-iteam@sun.com Subject: ssh disable banner [PSARC/2007/032 Timeout: 01/23/2007] Status: RO Content-Length: 5189 Template Version: @(#)onepager.txt 1.30 06/09/28 SMI 1. Introduction 1.1. Project/Component Working Name: New DisableBanner and DisableBannerInCommandMode options in Sun_SSH 1.2. Name of Document Author/Supplier: Jan Pechanec 1.3. Date of This Document: 01/11/07 1.4. Name of Major Document Customer(s)/Consumer(s): 1.4.2. The ARC(s) you expect to review your project: PSARC 1.4.4. The name of your business unit: Security 1.5. Email Aliases: 1.5.1. Responsible Manager: Craig.Payne@Sun.COM 1.5.2. Responsible Engineer: Jan.Pechanec@Sun.COM 1.5.3. Marketing Manager: Mark.Thacker@Sun.COM 1.5.4. Interest List: ssh-iteam@Sun.COM 2. Project Summary 2.1. Project Description: In some jurisdictions, sending a warning message before authentication may be relevant for getting legal protection. Many UNIX machines, for example, normally display text from /etc/issue, use TCP wrappers, or similar software to display a banner before issuing a login prompt. However, there is a clear difference between first time users logging in and (possibly) subsequent logins running SSH in remote command-only mode, for example using a quick search and run of a regular command from the shell history. In some scenarios, internal network for example, displaying a banner anytime might be even annoying while having it configured for connections from outside might still be a mandatory part of the security strategy. We already have a possibility to hush banner message when specifying '-q' option for quiet client operation but this will hush other warning messages as well. SSH Authentication Protocol (RFC 4252) permits the client side not to display a banner message (section "5.4 Banner Message) so what we propose here is an option to disable a banner message completely and also an option to disable it only for SSH remote command-only mode (SSH Connection Protocol - RFC 4254, section "6.5 Starting a Shell or a Command", specifing SSH_MSG_CHANNEL_REQUEST packet with "exec" request). SSH protocol specification doesn't specify that server should be the one to selectively decide whether to send a banner or not. This proposal is about SSH protocol 2.0 only, earlier versions of the protocol don't support displaying banner message at all. 2.2. Risks and Assumptions: None. 3. Business Summary 3.1. Problem Area: Customers want to display a banner message but they want an option to disable it for selected client's configurations. 3.3. Business Justification: Some customers convert from RSH to SSH and they report difficulty in configurations with banner messages in connection with remote command-only exec mode. 3.4. Competitive Analysis: The most often used player is OpenSSH project which doesn't have such options. 4. Technical Description: 4.1. Details: During the authentication phase, server can send SSH_MSG_USEAUTH_BANNER message before the authentication is over. This project would just add two new option keywords and change already existing code dealing with SSH_MSG_USEAUTH_BANNER to display the banner according to the newly added options. The change is easy and straightforward. 4.2. Bug/RFE Number(s): 4972643 wants banner page to display but not when issuing commands 4.5. Interfaces: We propose two new keywords for client side configuration files (ssh_config(5) and ~/.ssh/config files) DisableBanner DisableBannerInCommandMode both could be "yes" or "no", "no" by default for both. If both set to "yes" then DisableBanner takes precedence. With respect to the chosen 2nd option name - I chose to use "Command" instead of "Exec" because it's more meaningful for a user and even SSH Connection Protocol specification links "exec" mode with "starting a command" clause, which is different from "starting a shell" ("shell" mode). 4.6. Doc Impact: Manual page for ssh_config(5) would be changed. Diff follows: --- ssh_config.0 Wed Dec 20 15:52:44 2006 +++ ssh_config.0.banner Thu Jan 11 18:47:49 2007 @@ -166,18 +166,28 @@ ConnectionAttempts Specifies the number of tries (one per second) to make before falling back to rsh or exiting. The argument must be an integer. This can be useful in scripts if the con- nection sometimes fails. The default is 1. + DisableBanner + + Disables the display of banner message. See also Banner + option in sshd_config(5). + DisableBannerInCommandMode + + Disables the display of banner message when in remote + command-only mode. See also DisableBanner above and Banner + option in sshd_config(5). + + 4.7. Admin/Config Impact: None. 4.9. I18N/L10N Impact: None. Banner messages are to be displayed exactly as specified on server side. 4.10. Packaging & Delivery: SUNWsshr, SUNWman 4.11. Security Impact: N/A 4.12. Dependencies: N/A 5. Reference Documents: N/A 6. Resources and Schedule: 6.1. Projected Availability: project inception and integration: 1-2 Q 2007 6.5. ARC review type: FastTrack From sacadmin Tue Jan 16 09:36:00 2007 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0GHa04v004924; Tue, 16 Jan 2007 09:36:00 -0800 (PST) Received: from gmp-ea-fw-1.sun.com (gmpes-gis-mail-2.UK.Sun.COM [129.156.42.6]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l0GHZxqk016795; Tue, 16 Jan 2007 09:35:59 -0800 (PST) Received: from d1-emea-09.sun.com ([192.18.2.119]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l0GHZro6000264; Tue, 16 Jan 2007 17:35:53 GMT Received: from conversion-daemon.d1-emea-09.sun.com by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JBZ0090124CFD00@d1-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM); Tue, 16 Jan 2007 17:35:53 +0000 (GMT) Received: from [129.156.173.21] by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JBZ00DPR27TWE40@d1-emea-09.sun.com>; Tue, 16 Jan 2007 17:35:53 +0000 (GMT) Date: Tue, 16 Jan 2007 17:35:53 +0000 From: Darren J Moffat Subject: Corrected Spec Re: ssh disable banner [PSARC/2007/032 Timeout: 01/23/2007] In-reply-to: <200701161724.l0GHOlfC004088@sac.sfbay.sun.com> Sender: Darren.Moffat@Sun.COM To: Darren J Moffat Cc: PSARC@sac.sfbay.sun.com, ssh-iteam@Sun.COM Message-id: <45AD0CF9.5090902@Sun.COM> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_+mHefjEnodBx3nnOqWYCMw)" References: <200701161724.l0GHOlfC004088@sac.sfbay.sun.com> User-Agent: Thunderbird 1.5.0.8 (X11/20061128) Status: RO Content-Length: 6524 This is a multi-part message in MIME format. --Boundary_(ID_+mHefjEnodBx3nnOqWYCMw) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Due to a "save attachement", scp to sac.sfbay snafu on my part I sent this out with the wrong spec but the correct materials in the directory. The correct spec for this is a single new option as detailed in the attached spec file. sorry about that. -- Darren J Moffat --Boundary_(ID_+mHefjEnodBx3nnOqWYCMw) Content-type: text/plain; name=ssh-disable-banner.txt Content-transfer-encoding: 7BIT Content-disposition: inline; filename=ssh-disable-banner.txt Template Version: @(#)onepager.txt 1.30 06/09/28 SMI 1. Introduction 1.1. Project/Component Working Name: New DisableBanner option in SunSSH 1.2. Name of Document Author/Supplier: Jan Pechanec 1.3. Date of This Document: 01/16/07 1.4. Name of Major Document Customer(s)/Consumer(s): 1.4.2. The ARC(s) you expect to review your project: PSARC 1.4.4. The name of your business unit: Security 1.5. Email Aliases: 1.5.1. Responsible Manager: Craig.Payne@Sun.COM 1.5.2. Responsible Engineer: Jan.Pechanec@Sun.COM 1.5.3. Marketing Manager: Mark.Thacker@Sun.COM 1.5.4. Interest List: ssh-iteam@Sun.COM 2. Project Summary 2.1. Project Description: In some jurisdictions, sending a warning message before authentication may be relevant for getting legal protection. Many UNIX machines, for example, normally display text from /etc/issue, use TCP wrappers, or similar software to display a banner before issuing a login prompt. However, there is a clear difference between first time users logging in and (possibly) subsequent logins running SSH in remote command-only mode, for example using a quick search and run of a regular command from the shell history. In some scenarios, internal network for example, displaying a banner anytime might be even annoying while having it configured for connections from outside might still be a mandatory part of the security strategy. We already have a possibility to hush banner message when specifying '-q' option for quiet client operation but this will hush other warning messages as well. SSH Authentication Protocol (RFC 4252) permits the client side not to display a banner message (section "5.4 Banner Message) so what we propose here is an option to disable a banner message completely and also a way to disable it only for SSH remote command-only mode (SSH Connection Protocol - RFC 4254, section "6.5 Starting a Shell or a Command", specifing SSH_MSG_CHANNEL_REQUEST packet with "exec" request). SSH protocol specification doesn't specify that server should be the one to selectively decide whether to send a banner or not. This proposal is about SSH protocol 2.0 only, earlier versions of the protocol don't support displaying banner message at all. 2.2. Risks and Assumptions: None. 3. Business Summary 3.1. Problem Area: Customers want to display a banner message but they want an option to disable it for selected client's configurations. 3.3. Business Justification: Some customers convert from RSH to SSH and they report difficulty in configurations with banner messages in connection with remote command-only exec mode. 3.4. Competitive Analysis: The most often used player is OpenSSH project which doesn't have a proposed option or any other way how to achieve that. 4. Technical Description: 4.1. Details: During the authentication phase, server can send SSH_MSG_USEAUTH_BANNER message before the authentication is over. This project would add a new option keyword and change already existing code dealing with SSH_MSG_USEAUTH_BANNER to display the banner according to the newly added option keyword. The change is easy and straightforward. 4.2. Bug/RFE Number(s): 4972643 wants banner page to display but not when issuing commands 4.5. Interfaces: We propose a new keyword for client side configuration files (ssh_config(5) and ~/.ssh/config files). Interface stability is Committed: DisableBanner the argument could be "yes" or "no" or "in-exec-mode". "no" is the default. With respect to the chosen argument value "in-exec-mode", I directly followed SSH Connection Protocol specification defining "exec" mode as remote command-only mode. This way we can easily extend this if needed in backward compatible way to a comma separated list in the future for existing modes "shell", "subsystem" or any other new modes that might come using generic "in-xyz-mode" template value. However, it's not needed now and I'm not convinced it will be needed in the future so we won't include it in this case. 4.6. Doc Impact: Manual page for ssh_config(5) would be changed. Diff follows: --- ssh_config.0 Tue Jan 16 13:23:28 2007 +++ ssh_config.0.banner Tue Jan 16 14:25:00 2007 @@ -124,14 +124,24 @@ ConnectionAttempts Specifies the number of tries (one per second) to make before falling back to rsh or exiting. The argument must be an integer. This can be useful in scripts if the con- nection sometimes fails. The default is 1. + DisableBanner + + If set to "yes" it disables the display of banner + message. If set to "in-exec-mode" it disables the + display of banner message when in remote command mode + only. Default value is "no" which means that by default + the banner is displayed every time. See also Banner + option in sshd_config(5). This option applies to + protocol version 2 only. + DynamicForward Specifies that a TCP/IP port on the local machine be forwarded over the secure channel. The application pro- tocol is then used to determine where to connect to from the remote machine. The argument must be a port number. Currently the SOCKS4 protocol is supported, and ssh will 4.7. Admin/Config Impact: None. 4.9. I18N/L10N Impact: None. Banner messages are to be displayed exactly as specified on server side. 4.10. Packaging & Delivery: SUNWsshr, SUNWman 4.11. Security Impact: N/A 4.12. Dependencies: N/A 5. Reference Documents: N/A 6. Resources and Schedule: 6.1. Projected Availability: project inception and integration: 1-2 Q 2007 6.5. ARC review type: FastTrack --Boundary_(ID_+mHefjEnodBx3nnOqWYCMw)-- From sacadmin Thu Jan 18 06:56:18 2007 Received: from eastmail4bur.east.Sun.COM (eastmail4bur.East.Sun.COM [129.148.13.1]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0IEuIwo013066 for ; Thu, 18 Jan 2007 06:56:18 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail4bur.east.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l0IEuFnv009962; Thu, 18 Jan 2007 09:56:16 -0500 (EST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by thunk.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l0IEuFct019732; Thu, 18 Jan 2007 09:56:15 -0500 (EST) Subject: Re: Corrected Spec Re: ssh disable banner [PSARC/2007/032 Timeout: 01/23/2007] From: Bill Sommerfeld To: Darren J Moffat Cc: PSARC@sac.sfbay.sun.com, ssh-iteam@sun.com In-Reply-To: <45AD0CF9.5090902@Sun.COM> References: <200701161724.l0GHOlfC004088@sac.sfbay.sun.com> <45AD0CF9.5090902@Sun.COM> Content-Type: text/plain Date: Thu, 18 Jan 2007 09:56:15 -0500 Message-Id: <1169132175.19606.4.camel@thunk> Mime-Version: 1.0 X-Mailer: Evolution 2.8.1.1 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 593 On Tue, 2007-01-16 at 17:35 +0000, Darren J Moffat wrote: > 3.4. Competitive Analysis: > > The most often used player is OpenSSH project which doesn't have > a proposed option or any other way how to achieve that. Funny to describe it that way as Sun's SSH implementation is a derivative of OpenSSH. Have we discussed this proposal with the OpenSSH maintainers? (If we have, this should have been mentioned in the materials. If we haven't, I think we should have...). Are we going to push this extension back upstream, or keep it a quirk of our implementation? - Bill From sacadmin Thu Jan 18 07:24:14 2007 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0IFOETv013625 for ; Thu, 18 Jan 2007 07:24:14 -0800 (PST) Received: from gmp-ea-fw-1.sun.com (gmpes-gis-mail-2.UK.Sun.COM [129.156.42.6]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l0IFODBJ000767 for ; Thu, 18 Jan 2007 07:24:14 -0800 (PST) Received: from d1-emea-10.sun.com ([192.18.2.120]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l0IFO8jv023118 for ; Thu, 18 Jan 2007 15:24:08 GMT Received: from conversion-daemon.d1-emea-10.sun.com by d1-emea-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JC200201LDR8B00@d1-emea-10.sun.com> (original mail from Jan.Pechanec@Sun.COM) for PSARC@sac.sfbay.sun.com; Thu, 18 Jan 2007 15:24:08 +0000 (GMT) Received: from andal ([129.157.18.59]) by d1-emea-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JC200387LG78E05@d1-emea-10.sun.com>; Thu, 18 Jan 2007 15:24:08 +0000 (GMT) Date: Thu, 18 Jan 2007 16:23:53 +0100 (CET) From: Jan Pechanec Subject: Re: Corrected Spec Re: ssh disable banner [PSARC/2007/032 Timeout: 01/23/2007] In-reply-to: <1169132175.19606.4.camel@thunk> Sender: Jan.Pechanec@Sun.COM X-X-Sender: jp161948@andal To: Bill Sommerfeld Cc: Darren J Moffat , PSARC@sac.sfbay.sun.com, ssh-iteam@Sun.COM Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT References: <200701161724.l0GHOlfC004088@sac.sfbay.sun.com> <45AD0CF9.5090902@Sun.COM> <1169132175.19606.4.camel@thunk> Status: RO Content-Length: 1278 On Thu, 18 Jan 2007, Bill Sommerfeld wrote: hi Bill, >On Tue, 2007-01-16 at 17:35 +0000, Darren J Moffat wrote: >> 3.4. Competitive Analysis: >> >> The most often used player is OpenSSH project which doesn't have >> a proposed option or any other way how to achieve that. > >Funny to describe it that way as Sun's SSH implementation is a >derivative of OpenSSH. yeah, but since that's the way it is now... >Have we discussed this proposal with the OpenSSH maintainers? (If we >have, this should have been mentioned in the materials. If we haven't, >I think we should have...). no, I didn't discuss that with them. >Are we going to push this extension back upstream, or keep it a quirk of >our implementation? I could make a patch from our code and offer it to them, after that it would be up to them. However, I don't think we should discuss with them what we want to put into SunSSH since I think that is how it would look like. We want this because our customers want it and we think it's reasonable, that's it. it's not that I wouldn't want to discuss it with them it's just that they were very explicit about Sun the last time and I just don't feel like we should be coming back and asking them if they like our ideas. Jan. -- Jan Pechanec From sacadmin Thu Jan 18 09:21:48 2007 Received: from eastmail4bur.east.Sun.COM (eastmail4bur.East.Sun.COM [129.148.13.1]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0IHLlZT016036 for ; Thu, 18 Jan 2007 09:21:47 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail4bur.east.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l0IHLeo5016632; Thu, 18 Jan 2007 12:21:40 -0500 (EST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by thunk.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l0IHLeEf021112; Thu, 18 Jan 2007 12:21:40 -0500 (EST) Subject: Re: Corrected Spec Re: ssh disable banner [PSARC/2007/032 Timeout: 01/23/2007] From: Bill Sommerfeld To: Jan Pechanec Cc: Darren J Moffat , PSARC@sac.sfbay.sun.com, ssh-iteam@sun.com In-Reply-To: References: <200701161724.l0GHOlfC004088@sac.sfbay.sun.com> <45AD0CF9.5090902@Sun.COM> <1169132175.19606.4.camel@thunk> Content-Type: text/plain Date: Thu, 18 Jan 2007 12:21:39 -0500 Message-Id: <1169140899.19606.62.camel@thunk> Mime-Version: 1.0 X-Mailer: Evolution 2.8.1.1 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 1110 On Thu, 2007-01-18 at 16:23 +0100, Jan Pechanec wrote: > >Have we discussed this proposal with the OpenSSH maintainers? (If we > >have, this should have been mentioned in the materials. If we haven't, > >I think we should have...). > > no, I didn't discuss that with them. Please do. Consider what happens if they accept the functionality but want to tweak the interface prior to accepting the change into OpenSSH. > >Are we going to push this extension back upstream, or keep it a quirk of > >our implementation? > > I could make a patch from our code and offer it to them, after that > it would be up to them. However, I don't think we should discuss with them > what we want to put into SunSSH since I think that is how it would look > like. We want this because our customers want it and we think it's > reasonable, that's it. In general when we import externally maintained code from outside we want to avoid divergence with upstream maintainers. Even if there are areas where we may have agreed to disagree, we should continue to talk to them about orthogonal changes... - Bill From sacadmin Tue Jan 23 08:30:53 2007 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0NGUrCg021741 for ; Tue, 23 Jan 2007 08:30:53 -0800 (PST) Received: from gmp-ea-fw-1.sun.com (gmpes-gis-mail-1.UK.Sun.COM [129.156.42.5]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l0NGUqCP014168 for ; Tue, 23 Jan 2007 08:30:53 -0800 (PST) Received: from d1-emea-09.sun.com (d1-emea-09.sun.com [192.18.2.119]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l0NGUlim028796 for ; Tue, 23 Jan 2007 16:30:47 GMT Received: from conversion-daemon.d1-emea-09.sun.com by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JCB00B01XKLFC00@d1-emea-09.sun.com> (original mail from Jan.Pechanec@Sun.COM) for PSARC@sac.sfbay.sun.com; Tue, 23 Jan 2007 16:30:47 +0000 (GMT) Received: from andal ([129.157.18.59]) by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JCB00MILXV70R25@d1-emea-09.sun.com>; Tue, 23 Jan 2007 16:30:44 +0000 (GMT) Date: Tue, 23 Jan 2007 17:30:27 +0100 (CET) From: Jan Pechanec Subject: Re: Corrected Spec Re: ssh disable banner [PSARC/2007/032 Timeout: 01/23/2007] In-reply-to: <1169140899.19606.62.camel@thunk> Sender: Jan.Pechanec@Sun.COM X-X-Sender: jp161948@andal To: Bill Sommerfeld Cc: Darren J Moffat , PSARC@sac.sfbay.sun.com, ssh-iteam@Sun.COM Message-id: Content-id: MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_X1y+DCLhglzmgCiflOjdvQ)" References: <200701161724.l0GHOlfC004088@sac.sfbay.sun.com> <45AD0CF9.5090902@Sun.COM> <1169132175.19606.4.camel@thunk> <1169140899.19606.62.camel@thunk> Status: RO Content-Length: 1130 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --Boundary_(ID_X1y+DCLhglzmgCiflOjdvQ) Content-id: Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT On Thu, 18 Jan 2007, Bill Sommerfeld wrote: >On Thu, 2007-01-18 at 16:23 +0100, Jan Pechanec wrote: >> >Have we discussed this proposal with the OpenSSH maintainers? (If we >> >have, this should have been mentioned in the materials. If we haven't, >> >I think we should have...). >> >> no, I didn't discuss that with them. > >Please do. I did a couple of days ago. They are not interested in this feature. attached is the short communication I had with them. Jan. -- Jan Pechanec --Boundary_(ID_X1y+DCLhglzmgCiflOjdvQ) Content-id: Content-type: TEXT/PLAIN; NAME=disable-banner-openssh-discussion.txt; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Content-disposition: ATTACHMENT; FILENAME=disable-banner-openssh-discussion.txt Content-description: From Jan.Pechanec@Sun.COM Thu Jan 18 21:59:57 2007 Date: Thu, 18 Jan 2007 19:52:51 +0100 (CET) From: Jan Pechanec To: openssh-unix-dev@mindrot.org Subject: proposal: new DisableBanner client side option Status: RO Content-Length: 1171 hi all, we had quite a few requests recently so that SunSSH allowed to hush a banner on client side when in command-mode only. The argument usually is that the banner is mandatory due to legal reasons so first time login users should see it but that it causes problems when ssh is used from scripts after that. '-q' often seems not an option. RFC 4252 permits hushing banner in section 5.4. we want to add DisableBanner option to SunSSH with yes/no/in-exec-mode arguments, default to "no". It's designed to be extendable in a backward compatible way to a comma separated list of "in--mode" strings if needed in the future. "in-subsystem-mode" could be the next candidate. since we try to avoid divergence with upstream (= OpenSSH) if possible I would like to ask, in case you would be interested in adding such functionality to OpenSSH in which case I can provide a patch then, whether this would be an acceptible syntax for both. thanks, Jan. -- Jan Pechanec Sun Microsystems _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@mindrot.org http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From djm@mindrot.org Thu Jan 18 22:38:00 2007 Date: Fri, 19 Jan 2007 08:37:27 +1100 (EST) From: Damien Miller To: Jan Pechanec Cc: openssh-unix-dev@mindrot.org Subject: Re: proposal: new DisableBanner client side option Status: RO Content-Length: 1567 On Thu, 18 Jan 2007, Jan Pechanec wrote: > > hi all, we had quite a few requests recently so that SunSSH allowed > to hush a banner on client side when in command-mode only. The argument > usually is that the banner is mandatory due to legal reasons so first time > login users should see it but that it causes problems when ssh is used from > scripts after that. '-q' often seems not an option. RFC 4252 permits hushing > banner in section 5.4. "ssh -q" or the "Loglevel quiet" config option will hush the banner fine on OpenSSH. IMO not doing so "for legal reasons" is just silly. What next, will Solaris disable stderr redirection to prevent someone from missing a disclaimer? If people want to stick their heads in the sand then they will find a way. > we want to add DisableBanner option to SunSSH with > yes/no/in-exec-mode arguments, default to "no". It's designed to be > extendable in a backward compatible way to a comma separated list of > "in--mode" strings if needed in the future. "in-subsystem-mode" could > be the next candidate. > > since we try to avoid divergence with upstream (= OpenSSH) if > possible I would like to ask, in case you would be interested in adding such > functionality to OpenSSH in which case I can provide a patch then, whether > this would be an acceptible syntax for both. Thanks for making the effort to retain compatibility, but OpenSSH won't adopt such an option. I don't think it is necessary, and there is a strong consensus among the developers to have fewer, rather than more, options. -d From markus.r.friedl@arcor.de Fri Jan 19 13:59:52 2007 Date: Fri, 19 Jan 2007 13:59:33 +0100 From: Markus Friedl To: Jan Pechanec Cc: Iain Morgan , openssh-unix-dev@mindrot.org Subject: Re: proposal: new DisableBanner client side option Status: RO Content-Length: 429 On Thu, Jan 18, 2007 at 11:33:00PM +0100, Jan Pechanec wrote: > I know that, my note about '-q' option was probably an overly subtle > attempt to say that some customers really want to hush banner but they do > want to see other warnings at the same time. So, using '-q' is not an > solution for them. LogLevel=ERROR suppresses banners and keeps other warnings. otherwise you have to add options for every message printed. From Jan.Pechanec@Sun.COM Fri Jan 19 14:55:21 2007 Date: Fri, 19 Jan 2007 14:53:15 +0100 (CET) From: Jan Pechanec To: Markus Friedl Cc: Iain Morgan , openssh-unix-dev@mindrot.org Subject: Re: proposal: new DisableBanner client side option Status: RO Content-Length: 877 On Fri, 19 Jan 2007, Markus Friedl wrote: >On Thu, Jan 18, 2007 at 11:33:00PM +0100, Jan Pechanec wrote: >> I know that, my note about '-q' option was probably an overly subtle >> attempt to say that some customers really want to hush banner but they do >> want to see other warnings at the same time. So, using '-q' is not an >> solution for them. > >LogLevel=ERROR > >suppresses banners and keeps other warnings. otherwise you have yes, but logit() uses default INFO level and still is used for warnings sometimes. To change level of some mesages seems more confusing for me that adding an option for a special case of banner message. Jan. -- Jan Pechanec _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@mindrot.org http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev --Boundary_(ID_X1y+DCLhglzmgCiflOjdvQ)-- From sacadmin Mon Jan 29 01:15:31 2007 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0T9FVOJ000134 for ; Mon, 29 Jan 2007 01:15:31 -0800 (PST) Received: from gmp-ea-fw-1.sun.com (gmpes-gis-mail-1.UK.Sun.COM [129.156.42.5]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l0T9FUlc020682 for ; Mon, 29 Jan 2007 01:15:30 -0800 (PST) Received: from d1-emea-10.sun.com (d1-emea-10.sun.com [192.18.2.120]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l0T9FOkx019512 for ; Mon, 29 Jan 2007 09:15:24 GMT Received: from conversion-daemon.d1-emea-10.sun.com by d1-emea-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JCM00J01HHBY900@d1-emea-10.sun.com> (original mail from Jan.Pechanec@Sun.COM) for PSARC@sac.sfbay.sun.com; Mon, 29 Jan 2007 09:15:24 +0000 (GMT) Received: from andal ([129.157.18.59]) by d1-emea-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JCM00FSYHP3T8OR@d1-emea-10.sun.com>; Mon, 29 Jan 2007 09:15:04 +0000 (GMT) Date: Mon, 29 Jan 2007 10:14:41 +0100 (CET) From: Jan Pechanec Subject: Re: Corrected Spec Re: ssh disable banner [PSARC/2007/032 Timeout: 01/23/2007] In-reply-to: <45AD0CF9.5090902@Sun.COM> Sender: Jan.Pechanec@Sun.COM X-X-Sender: jp161948@andal To: PSARC@sac.sfbay.sun.com Cc: ssh-iteam@Sun.COM Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT References: <200701161724.l0GHOlfC004088@sac.sfbay.sun.com> <45AD0CF9.5090902@Sun.COM> Status: RO Content-Length: 465 On Tue, 16 Jan 2007, Darren J Moffat wrote: > Due to a "save attachement", scp to sac.sfbay snafu on my part I sent this out > with the wrong spec but the correct materials in the directory. > > The correct spec for this is a single new option as detailed in the attached > spec file. I forgot to include one thing in the material - those 7 RFE's might be put back separately or in groups, not necessarily all 7 in one putback. thanks, Jan. -- Jan Pechanec From sacadmin Wed Jan 31 09:33:35 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0VHXZ7Q020461 for ; Wed, 31 Jan 2007 09:33:35 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l0VHXVip012291; Wed, 31 Jan 2007 09:33:31 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JCQ00H09U3VAH00@nwk-avmta-2.sfbay.sun.com>; Wed, 31 Jan 2007 09:33:31 -0800 (PST) Received: from nwk-ea-fw-1.sun.com ([10.4.134.5]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JCQ00C7AU3UD0D0@nwk-avmta-2.sfbay.sun.com>; Wed, 31 Jan 2007 09:33:30 -0800 (PST) Received: from d1-sfbay-09.sun.com ([192.18.39.119]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l0VHXUuP026747; Wed, 31 Jan 2007 09:33:30 -0800 (PST) Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JCQ00901U09JR00@d1-sfbay-09.sun.com> (original mail from Sherri.Shieh@Sun.COM); Wed, 31 Jan 2007 09:33:30 -0800 (PST) Received: from [129.145.154.108] by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JCQ008GQU3T1YB7@d1-sfbay-09.sun.com>; Wed, 31 Jan 2007 09:33:30 -0800 (PST) Date: Wed, 31 Jan 2007 09:33:29 -0800 From: Sherri Shieh Subject: PSARC Fast track: ssh disable banner (2007/032) Sender: Sherri.Shieh@Sun.COM To: psarc@Sun.COM, Darren Moffat , Jan.Pechanec@Sun.COM Cc: ssh-iteam@Sun.COM Message-id: <45C0D2E9.40505@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 User-Agent: Mozilla/5.0 (X11; U; SunOS sun4v; en-US; rv:1.7) Gecko/20060120 Status: RO Content-Length: 341 This case has been marked closed approved based on last week's meeting. - Sherri -- ========================================================= Sherri Shieh Sun Microsystems, Inc. Program Manager Email: sherri.shieh@sun.com Systems Architecture Phone: 650-786-5245/x85245 ===========================================================