openssh unix dev - Dec 2016 - Extend logging of openssh-server - e.g. plaintext password

I concur with Nico ? logging plaintext passwords is an extremely bad idea.

The tone of the poster also leaves much to be desired ? but I?ll hold my tongue
for now.
--
Regards,
Uri Blumenthal

On 12/18/16, 11:48, "openssh-unix-dev on behalf of Nico Kadel-Garcia"
<openssh-unix-dev-bounces+uri=ll.mit.edu at mindrot.org on behalf of nkadel
at gmail.com> wrote:

    On Sun, Dec 18, 2016 at 9:42 AM, Philipp Vlassakakis
    <philipp at vlassakakis.de> wrote:
    > What part of ?Password Authentication is disabled? do you not
understand?
    >
    >
    > Am 18.12.2016 um 11:21 schrieb Nico Kadel-Garcia <nkadel at
gmail.com>:
    >
    > On Sat, Dec 17, 2016 at 7:37 PM, Philipp Vlassakakis
    > <philipp at vlassakakis.de> wrote:
    >
    > Dear list members,
    >
    > I want to extend the logging of the openssh-server, so it also logs the
    > entered passwords in plaintext, and yes I know that this is a security
    > issue, but relax, Password Authentication is disabled. ;)
    >
    >
    > Oh, dear lord. What part of "a really bad idea and begging for
pure
    > abuse" is not clear about this idea? Simply setting up a fake
server
    > with a hostname similar to a common could encourage password
    > harvesting.
    >
    > It would be much safer to simply avoid activating debugging tools that
    > can be so abused.
    
    What part of "actively supporting honeypots is a bad idea"  is
unclear
    to you, sir? This kind of built-in feature can, and will, be used by
    malicious people to activate passphrase theft. By activating it
    directly in the source code, it also makes it that much more difficult
    to detect when someone can and has enabled such harvesting.
    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev at mindrot.org
    https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
    
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5211 bytes
Desc: not available
URL:
<http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20161218/b47ed2c5/attachment.bin>

Please accept my apologies. Sorry if my previous mails sound rude, it was not my
intention.

@Nico:
What do you mean with ?setting up a fake server? ?
Should I change my SSH-Port to a non-default port and install a SSH-Honeypot
like Kippo, which listens on Port 22 as my ?SSH-Honeypot-Password-Harvester? ?

With this solution i don?t have to modify the source code of the
openssh-server-package.

Regards,
Philipp
> Am 18.12.2016 um 18:05 schrieb Blumenthal, Uri - 0553 - MITLL <uri at
ll.mit.edu>:
> 
> I concur with Nico ? logging plaintext passwords is an extremely bad idea.
> 
> The tone of the poster also leaves much to be desired ? but I?ll hold my
tongue for now.
> --
> Regards,
> Uri Blumenthal
> 
> On 12/18/16, 11:48, "openssh-unix-dev on behalf of Nico
Kadel-Garcia" <openssh-unix-dev-bounces+uri=ll.mit.edu at mindrot.org on
behalf of nkadel at gmail.com> wrote:
> 
>    On Sun, Dec 18, 2016 at 9:42 AM, Philipp Vlassakakis
>    <philipp at vlassakakis.de> wrote:
>> What part of ?Password Authentication is disabled? do you not
understand?
>> 
>> 
>> Am 18.12.2016 um 11:21 schrieb Nico Kadel-Garcia <nkadel at
gmail.com>:
>> 
>> On Sat, Dec 17, 2016 at 7:37 PM, Philipp Vlassakakis
>> <philipp at vlassakakis.de> wrote:
>> 
>> Dear list members,
>> 
>> I want to extend the logging of the openssh-server, so it also logs the
>> entered passwords in plaintext, and yes I know that this is a security
>> issue, but relax, Password Authentication is disabled. ;)
>> 
>> 
>> Oh, dear lord. What part of "a really bad idea and begging for
pure
>> abuse" is not clear about this idea? Simply setting up a fake
server
>> with a hostname similar to a common could encourage password
>> harvesting.
>> 
>> It would be much safer to simply avoid activating debugging tools that
>> can be so abused.
> 
>    What part of "actively supporting honeypots is a bad idea"  is
unclear
>    to you, sir? This kind of built-in feature can, and will, be used by
>    malicious people to activate passphrase theft. By activating it
>    directly in the source code, it also makes it that much more difficult
>    to detect when someone can and has enabled such harvesting.
>    _______________________________________________
>    openssh-unix-dev mailing list
>    openssh-unix-dev at mindrot.org
>    https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
> 
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On Sun, Dec 18, 2016 at 12:26 PM, Philipp Vlassakakis
<philipp at vlassakakis.de> wrote:
> Please accept my apologies. Sorry if my previous mails sound rude, it was
not my intention.
>
> @Nico:
> What do you mean with ?setting up a fake server? ?
> Should I change my SSH-Port to a non-default port and install a
SSH-Honeypot like Kippo, which listens on Port 22 as my
?SSH-Honeypot-Password-Harvester? ?
>
> With this solution i don?t have to modify the source code of the
openssh-server-package.
>
> Regards,
> Philipp
By setting up a fake server, I mean scenarios like this.

* I have web server in my company with or without passphrase access
enabled called "www.example.com"
* I have dynamic DNS enabled, as well, for laptops.
* Some fool names their laptop "ww.example.com" in my local DNS,
* The new admin at work, unaware of this "we don't allow PassPhrase
based access", tries to log into "www.example.com".
* The new admin uses his password. Having difficulty logging into the
honeypot, he then tries to log in as root or other administrtive
accounts.
* The honeypoyt now has copies of the login names, and passphrases,
stored in cleartext, without having to modify a single line of their
OpenSSH source code or a single byte of their binary.
* Voila: stashed passphrases and login names for the deired
"www.example.com".

The possibilities, individually, may not seem to be high. But there
are so very many potential ways to abuse this it seems extremely wise
to enable at all, much less as a built-in feature.