Remove Ubuntu/Debian version from sshd server string

For security reasons, I don’t like that “Debian/Ubuntu” shows up on my sshd server string.

You can see the sshd server identification string by telnetting to port 22.


$ telnet ngmarley.com 22
Trying 106.187.97.211...
Connected to ngmarley.com.
Escape character is '^]'.
SSH-2.0-OpenSSH_6.0p1 Debian-3ubuntu1
^]
telnet> quit
Connection closed.

It’s very simple to just remove the “Debian…” part off the end.

Just edit /etc/ssh/sshd_config and append

DebianBanner no

to it.

Then re-start your sshd:


service ssh restart

… and now verify that it’s gone:


$ telnet ngmarley.com 22
Trying 106.187.97.211...
Connected to ngmarley.com.
Escape character is '^]'.
SSH-2.0-OpenSSH_6.0p1
^]
telnet> quit
Connection closed.

Linux shared library error

Note: this was originally written on Apr 23, 2010, so that’s why the dates are from about a week and a half ago. Because I’m a lazy sod, I didn’t get around to publishing this until now.

After installing ntp on my Arch Linux server via pacman, I received this error message while trying to update my system time with ntpdate:


[root@ngmar01 ~]# ntpdate
ntpdate: error while loading shared libraries: libcrypto.so.1.0.0: cannot open shared object file: No such file or directory

At first I thought the error indicated that I was missing libcrypto, but then I checked and indeed I did have libcrypto installed on my system.

So then I checked the ntpdate executable itself. The ‘ldd’ utility lists dynamic dependencies of an executable (or, to put it another way, it lists the shared libraries on which the program is dependent).

[root@ngmar01 ~]# ldd $( which ntpdate )
linux-vdso.so.1 => (0x00007fffdcae6000)
libcrypto.so.1.0.0 => not found
librt.so.1 => /lib/librt.so.1 (0x00007fa1fef84000)
libcap.so.2 => /lib/libcap.so.2 (0x00007fa1fed80000)
libc.so.6 => /lib/libc.so.6 (0x00007fa1fea2a000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00007fa1fe80e000)
libattr.so.1 => /lib/libattr.so.1 (0x00007fa1fe60a000)
/lib/ld-linux-x86-64.so.2 (0x00007fa1ff18c000)

So we found the culprit. It’s obviously trying to link to “libcrypto.so.1.0.0”, which can’t be found anywhere in my shared lib path. Generally the error above is just a version problem and can be easily fixed with a symbolic link to the system version. A-like so:

[root@ngmar01 ~]# cd /usr/lib/
[root@ngmar01 lib]# ln -s libcrypto.so libcrypto.so.1.0.0

Now we no longer get a “not found” message when running ldd on the binary.
[root@ngmar01 lib]# ldd $( which ntpdate )
linux-vdso.so.1 => (0x00007fff88fff000)
libcrypto.so.1.0.0 => /usr/lib/libcrypto.so.1.0.0 (0x00007f85f8ce2000)
librt.so.1 => /lib/librt.so.1 (0x00007f85f8ada000)
libcap.so.2 => /lib/libcap.so.2 (0x00007f85f88d6000)
libc.so.6 => /lib/libc.so.6 (0x00007f85f8580000)
libdl.so.2 => /lib/libdl.so.2 (0x00007f85f837c000)
libz.so.1 => /usr/lib/libz.so.1 (0x00007f85f8164000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00007f85f7f48000)
libattr.so.1 => /lib/libattr.so.1 (0x00007f85f7d44000)
/lib/ld-linux-x86-64.so.2 (0x00007f85f9072000)

And now, to test that it’s working:

[root@ngmar01 lib]# ntpdate
23 Apr 22:48:24 ntpdate[20587]: no servers can be used, exiting

Note: the error above indicates that the binary is working, but I didn’t provide any command-line arguments. It’s beyond the scope of this post, but “ntpdate pool.ntp.org” should work.