Mailing List Archive

>
> DebianBanner no

I think DebianBanner is a debian-specific option so you'd have to take
this request for help to them, but for what it's worth it works for me

$ telnet localhost 22
Trying ::1...
Connected to localhost.
Escape character is '^]'.
SSH-2.0-OpenSSH_8.3p1 Debian-1

and with DebianBanner no

$ telnet localhost 22
Trying ::1...
Connected to localhost.
Escape character is '^]'.
SSH-2.0-OpenSSH_8.3p1



> And restart your SSH daemon: /etc/init.d/ssh restart or service ssh restart
>
> This doent change anything.
>
> Another question why user cant hide SSH info as well? why it needs to be
> publicly visible? (I read that only recompiling would fix that but this
> is pain in the neck)
>
> ThX!
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev@mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On Mon, 15 Jun 2020, bo0od wrote:

> Im trying to hide the ability to show my host details from OpenSSH on
> GNU/Linux Debian using this method:
>
> Add the following line to /etc/ssh/sshd_config
>
> DebianBanner no
>
> And restart your SSH daemon: /etc/init.d/ssh restart or service ssh restart
>
> This doent change anything.
>
> Another question why user cant hide SSH info as well? why it needs to be
> publicly visible? (I read that only recompiling would fix that but this is
> pain in the neck)

It's public because it's used to make compatibility decisions, see compat.c
in the OpenSSH source distrubution.

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

maybe its useful but on the other hand its bad decision if user want to
hide it in order to avoid bots attacks for vulnerable versions (for
surely it should be left not updated for long time BUT still optional
setting is preferable for the user to choose hide it or not)

Default can be show version , but at least provide easy option to hide.

Damien Miller:
> On Mon, 15 Jun 2020, bo0od wrote:
>
>> Im trying to hide the ability to show my host details from OpenSSH on
>> GNU/Linux Debian using this method:
>>
>> Add the following line to /etc/ssh/sshd_config
>>
>> DebianBanner no
>>
>> And restart your SSH daemon: /etc/init.d/ssh restart or service ssh restart
>>
>> This doent change anything.
>>
>> Another question why user cant hide SSH info as well? why it needs to be
>> publicly visible? (I read that only recompiling would fix that but this is
>> pain in the neck)
>
> It's public because it's used to make compatibility decisions, see compat.c
> in the OpenSSH source distrubution.
>
> -d
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev@mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Hi bo0od,

bo0od <bo0od@riseup.net> writes:

> maybe its useful but on the other hand its bad decision if user want to
> hide it in order to avoid bots attacks for vulnerable versions (for
> surely it should be left not updated for long time BUT still optional
> setting is preferable for the user to choose hide it or not)

Security through obscurity is not security. It is security theatre.

Even if a lot of OS distirbutions patch the security problems with
secure shell and do NOT update the version string being passed.

> Default can be show version , but at least provide easy option to hide.

The option exists, recompile.

Or, pay someone to support the option for you and have them provide you
the binaries.

There have been MANY interoperability issues across Secure Shell
implementations and releases of code such that the exact version
information is HIGHLY desirable to avoid interoperability problems. As
has been suggested, for OpenSSH look in compat.c. The same is true for
OpenSSH releases where you need to look at the of the other secure shell
vendors source implementations.

For myself, I do NOT want to see the feature disappear just because a
system administrator wants to obfuscate the version of secure shell they
are using on their systems and feel doing so in a config file is the
best thing to do.

It is always better to keep up-to-date with the latest release whenever
possible.

Note: I expect to see a fair amount of breakage when the mandatory to
implement options are no longer enabled by default:

REQUIRED [RFC4253]
* ssh-dss (with 1024-bit keys and sha1 hashes)
* diffie-hellpman-group1-sha1
* diffie-hellman-group14-sha1
* 3des-cbc
* hmac-sha1

RECOMMENDED [RFC4253]
* ssh-rsa (with sha1 hashes)
* aes128-cbc
* hmac-sha1-96

I expect to see a LOT of implementations not having ssh-dss,
diffie-hellpman-group1-sha1, or 3des-cbc enabled by default in the near
future.

Be safe, stay healthy,
-- Mark
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On Tue, 16 Jun 2020, bo0od wrote:

> maybe its useful but on the other hand its bad decision if user want to hide
> it in order to avoid bots attacks for vulnerable versions (for surely it
> should be left not updated for long time BUT still optional setting is
> preferable for the user to choose hide it or not)

I think you're misunderstanding how attacks work. Trying 10000 different
exploits against your sshd because the attacker doesn't know the version
is not perceptibly more difficult than trying a single one.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev