Hide OpenSSH Version Banner

Here is a quick and dirty method for hiding some of the banner information advertised by OpenSSH[1]. This article focuses on how to use hexedit[2] to update your sshd binary to reduce information leakage.

Hiding the version information from OpenSSH is not supported by configuration[3]. This may have been added in some versions[4] and could be achieved by compiling your own version from source or switching to port knocking – these approaches are not covered.


SSH Servers such as OpenSSH advertise information such as protocol support, build version and host operating system. For example:

$ nc example.local 22
 SSH-2.0-OpenSSH_7.4p1 Raspbian-10+deb9u2

Would be attackers scan the internet[5] and create large databases to search for servers running software with known vulnerabilities[6]. While this may have somewhat legitimate uses such as research into market share of SSH servers or for system admins monitoring their network for machines requiring patches; its generally not a good idea to give away such information freely to the Internet.

You can also use telnet or nmap to snoop on the same information e.g:

$ nmap -A -T4 -p 22 example.local

Starting Nmap 7.60 ( ) 
Nmap scan report for example.local (
Host is up (0.0044s latency).
rDNS record for

22/tcp open ssh (protocol 2.0)
| fingerprint-strings:
|_ SSH-2.0-OpenSSH_7.4p1 Raspbian-10+deb9u2
$ telnet example 22
Trying ::1...
Connected to example.
Escape character is '^]'.
SSH-2.0-OpenSSH_7.4p1 Raspbian-10+deb9u2

Removing the Banner

Warning: Doing this while connected via SSH is risky as you can lock yourself out. If you are, set up a way to recover the original binary (i.e. set up another way to connect to the machine or a cron job to restore a copy of the original).

These steps use the hexedit[2] tool which is light weight and should be in your package manager. The goal is to write over the existing version string with text of your choice. The instructions are written for Debian / Systemd from steps followed on a Raspberri Pi running Raspbian.

  1. Check the current banner:
    $ echo "Hello" | nc localhost 22
    SSH-2.0-OpenSSH_7.4p1 Raspbian-10+deb9u2
    Protocol mismatch.

    In this case, the part of the banner we want to hide is “OpenSSH_7.4p1 Raspbian-10+deb9u2” which is broadcasting the versions of my SSH server and operating system. Hiding the protocol is a bit harder and not covered here.
    We can see this in the binary too:

    $ strings /tmp/ | grep Rasp
    OpenSSH_7.4p1 Raspbian-10+deb9u2
  2. Escalate to a root session:
    $ sudo su
  3. Install hexedit:
    # apt-get update && apt-get install hexedit
  4. Back up your sshd binary and create an editable working copy (as root):
    # cp /usr/sbin/sshd /tmp/sshd.backup
    # cp /tmp/sshd.backup /tmp/
  5. Update the binary with hexedit:
    # hexedit /tmp/

    Press TAB to switch from the HEX are to the ASCII area
    Use CTRL+S to bring up the search prompt and search for the text in your banner than you want to hide e.g. ‘OpenSSH_7.4’. You should see something like:

    0007DA54   61 67 65 6E  74 00 00 00  4F 70 65 6E  agent...Open
    0007DA60   53 53 48 5F  37 2E 34 70  31 20 52 61  SSH_7.4p1 Ra
    0007DA6C   73 70 62 69  61 6E 2D 31  30 2B 64 65  spbian-10+de
    0007DA78   62 39 75 32  00 00 00 00  4F 70 65 6E  b9u2....Open

    Use the arrow keys to highlight the start of the string that you want to update and type your replacement. Be careful to stay within the bounds of the length of the original banner. You can also press TAB to switch back to the HEX area if you wanted to just null out the string setting each word to ’00’.
    Your change should look something like:

    0007DA54   61 67 65 6E  74 00 00 00  48 65 72 65  agent...Here
    0007DA60   20 62 65 20  64 72 61 67  6F 6E 73 2E   be dragons.
    0007DA6C   20 54 75 72  6E 20 42 61  63 6B 00 00   Turn Back..
    0007DA78   00 00 00 00  00 00 00 00  4F 70 65 6E  ........Open

    Save your changes with CTRL+x and a Y.

  6. Check if there are any instances that we missed (we expect no output now):
    # strings /tmp/ | grep Rasp
  7. Update sshd and restart the service for good measure:
    # rm /usr/sbin/sshd
    # cp /tmp/ /usr/sbin/sshd
    # systemctl restart ssh.service
  8. Check that you can still SSH in (otherwise restore the backup or reinstall OpenSSH from your package manager!):
    # ssh user@localhost

This change will only be temporary as any time you update OpenSSH, the binary will be replaced.


The process above will result in something like the following:

$ nc localhost 22
SSH-2.0-Here be dragons. Turn Back

Where before this would be along the lines of:

$ nc localhost 22 
SSH-2.0-OpenSSH_7.4p1 Raspbian-10+deb9u2

Which makes it just a little bit more obscure and secure.


(last checked 2018-01-06)


2 thoughts to “Hide OpenSSH Version Banner”

  1. I see at least three problems with this approach:

    1. As you already mentioned: “This change will only be temporary as any time you update OpenSSH, the binary will be replaced.” So unless you want to mess with the sshd binary after every single update of the openssh-server package (either with hex editing or recompiling the latter seems to be easier to automate in a robust manner), you don’t want to go down this road.

    2. The SSH specification (RFC) prohibits any comliant implementation from messing with the software version part of the identification string.

    3. Lying about the software version or hiding it is “security through obscurity” which is a possible, although a widely questioned practise. Reference:
    If you know you have an old and vulnerable ssh daemon (i.e. with publicly known vulnerabilities) and for some reason you cannot deploy fixes, you’re in trouble anyway. Hiding software version numbers merely makes it a bit more difficult to identify your service/server as a target. Most vulnerabilities get a proof-of-concept code and a large number of these are integrated into vulnerability scanners, which do not rely on the version string that the service tells about itself.

    To summarize: I think you’re better off spending your time on actual security (eg. deploying updates) instead of hiding potential vulnerabilities.

  2. Hi Müzso,

    Absolutely agree! This is just an interesting and quick way to change the banner and not in of itself a way to secure an SSH service.

    1. Compiling a different banner from source, and especially tying to automate this for updates would be a lot more difficult.

    2. In the example from the article, I have left the protocol version untouched (i.e. still has ‘SSH-2.0-) which should allow most clients to connect without issue. I should have noted above that this part is required. Changes after this will just confuse the client/world about what software version is running – which is part of the point. I am the only consumer of my server and the banner is for my own amusement. In a serious commercial setting, the banner may actually be important for things like inventory management and looking for servers that need to be patched.

    3. This article isn’t about how to secure an SSH server. There are many things which I would recommend for that (on my server I have locked down root access, require an SSH key and whitelist inbound IPs amongst others). Just as would come from changing the port you run SSH on, the added obscurity reduces exposure and the likelihood of being on a database of targets when the next vulnerability is discovered. One should always expect and behave as though you are at the top of the list however.

    I appreciate the feedback and agree with your points. To be clear, this is not a way to make a SSH server secure from threat; its a ‘quick and dirty’ way to change the banner (that I have done for my own amusement – I use IP whitelisting to prevent my banner being seen outside my trusted networks). There are many services on the internet that obscure the software they are running (not uncommon on web servers) precisely to reduce the likelihood of being targeted, ever if they are no more secure than an equivalent service broadcasting its version information.

Leave a Reply

Your email address will not be published.