43

I've read Stop ssh login from printing motd from the client?, however my situation is a bit different :

  • I want to keep Banner /path/to/sometxt serverside
  • I would like to pass an option under specific conditions so that Banner is not printed (eg ssh -o "PrintBanner=No" someserver).

Any idea?

13 Answers 13

-5

You can't. (At least not with stock OpenSSH)

The server banner is sent by the server before authentication happens. It's point is usually to contain a legal disclaimer or similar "If you're not authorized disconnect NOW" type message, or other critical things you don't want the remote user to be able to suppress/ignore.

If you really want to get rid of this you will need to hack and compile your own customized version of the SSH client.

2
  • 29
    This is old information and no longer true on common distributions. The answers below to use either -q or -o LogLevel=error work great now :-)
    – Dogsbody
    Nov 28, 2015 at 19:49
  • "You can't. (At least not with stock OpenSSH) The server banner is sent by the server before authentication happens." ... Are you ACTUALLY FOR REAL ?!? imagine that banner contains private information in that company, no one would use ssh anymore if such HORRIBLE BREACH OF SECURTY would be in place ! ... TURN THE POWER ON DUDE ! Dec 20, 2023 at 9:16
79

There is a LogLevel option:

It silences the banner but you're still able to receive errors:

$ ssh -o LogLevel=error localhost 
Permission denied (publickey).
2
  • Didn't work with OpenSSH 6.9 client - perhaps version information would be useful? Apr 11, 2016 at 9:01
  • Works with OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.3, OpenSSL 1.0.1f 6 Jan 2014 May 17, 2016 at 19:31
16

I 've tested it, I think u can use -q in the ssh command. Parameter -q was means Quiet mode. It causes most warning and diagnostic messages to be suppressed, e.g.

ssh -t '$node2' 'sudo cat xxx' |grep xxxxx" 2>/dev/null >/root/node2

or

ssh -t -q '$node2' 'sudo cat xxxx' |grep xxx" >/root/node2

Hope this can help others

1
  • -q didn't work from a Fedora 22 client to Centos 6 and Suse 2.6 (client was OpenSSH 6.9. Maybe this answer would be upvoted if it referenced specific ssh version? Apr 11, 2016 at 9:00
13

Update ~/.ssh/config with following to suppress banner

Host *
    LogLevel error
1
  • 1
    I believe the "Host *" line is either redundant or incorrect. At any rate, I get the desired effect without it. Altho it should be noted that OP wanted to get the effect under certain programmatic conditions, in which case the command line option listed above is the better solution.
    – UncaAlby
    Dec 26, 2017 at 23:41
9

Seems like you're looking for -q:

Quiet mode. Causes most warning and diagnostic messages to be suppressed.

ssh user@host
*------------------------------------------------------------------------------*
| banner: blah                                                                 |
*------------------------------------------------------------------------------*
Last login: Mon Oct  2 16:40:01 2017 from ipAddress
$

With -q

ssh -q user@host
Last login: Mon Oct  2 16:40:30 2017 from ipAddress
$

Nice and quiet. The banner is still configured but you're not bothered by it.

On another note: don't use banners. It's best not to confirm or deny anything. It won't help you with the people you weren't worried about and the people you are worried about will laugh as they work past it ;-)

6

You should be able to set a different Banner (to none) inside a Match block.

For instance:

Match Address 192.0.2.0/24
        Banner none

But this has to be done server-side, based on specific conditions. You can't do it from the client side.

4

For me, -o LogLevel=error was better than -q, because the latter suppresses the important error information (which you can then obtain only via exit code).

Compare this (without options): [root@myserver804 myuser1]# ssh targetserver1; echo "exit code=$?" @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that a host key has just been changed. The fingerprint for the RSA key sent by the remote host is SHA256:hvtR8Dl09aUeCeG2cT5EA8b+nbCOoV6h1DUON2vE63w. Please contact your system administrator. Add correct host key in /root/.ssh/known_hosts to get rid of this message. Offending RSA key in /root/.ssh/known_hosts:1735 RSA host key for targetserver1 has changed and you have requested strict checking. Host key verification failed. exit code=255

with this (quiet) [root@myserver804 myuser1]# ssh -q targetserver1; echo "exit code=$?" exit code=255

with this (only log errors) [root@myserver804 myuser1]# ssh -o LogLevel=error targetserver1; echo "exit code=$?" @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that a host key has just been changed. The fingerprint for the RSA key sent by the remote host is SHA256:hvtR8Dl09aUeCeG2cT5EA8b+nbCOoV6h1DUON2vE63w. Please contact your system administrator. Add correct host key in /root/.ssh/known_hosts to get rid of this message. Offending RSA key in /root/.ssh/known_hosts:1735 RSA host key for targetserver1 has changed and you have requested strict checking. Host key verification failed. exit code=255

So the conclusion is - if you are still interested in relevant errors, use -o LogLevel=error

2
  • "-q" is definetly not a good option indeed :) Apr 19, 2022 at 9:55
  • On centos 7.9 the output of "-q" and "-o ..." is exactly the same. Meaning that they both show the output that you posted.
    – salvador
    Oct 4, 2023 at 12:25
2

Neither the -q or the -oLogLevel=error works.

What does work is to suppress STDERR

ssh hostname command 2>/dev/null

The downside, however, is that the STDERR suppression is applied to the entire command and not just the SSH program.

2

On a user basis you can suppress server banners by creating an empty file in a user's $HOME directory (/home/username/) called .hushlogin.

touch ~/.hushlogin
1
  • does not work for banner served prior to login.
    – mckenzm
    Mar 29, 2022 at 3:18
2

Ok adding my resolution. I discovered that I was getting different results depending on how I used ssh.

ssh -q tgt true
No Banner

ssh -q tgt <<EOF
true
EOF
Banner

ssh -q tgt bash <<EOF
true
EOF
No Banner
2
  • Nice! bash call solved it for me.
    – Fedcomp
    Nov 17, 2023 at 6:41
  • Best. I solved my issue by this answer.
    – OfusJK
    Jan 12 at 7:50
0

Try:

ssh -q

my ssh conections, do not get a banner message.

-2

Just call a shell, that should suppress the banner.

ssh [email protected] /bin/bash

Note though, for me at least, my $PS1 doesn't get set, so it looks like it's hanging. I had to type a couple of commands to verify that it was working.

2
  • 1
    This won't suppress banners shown by the Banner option in /etc/sshd_config (at least it doesn't on FreeBSD / OpenSSH_5.8p2)
    – voretaq7
    Jun 13, 2013 at 17:06
  • 1
    Ah, I saw motd in the question. That'll learn me to read the description properly ;)
    – chrskly
    Jun 13, 2013 at 17:21
-3

For me -q did the trick and I was still able to work with the output saved to a file.

ssh -q root@server28 "ls -alF /dr_mksysb |egrep -v \"total|lost+found|./|../\" |awk '{print \$NF}' |sed 's/.\$//g'" > ${basedir}/28.list

3
  • Great that it works for you. Nevertheless this doesn't answer the question and should be a comment at most. Jul 6, 2016 at 8:12
  • That's the problem, it does answer the question, I got rid of motd (banner) I had exactly the same problem as stated in the question
    – Zatarra
    Jul 6, 2016 at 9:03
  • The only part of your answer that relates to the question is the -q parameter. The rest is completely unrelated and is only helpful to you. The parameter has already been given as an answer, so feel free to upvote it if it helped you, but this "answer" will only receive downvotes Jul 6, 2016 at 9:12

You must log in to answer this question.