OpenSSH
[Top] [All Lists]

Re: proposal: new DisableBanner client side option

To: Jan Pechanec <Jan.Pechanec@Sun.COM>
Subject: Re: proposal: new DisableBanner client side option
From: Damien Miller <djm@mindrot.org>
Date: Fri, 19 Jan 2007 08:37:27 +1100 (EST)
Cc: openssh-unix-dev@mindrot.org
Delivered-to: sp-com-lists@consult.net
Delivered-to: openssh-unix-dev-list1@securepoint.com
Delivered-to: openssh-unix-dev-tmda@mindrot.org
Delivered-to: openssh-unix-dev@mindrot.org
In-reply-to: <Pine.GSO.4.61.0701181836010.798@andal>
List-archive: <http://lists.mindrot.org/pipermail/openssh-unix-dev>
List-help: <mailto:openssh-unix-dev-request@mindrot.org?subject=help>
List-id: Development of portable OpenSSH <openssh-unix-dev.mindrot.org>
List-post: <mailto:openssh-unix-dev@mindrot.org>
List-subscribe: <http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev>, <mailto:openssh-unix-dev-request@mindrot.org?subject=subscribe>
List-unsubscribe: <http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev>, <mailto:openssh-unix-dev-request@mindrot.org?subject=unsubscribe>
References: <Pine.GSO.4.61.0701181836010.798@andal>
Sender: openssh-unix-dev-bounces+openssh-unix-dev-list1=securepoint.com@mindrot.org
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>-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

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

<Prev in Thread] Current Thread [Next in Thread>