i want to be able to suppress the banner from the client side
(ssh/slogin/scp/sftp) but i don't see a way to do it cleanly. for
example, if there were a -B flag that suppressed the banner that would
be alright. i did try -q, but that suppresses all stderr, which is
unacceptable since i do want to see the error output when ssh fails to
know why it failed. another idea would be to have -q suppress the
banner and -qq suppress all warning and diagnostic messages but
changing the behavior or an existing flag might be a bad idea.
the main reason for bringing this up is that i'd like to be able to
turn on a banner in sshd_config on the server side without breaking a
multitude of existing automated scripts that will barf when they start
getting unexpected output in the form of a banner statement. it is
true that if a flag were provided to suppress the banner i would have
to touch each script to add the flag as well as ask end-users to update
any scripts they might be using, but that's much cleaner than updating
each script to be smart enough to try and figure out what output is
part of the banner statement that needs to be ignored.
an idea i had that would allow turning on the banner that would not
require changing any of the automated scripts to either add a flag or
ignore the banner statement was the following simple code change. this
is from openssh-5.1p1:
*** sshconnect2.c.orig Thu Jul 17 03:15:43 2008
--- sshconnect2.c Fri Feb 13 09:19:22 2009
***************
*** 377,386 ****
--- 377,387 ----
void
input_userauth_banner(int type, u_int32_t seq, void *ctxt)
{
char *msg, *raw, *lang;
u_int len;
debug3("input_userauth_banner");
+ if (!isatty(1) || !isatty(2)) return;
raw = packet_get_string(&len);
lang = packet_get_string(NULL);
if (options.log_level >= SYSLOG_LEVEL_INFO) {
what i think this will accomplish is that if one of the ssh client
programs is called normally by a user, the banner will be displayed.
if however either stdout or stderr is redirected like you would do in
an automated script, the banner will be suppressed.
can anyone think of any unintended side-effects of the above change?
i'm new to this list. how are requests for enhancement handled? i
figured discussion would at least be the first step so that's what i'm
attempting to do with this email.
-john