[PLUG] Public SSH server configs

[Cryptomonkeys.org]

Sure. and that would be fine for all the people who aren’t malicious.


> On Apr 11, 2017, at 7:53 PM, Tom <tomas.kuchta.lists at gmail.com> wrote:
> 
> That is what contracts, firewalls, monitoring and compliance tools are
> for.
> If you do not trust users to start a process or use network ports -
> disable their login and physical access to computers.
> There are so many avenues which can be exploited beside ssh or any
> myriad of other server processes.
> Tomas
> On Tue, 2017-04-11 at 18:41 -0500, Cryptomonkeys.org <http://cryptomonkeys.org/> wrote:
>> On Apr 10, 2017, at 2:17 PM, Jim Garrison <jhg at jhmg.net> wrote:
>>> 
>>> On 4/10/2017 8:22 AM, Paul Heinlein wrote:
>>>> I've got a CentOS 7 VM running off in the cloud. It exposes SSH
>>>> on 
>>>> port 22 to the world. I've thought about moving it to an
>>>> alternate 
>>>> port, and may someday do so, but in the meantime I've tried to
>>>> keep up 
>>>> with best practices for sshd configuration.
>>>> 
>>>> I recently changed the KexAlgorithms setting, removing all 
>>>> key-exchange algorithms based on NIST curves. (Google variants of
>>>> "ed25519 nist ssh ecdh" for my reasoning.) Anyway, the new
>>>> setting:
>>>> 
>>>> KexAlgorithms curve25519-sha256 at libssh.org,diffie-hellman-group
>>>> -exchange-sha256
>>>> 
>>>> All of my machines (MacOS 10.12, CentOS 6, CentOS 7) can work
>>>> with 
>>>> this setting, so I don't have to worry about infinite backward 
>>>> compatibility.
>>>> 
>>>> One interesting and unintended result of this change is that many
>>>> SSH 
>>>> scanners will fail while trying to negotiate a key exchange. The
>>>> log 
>>>> entries are short and sweet:
>>>> 
>>>> sshd[18200]: fatal: Unable to negotiate a key exchange method
>>>> [preauth]
>>>> 
>>>> The number of scanners that even get through to the stage of
>>>> 'Invalid 
>>>> user' has dropped from a couple hundred per day to less than a
>>>> dozen.
>>>> 
>>>> Everyone's situation is different, of course, and this alteration
>>>> may 
>>>> not work in your environment -- but you may find it worthwhile
>>>> raising 
>>>> the bar on the KexAlgorithm, Ciphers, and MACs in your
>>>> sshd_config, 
>>>> especially if your SSH daemon is exposed to the world at large.
>>>> 
>>> 
>>> I've been running sshd on a non-standard port above 5000 for about
>>> 7
>>> years, on various hosting services, both real hardware and more
>>> recently
>>> virtual machines.  I think in 7 years I've seen only **two**
>>> attempted
>>> connections and I think those were from someone just doing a
>>> portscan,
>>> as the log messages were one-offs and not repeated.
>>> 
>>> There has never been any effort from anybody to actually connect.
>>> 
>> Any thoughts on the consequences of arbitrary users being able to run
>> their own sshd on port numbers >1024? Would that mean that if
>> somebody got access to your machine, they could replace the listening
>> sshd with their own?
>> 
>> --
>> Louis Kowolowski                                
>> louisk at cryptomonkeys.com
>> Cryptomonkeys:                                   
>> http://www.cryptomonkeys.com/ <http://www.cryptomonkeys.com/> <http://www.cryptomonkeys.com/ <http://www.cryptomonkeys.com/>>
>> 
>> 
>> 
>> _______________________________________________
>> PLUG mailing list
>> PLUG at lists.pdxlinux.org <mailto:PLUG at lists.pdxlinux.org>
>> http://lists.pdxlinux.org/mailman/listinfo/plug <http://lists.pdxlinux.org/mailman/listinfo/plug>
> _______________________________________________
> PLUG mailing list
> PLUG at lists.pdxlinux.org <mailto:PLUG at lists.pdxlinux.org>
> http://lists.pdxlinux.org/mailman/listinfo/plug <http://lists.pdxlinux.org/mailman/listinfo/plug>
--
Louis Kowolowski                                louisk at cryptomonkeys.com
Cryptomonkeys:                                   http://www.cryptomonkeys.com/ <http://www.cryptomonkeys.com/>