<div dir="ltr"><div class="gmail_default" style="font-size:small">Thanks everyone for the useful links and comments. I decided to go with port 443 since that was already open to the world, meaning I did not need to open an additional port.</div>
<div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">I was happy to note that enabling password logins did not stop my ssl-based logins from working on the same server. I was worried it might be an either/or scenario. Unfortunately, for the service I'm setting up I had to provide a password-based login. I set up a restricted user for this purpose.</div>
<div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Will monitor things and see what kind of hits I get on that server. Hopefully the problem goes away or is significantly reduced by this. If I still see lots of hits then I guess I'll just have to go back to denyhosts which seems to do a great job of nailing things down. Of course, I'd rather not have the hits at all.</div>
<div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">cheers</div><div class="gmail_default" style="font-size:small">ed</div></div><div class="gmail_extra"><br><br>
<div class="gmail_quote">On Mon, Feb 17, 2014 at 9:37 AM, JD <span dir="ltr"><<a href="mailto:jdp@algoloma.com" target="_blank">jdp@algoloma.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Securing ssh:<br>
<a href="http://blog.jdpfu.com/2011/08/23/securing-ssh-connections-and-blocking-failures" target="_blank">http://blog.jdpfu.com/2011/08/23/securing-ssh-connections-and-blocking-failures</a><br>
<br>
The short version is:<br>
* only allow key-based logins, never passwords<br>
* use denyhosts or fail2ban<br>
* change to a non-default port (any will do) - use port translation at the<br>
router to make life easier, NOT on the server itself.<br>
* do not allow direct root logins over ssh, even on the LAN.<br>
<div class="im HOEnZb"><br>
On 02/17/2014 08:51 AM, Lightner, Jeff wrote:<br>
> The reason why changing the port drops hits to near zero even if someone is doing a port scan is that the port scan doesn't tell them the port is ssh - just that it is open. Of course doing a telnet to an open port might reveal that..<br>
><br>
> The fail2ban idea is a good one. So is using the high number but you CAN do nmap for high numbers - most people just don't. Security is all about hardening so the bad guys move on to easier targets. Nothing is really going to stop the determined folks specifically targeting you but it will keep out most of the hit and run types and script kiddies.<br>
<br>
</div><div class="HOEnZb"><div class="h5">_______________________________________________<br>
Ale mailing list<br>
<a href="mailto:Ale@ale.org">Ale@ale.org</a><br>
<a href="http://mail.ale.org/mailman/listinfo/ale" target="_blank">http://mail.ale.org/mailman/listinfo/ale</a><br>
See JOBS, ANNOUNCE and SCHOOLS lists at<br>
<a href="http://mail.ale.org/mailman/listinfo" target="_blank">http://mail.ale.org/mailman/listinfo</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr">Edward Holcroft | Madsen Kneppers & Associates Inc.<br>11695 Johns Creek Parkway, Suite 250 | Johns Creek, GA 30097<br>O (770) 446-9606 | M (770) 630-0949</div>
</div>
<br>
<span style="font-family:arial"><font size="2">MADSEN, KNEPPERS & ASSOCIATES USA, MKA Canada Inc. WARNING/CONFIDENTIALITY NOTICE: This message may be confidential and/or privileged. If you are not the intended recipient, please notify the sender immediately then delete it - you should not copy or use it for any purpose or disclose its content to any other person. Internet communications are not secure. You should scan this message and any attachments for viruses. Any unauthorized use or interception of this e-mail is illegal.</font></span>