A comparatively stronger & safer & secured sshd_config for SSH Server

sshd.conf

# Created by atErik, tErik. 
# Copyright 2011-2015 atErik. 
# a4t4erik AT out4look dot co4m, a4t4erik0 AT 4gmail dot co4m
# (Remove all prev & above "4"). 
# Released under GPL (GNU Public License).
# 
# 
# 1st created & used on 2011. 
# Improved and changed, when necessary. 
# 1st released to public under GPL on March 6th, 2015. 
# Last edited, on March 8, 2015.
# 
# 
# 
# 
# BE ALERT: that, the terms/words "Stronger" & "Safer" always changing
# over time.  What is NOW stonger & safer, MAY NOT BE TOMORROW,
# and there are hidden+secret operations, which may also be able to
# "weaken" or have already "practically"-"Broken" it. So stay TWO STEPS
# ahead.
# Use very(1) very(2) strong stuff, so it remains protected for at-least
# some good amount of time, and "strong" stuff also makes it harder +
# COSTLIER for those who breaks or weakens stuff. 
# Making (bad-person's & bad-group's) decryption (objectives), more harder
# to do and more costlier to do, is my + our + this file's objective.
# 
# 
# 
# 
# Lines which starts/begins with the # (hash) symbols, are disabled + inactive + comment lines.
# Other lines are active configuration command option lines.
# 
# 
# 
# 
# I have added more sections or config options from:
# various sites, books: 
# http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man5/sshd_config.5?query=sshd_config
# http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man5/ssh_config.5?query=ssh_config
# https://www.debian.org/doc/manuals/securing-debian-howto/ch-sec-services.en.html 
#  above webpage info is released under MIT expat License, and/or, GPL2+.
# https://stribika.github.io/2015/01/04/secure-secure-shell.html 
#  above article's author has released it on github.
# https://wiki.mozilla.org/Security/Guidelines/OpenSSH 
#  above article is releaed under Mozilla Public License.
# https://wiki.mozilla.org/Security/Key_Management
# http://undeadly.org/cgi?action=article&sid=20080220110039
# https://wiki.archlinux.org/index.php/Ssh




# IN YOUR SYSTEM, THIS FILE PROBABLY KNOWN AS "sshd_config".
# And use that name, what your-system prefers.
# The "d" after "ssh", means "daemon", means "server", "service provider", etc.
# 
# 
# This config settings are for securing OpenSSH server (sshd) side. 
# /etc/ssh/sshd_config <-- make backup 1st, then copy-paste from here.
# 
# 
# For securing SSH Client/user (ssh) side, see below webpage: 
# URL: 
# Also apply ssh-client side config, in server-side ssh-client, so that
# client oriented connections are also by default secured.
# /etc/ssh/ssh_config <-- make backup 1st, then copy-paste from above URL.
# 
# 
# 
# 
# Usage of PuTTY, a ssh client, is not recommended -- atErik. 
# Windows users usually prefers PuTTY.  Instead use, openssh client
# located inside: Cygwin, or MSYS2, or Chocolatte <-- these package
# managers allow to download & use various unix/linux/win32 etc packages
# on windows.




# Use "fail2ban" or "sshguard" to monitor for brute force attacks, and ban
# brute forcing IPs accordingly.
# https://wiki.archlinux.org/index.php/Fail2ban 
# https://wiki.archlinux.org/index.php/Sshguard <-- i would go with this --atErik.
# 



# TCP port to listen-from/bind-to: 
# You must change port "22" into a different (listen) port, preferably above
# 1023 but below 65535, and make sure your chosen port is not conflicting with
# other server daemons/software, which are sharing the same (internet routable)
# IP address.
Port 22


# To bind-to/listen-from all interfaces: (Not recommended -- atErik).
# ListenAddress 0.0.0.0
# Specify your specific internet-routable or network-interface's
# IP address:
ListenAddress 192.168.0.20
# This format of IP-adrs:port can alse be used: 
# ListenAddress 192.168.0.20:22
#    ListenAddress host|IPv4_addr|IPv6_addr
#    ListenAddress host|IPv4_addr:port
#    ListenAddress [host|IPv6_addr]:port


# Force SSHv2 Protocol, as weaknesses are found in SSHv1.
Protocol 2


# ServerKeyBits : defines the number of bits in the ephemeral protocol
# v1 server key. The minimum value is 512, and the default is 1024.
#ServerKeyBits 16384


# HostKeys for SSH protocol version 2.
# system wide.
# There is no latency difference between RSA-4096 or ED25519.
HostKey /etc/ssh/ssh_host_ed25519_key
HostKey /etc/ssh/ssh_host_rsa_key
## HostKey /etc/ssh/ssh_host_dsa_key
## HostKey /etc/ssh/ssh_host_ecdsa_key
# 
# In SSH server, Remove/DELETE ALL unused/other keys. And generate ONLY
# one large RSA key and one Ed25519 key. Some system's init scripts may
# recreate unused keys, So for more security, make sure to remove all
# ssh-keygen commands from your system's init script.
#   cd /etc/ssh
#   rm ssh_host_*key*
#   ssh-keygen -t ed25519 -f ssh_host_ed25519_key < /dev/null
#   ssh-keygen -t rsa -b 16384 -f ssh_host_rsa_key < /dev/null
# To create a SSH key (in client/user side) that is based on 
# curve25519-sha256 (ECDH over Curve25519 with SHA2) or RSA, then
# please find in above, a url/webpage for "ssh_config".


# HostCertificate : specifies a file containing a public host certificate.
# The certificate's public key must match a private host key already specified
# by HostKey (see above). The default behaviour of sshd is not to load any
# certificates.


# PubkeyAuthentication : specifies whether public key authentication is allowed.
# Default is “yes”. For SSH v2 only.


# PubkeyAcceptedKeyTypes : specifies the key types that will be accepted for
# public key authentication as a comma-separated pattern list. The default “*”
# will allow all key types. The -Q option of ssh may be used to list supported
# key types.


# UsePrivilegeSeparation : specifies whether sshd separates privileges by
# creating an unprivileged child process to deal with incoming network traffic.
# After successful authentication, another process will be created that has
# the privilege of the authenticated user. The goal of privilege separation
# is to prevent privilege escalation by containing any corruption within
# the unprivileged processes. The default is “yes”. If UsePrivilegeSeparation
# is set to “sandbox” then the pre-authentication unprivileged process is
# subject to additional restrictions, and where possible kernel sandbox
# mechanisms are used.
#UsePrivilegeSeparation yes
UsePrivilegeSeparation sandbox
# kernel sandbox: Systrace on OpenBSD, Seccomp on Linux, seatbelt on MacOSX/Darwin,
# rlimit elsewhere.


# Deny all other users besides the following specific users.
# Allow only (very few) non-root user(s) to have login access.
# And if right person/user need to use the root account, then
# that user can issue: su - root (command, to use root account)
# and enter correct password:
# Create a user, (do not use exact name "adminuser" what is shown below),
# before using this config file, or else you may be locked out
# of SSH access.
AllowUsers adminuser


# UseLogin : specifies whether "login" is used for interactive login sessions.
# Default is “no”. Note that "login" is never used for remote command execution.
# Note also, that, if this is enabled, "X11Forwarding" will be disabled because
# "login" does not know how to handle "xauth" cookies. If "UsePrivilegeSeparation"
# is specified (see above), it will be disabled after authentication.
UseLogin no


# Subsystem : configures an external subsystem (e.g. file transfer daemon).
# Arguments should be a subsystem name and a command (with optional arguments)
# to execute upon subsystem request. The command sftp-server implements the
# “sftp” file transfer subsystem. Alternately the name “internal-sftp”
# implements an in-process “sftp” server. This may simplify configurations
# using ChrootDirectory to force a different filesystem root on clients.
# By default no subsystems are defined for v2, and this works with only v2.
##Subsystem      sftp    /usr/libexec/sftp-server
Subsystem       sftp    internal-sftp
# SCP has some disadvantages, so we will use SFTP. -- atErik.


# GatewayPorts : specifies whether remote hosts are allowed to connect to ports
# forwarded for the client. By default, sshd binds remote port forwardings to
# the loopback address. This prevents other remote hosts from connecting to
# forwarded ports. GatewayPorts can be used to specify that sshd should allow
# remote port forwardings to bind to non-loopback addresses, thus allowing other
# hosts to connect. The argument may be: “no” to force remote port forwardings to
# be available to the local host only. And “yes” forces remote port forwardings
# to bind to the wildcard address. And “clientspecified” allows the client to
# select the address to which the forwarding is bound. The default is “no”.
#GatewayPorts no
GatewayPorts no


# PermitOpen : Specifies destinations to which TCP port forwarding is permitted.
# The forwarding specification must be one of the following forms:
#    PermitOpen host:port
#    PermitOpen IPv4_addr:port
#    PermitOpen [IPv6_addr]:port
# Multiple forwards may be specified by separating them with whitespace.
# An argument of “any” can be used to remove all restrictions and permit any
# forwarding requests. An argument of “none” can be used to prohibit all
# forwarding requests. By default all port forwarding requests are permitted.
# For example, if you want your users be able to connect-with & use ONLY server's
# local dns service & local znc-irc proxy service & local HTTPS proxy server,
# then: 
#PermitOpen 127.0.0.1:53 127.0.0.1:8443 127.0.0.1:6697 


# PermitTunnel : specifies whether tun device forwarding is allowed.
# The argument must be “yes”, “point-to-point” (layer 3), “ethernet” (layer 2),
# or “no”. Specifying “yes” permits both “point-to-point” and “ethernet”.
# The default is “no”. Independent of this setting, the permissions of the
# selected tun device must allow access to the user
#PermitTunnel no


# PermitTTY : specifies whether "pty" allocation is permitted. Default is “yes”.
# pty = pseudo terminal driver. The "pty" driver provides support for a device-pair
# termed a "pseudo terminal". A pseudo terminal is a pair of character devices,
# a "master" device and a "slave" device. The slave device provides to a process
# an interface identical to that described in "tty".


# Client timeout automatically, if no data activity for 5 minutes = 300 seconds: 
#ClientAliveInterval 0  # (default)
ClientAliveInterval 300


# ClientAliveCountMax : sets the number of client alive messages (see above)
# which may be sent without sshd receiving any messages back from the client.
# If this threshold is reached while client alive messages are being sent,
# sshd will disconnect the client, terminating the session.
# Usage of client alive messages is very different from TCPKeepAlive (below).
# The client alive messages are sent through the encrypted channel and therefore
# will not be spoofable. The TCP keepalive option enabled by TCPKeepAlive is
# spoofable. The client alive mechanism is valuable when the client or server
# depend on knowing when a connection has become inactive.
# The default value is 3. If ClientAliveInterval (see above) is set to 15, and
# ClientAliveCountMax is left at the default, unresponsive SSH clients will
# be disconnected after approximately 45 seconds. This option is for SSH v2 only.
#ClientAliveCountMax 3
ClientAliveCountMax 1
# So, 300 x 1 = total 300 seconds. So after 300 seconds, conneciton will
# be disconnected, when there was no data activity during that period.


# Compression (delayed = enable compression only after authentication).
# choices: yes|no|delayed. 
Compression delayed


# FingerprintHash : specifies the hash algorithm used when logging key fingerprints.
# Valid options are: “md5” and “sha256”. Default is “sha256”.
FingerprintHash sha256


# Logging with "LogLevel" : Gives the verbosity level that is used when logging
# messages from sshd(8). The possible values are: QUIET, FATAL, ERROR, INFO,
# VERBOSE, DEBUG, DEBUG1, DEBUG2, and DEBUG3. The default is INFO. DEBUG and
# DEBUG1 are equivalent. DEBUG2 and DEBUG3 each specify higher levels of debugging
# output. Logging with a DEBUG level violates the privacy of users and is not
# recommended.
LogLevel INFO
# SyslogFacility : gives the facility code that is used when logging messages
# from sshd. The possible values are: DAEMON, USER, AUTH, LOCAL0, LOCAL1,
# LOCAL2, LOCAL3, LOCAL4, LOCAL5, LOCAL6, LOCAL7. The default is AUTH.
SyslogFacility AUTH


# Authentication must happen within 30 seconds, default is 120: 
LoginGraceTime 30


# Disable direct root user SSH access: 
PermitRootLogin no
# Deny access if empty passwords are used: 
PermitEmptyPasswords no


# MaxAuthTries : Specifies the maximum number of authentication attempts permitted
# per connection. Once the number of failures reaches half this value, additional
# failures are logged. The default is 6.
MaxAuthTries 3


# StrictModes : specifies whether sshd should check file modes and
# ownership of user's files and home directory permissions, before
# accepting/allowing login/access. Note that this does not apply to
# "ChrootDirectory", whose permissions and ownership are checked
# unconditionally.
StrictModes yes


# Public key authentication & Password authentication
# Two-Factor Authentication for OpenSSH v6.2+
RSAAuthentication yes
PubkeyAuthentication yes
PasswordAuthentication yes
AuthenticationMethods publickey,password
# AuthenticationMethods publickey,keyboard-interactive


# Change this depending on where your authorized_keys file is
# Use below line which has %u to use correct file, when your home
# directory is encrypted: 
# AuthorizedKeysFile /etc/ssh/keys/%u/authorized_keys
# If you are not using encrypted home directory, then use below: 
AuthorizedKeysFile /etc/ssh/keys/authorized_keys




# In below, I HAVE COPIED+BORROWED SECTIONS & SENTENCES from various other
# authors & writers FROM DIFFERENT WEBSITES & BOOKS, and (slightly) modified
# sometime where it was necessary.
# 
# 
# KNOWLEDGE FOR WISER+ALERT PERSON+GROUPS: 
# 
# This is year 2015 AD. <-- read it one more time.
# Check in top side, when (what DATE) this file was last optimized for ?
# DO NOT TRUST THIS CONFIG FILE, IF IT IS OLDER THAN 12 or 18 MONTHS.
# Do not ever use MD5, SHA1: as these are already theoritically and
# also practically, broken/cracked, very long time ago.
# MD5 hashing takes under a second to break, with current/regular
# computers. SHA1 hashing takes around 10 minutes to break, using only
# two GPU based cluster/cloud computers.
# SHA2, like SHA-256, may be already practically broken, i'm not sure yet.
# SHA2, like SHA-512, probably not going to be broken practically very soon.
# ECDSA/NIST cannot be trusted, as NIST have already implemented backdoor
# in few of their developed technologies: https://projectbullrun.org/dual-ec/vulnerability.html 
# ECDHE is still fine, as it uses PFS.
# AES is theoritically already broken. AES-256 may be not have been broken
# practically yet.
# AES-128 probably broken practically by NSA in 2010 or 2012, so avoid
# using, if possible. 
# 
# BECAREFUL, DO NOT DO STUFF THAT INVOLVES SAVING SOMETHING IN GOOGLE, AND
# DO NOT USE A PROGRAM OR LIBRARY SOFTWARE OR HARDWARE MADE BY GOOGLE OR
# CONTRIBUTED BY GOOGLE DEVELOPERS.
# GOOGLE, Inc was created with USA military+CIA funds, and then more funds
# and more people came into Google board members, from various areas of USA
# CIA+NSA, and from other military or secret services, and from other military
# or secret service related intelligence service provider corporations.
# https://en.wikipedia.org/wiki/Criticism_of_Google#Potential_for_data_disclosure 
# ALWAYS CHECK, EACH ENCRYPTION RELATED TECHNOLOGY COMPANY/CORPORATION,
# CONTROLLED & FUNDED BY WHOM, WHO ARE SHARE-HOLDERS & FOUNDERS & BOARD
# MEMBERS, WHAT IS THEIR PHILOSOPHY AND IDEOLOGY, WHAT EXACT AREA/OFFICE
# OR COMPANY THEY WORKED/PARTICIPATED BEFORE, IN WHICH OTHER CORPORATIONS
# THEY ARE PARTICIPATING NOW.
# 
# USE COMMON SENSE : PEOPLES OR GROUPS WHO DO NOT RESPECT IN PEOPLE'S
# PRIVACY OR PROPERTY, AND VIOLATING CONSTITUTION & OTHER FUNDAMENTAL
# LOCAL & INTERNATIONAL RIGHTS, CIVIL LIBERTIES, ETC, THESE TYPE OF
# PEOPLE OR GROUPS WILL NEVER MAKE OR DO SOMETHING THAT WILL TRULY HELP
# OR WORK IN SUPPORT OF PRIVACY, THESE TYPE OF PEOPLE OR GROUPS WILL ALWAYS
# KEEP BACKDOORS+BUGS+VULNERABILITIES, THEY WILL DO STUFF WITHOUT TAKING
# DIRECT VOTE FROM PEOPLE, OR STEAL VOTE, OR THEY WILL OBTAIN SUPPORT BY
# USING MONEY OR BY THREAT OR OTHER INTIMIDATIONS, OR BY KEEPING INDIVIDUAL
# & MAJORITY AMOUNT OF PEOPLE, LESS-INFORMED OR MIS-INFORMED ON, WHAT IS
# OR ARE ACTUALLY GOOD OR BETTER IN LONG RUN, FOR MAJORITY AMOUNT OF PEOPLE,
# AND FOR THE COUNTRY, AND FOR THE WORLD.
# Current system is rigged so much, that, not only inside USA, but all
# over the world, group of elite people are controlling other people &
# controlling & owns various resources. Only 84 person, controls & owns
# 45% resources of entire Earth/World.
# 
# When we go outside of our home, into civilized society, then we COVER/WRAP
# our body with CLOTH/DRESS, because it not only creates a layer of extra
# protection for us from various harmful things (harmful sun rays, harmful
# people, harmful microbes), and it is also a moral tool, to create separation
# between parents & childs & outsiders & insiders, etc.
# When we send (snail) mail outside (using Post-Office), we COVER/WRAP our
# message with ENVELOP so that unknown person/peoples on the way, cannot
# over-write or modify something, so our message remains intact.
# The "CLOTH" and "ENVELOPE" are equivalent to "ENCRYPTION" in Internet
# aka cybersapce.
# Removing someone's cloth from someone's body, or tearing-up or un-wrapping
# an envelope, are federal punishable CRIME, such acts are massive violations
# of privacy rights and civil liberties.
# 
# If someone or somegroup or some-ENTITY (for example, like: NSA, GCHQ) REALLY
# cares about protecting & SECURING citizens & residents & people, from HARMFUL
# hackers or person or entities or from other nation's spying entities, etc,
# WHO DEVELOPS & DEPLOY HARMFUL exploits,attacks,malware,services,products etc,
# then the ENTITY WHO REALLY CARES ABOUT PEOPLE'S SAFETY & SECURITY, would have
# made one of the BEST ANTI-VIRUS + ANTI-MALWARE + ANTI-SPYWARE, but has any one
# of these entities done anything like that ? ? ? 
# Answer is: NO.  Instead these ENTITIES have created BACKDOORS in almost every
# key, junction, hub points and in PKI (public key infrastructure) cryptography,
# and as a result harmful hackers or entities, can now easily find backdoors (and
# allowed to find backdoors), and then harmful hackers/crackers deploy more attacks,
# exploits, malware, spyware, virus, trojan, etc toward citizens, residents, people,
# and other competitor companies. 
# When such attacks occur, then NSA/GCHQ type of entities & their supporters
# spread news that people needed NSA/GCHQ to protect from such harmful hackers.
# NEWS do not say, harmful hacker actually using backdoor embedded+created by
# NSA/GCHQ for these attacks.
# So its a circle strategy: create backdoors, release backdoors info, and wait
# for when someone uses those backdoors, then blame them, (instead of blaming
# NSA/GCHQ), and ask for more government fund for NSA/GCHQ, and prolong staying
# in NSA/GCHQ job.
# 
# For example, NASA (National Aeronautics and Space Administration ) with its
# BILLIONS OF US-DOLLARS BUDGET/FUNDINGS, and WITH HELP FROM OTHER SCIENTISTS
# FROM all around WORLD, has at-least made some rocket & satellite technologies
# that does benefits us daily, (for example, like: GPS (global positioning system),
# Weather forecasting systems, understanding changes in climate+weather, etc),
# even though they are wasting lots of money which could have been better used
# for other more necessary areas. 
# But what good anti-virus or good anti-spyware or good operating -system
# or a GOOD "SECURITY" TOOL has NSA (Natinal "SECURITY" Agency) made to "secure"
# & "protect" citizens, residents, people ? ? ?   Answer is: NONE , NADA , ZERO !!! 
# Sometime even military like entity, with massive (unnecessary) budget/fundings
# from government, and with help from other groups, at-least sometime makes &
# improves some good (non-human killing) & benefitial technologies, like: missile
# shield defense, or nuclear power reactor/generator, etc, which does benefit+help
# citizens, residents, peoples.
# BUT WHAT GOOD THING/TECHNOLOGY HAS NSA MADE ? ? ?  Answer is: NOTHING !!! WHY ? !!!
# NSA (Natinal "SECURITY" Agency) (which also HAS BILLIONS OF US-DOLLARS EACH
# YEAR FUNDINGS, THE HIGHEST AMOUNT OF FUNDING IN ENTIRE WORLD, FOR SUCH AGENCY
# or ENTITY) or similar entities, which has thousands of employees & scientists
# and almost unlimited resources, HAS IT MADE ANY open source SOFTWARE, like a
# LINUX operating system, that can PROTECT & "SECURE" citizens, residents from
# harmful hackers, entities, and which does not SPY and does not allow OTHERS
# to SPY, and which does not violate USA-BILL-OF-RIGHTS (for example, 4TH AMMENDMENT)
# CONSTITUTION ? ? ?   Answer is: NO/NONE !!!  Instead (with its massive amount
# of fundings) it has added & embedded more spyware (spying-codes) and backdoors,
# in most software, phones, hardwares, etc, THAN ANY OTHER NATION in entire
# earth/world !!! 
# CONCLUSION: In Overall, NSA (Natinal "SECURITY" Agency) has failed do its
# "SECURITY" JOB.
# NSA which has vast amount of employees, failed to do the JOB of their own
# middle-name, from above examples & questions & facts, we can clearly see that
# these employees have not done any real good things, so its an overall BAD
# entity, wasting money, in which employees just want to get money from their
# job without actually doing anything really helpful for people.
# It's middle-name has become "SURVEILLANCE", instead of "SECURITY".
# EMPLOYEE (PUBLIC SERVANTS) IN NSA/similar, MUST REALIZE, THEY MUST REALLY SERVE
# THEIR COUNTRY'S PEOPLE, THEY MUST CHANGE CURRENT BAD PRACTICES, and really pay
# attention on doing their "SECURITY" JOB, which is to provide & maintain 
# "SECURITY", it must stop adding spyware & backdoors in software, phone, 
# hardware, etc,
# AND it MUST START TO REALLY RESPECT & LIKE USA-BILL-OF-RIGHTS, civil-liberties,
# etc.
# 
# If we TAKE VOTE DIRECTLY FROM EACH PERSON today, and if voting machines &
# systems are not rigged, then NSA type of agencies WILL FOR SURE LOSE SUPPORT.
# Its not even created with citizen's or resident's or people's voted permission.
# It did not even have any official approval for surveillance, during 2006
# to 2012.
# 
# Hitler used such agency to violate people's rights & civil-liberties.
# People who support it's current activities, also talks just like Hitler's
# spy or surveillance master(s).
# 
# USA'S FOUNDING FATHERS REALIZED, UNDERSTOOD, LEARNED ABOUT THESE TYPE OF
# VIOLATIONS AND ABUSES FROM THEIR OPPRESSORS & VIOLATORS, THATS WHY THEY
# FOUGHT, DISCUSSED, VOTED, AND VERY CLEARLY SPECIFIED IN USA-CONSTITUTION,
# WHAT ARE ALLOWED AND WHAT ARE NOT-ALLOWED.
# 
# ANY ENTITY WHO ACTS LIKE WHAT NSA DOING FOR LAST 13 YEARS, (now its March 2015),
# MUST BE AVOIDED,
# WE/PEOPLE MUST DEVELOP SKILLs & PROTECTIONs & DO SECURED PRACTICES AGAINST
# SUCH SOCIOPATH GROUPS OR ENTITIES, TO PROTECT & SECURE OURSELVES, BECAUSE
# SUCH SOCIOPATHS WILL NOT HELP US, TO PTOTECT & SECURE OURSELVES, OR OUR
# PROPERTIES, OR OUR EFFECTS.




# Message Authentication Code = MAC. MAC algorithms. The MAC algorithm is
# used in protocol SSH v2 for data integrity protection.
# Only allow SHA2-512 Hash: 
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-512
# If you also want to use PuTTY, which yet does not support SHA-512: 
# MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512,hmac-sha2-256
# Even more options:
# MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-ripemd160-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,hmac-ripemd160,umac-128@openssh.com


# Ciphers: Only use secure AES-256. It is probably still practically secure.
# CBC has weakness so avoid, instead use CTR. 
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes256-ctr
# But to support different clients you may also use CBC: 
# Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr


# Key Exchange (KEX) algorithms : specifies available KEX algorithms.
# use Elliptic Curve Diffie-Hellman (ECDH/ECDHE), or DH/DHE.
# Do not use ECDSA/NIST: may have more backdoors & untrustworthy.
KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256
# If you also want to allow users of PuTTY & similar clients, which supports upto DH-SHA-256, then: 
# KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256
# NIST may have backdoor & untrustworthy, so below "nist521" should not be used: 
# KexAlgorithms ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256


# Use only stronger & safer Key Algos (Do not use ECDSA/NIST, has backdoor): 
#HostKeyAlgorithms ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp521
# If you want to alow various algo based connections, then use below:
# HostKeyAlgorithms ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp256-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ecdsa-sha2-nistp521,ecdsa-sha2-nistp384,ecdsa-sha2-nistp256




# RekeyLimit : specifies the maximum amount of data that may be transmitted before
# the session key is renegotiated, optionally followed a maximum amount of time
# that may pass before the session key is renegotiated.
# Default value for RekeyLimit is “default none”, which means that rekeying is
# performed after the cipher's default amount of data has been sent or received
# and no time based rekeying is done.
# Data size suffix: K, M, G. Time amount/duration suffix: S, M, H, D, W.
RekeyLimit 512M


# The ephemeral server key is automatically regenerated after this many seconds
# (if it has been used). The purpose of regeneration is to prevent decrypting
# captured sessions by later breaking into the machine and stealing the keys.
# The key is never stored anywhere. We will use half of default 3600.
# 1800 seconds is 30 minutes.
KeyRegenerationInterval 1800


# IgnoreUserKnownHosts : specifies whether sshd should ignore the user's
# ~/.ssh/known_hosts during "RhostsRSAAuthentication" or "HostbasedAuthentication".
# Default is “no”.
IgnoreUserKnownHosts yes


# IgnoreRhosts : specifies that ~/.rhosts and ~/.shosts files will not be used
# in RhostsRSAAuthentication or HostbasedAuthentication. But /etc/hosts.equiv
# and /etc/shosts.equiv are still used. Default is “yes”.
IgnoreRhosts yes


# PermitUserRC : specifies whether any ~/.ssh/rc file is executed. Default is “yes”.
#PermitUserRC yes


# Disable un-used authentication schemes: 
# So that, unwated, unplanned, or un-approved things do not occur.
RhostsRSAAuthentication no
HostbasedAuthentication no
ChallengeResponseAuthentication no
KerberosAuthentication no
GSSAPIAuthentication no


# Disable PAM, if you are not using it to restrict OpenSSH even further: 
UsePAM no
# You can also restrict access to the ssh server using pam_listfile or
# pam_wheel in the PAM control file. For example, you could reject other
# users who are not in this approved list /etc/loginusers by adding below
# code line into this file /etc/pam.d/ssh 
# 	auth       required     pam_listfile.so sense=allow onerr=fail item=user file=/etc/loginusers
# To restrict users who are not from very specific subnets, use "pam_access" and
# add below line in this file /etc/security/access.conf
# 	-:localnetuser1 localnetuser2:ALL EXCEPT LOCAL .localdomain
# And add below codeline into /etc/pam.d/ssh after "account requiered pam_unix.so"
# 	account requiered pam_access.so


# You can also chroot users (using "libpam-chroot" so that, even if file
# transfer is allowed, they are limited to an environment which does not
# include any system files.


# If you want to restrict/limit access for a specific set of users, so
# that they can only do file transfers, and cannot have interactive
# shells: then in order to do this, you can either, option-1: disallow
# those specific users from login into the ssh server (as described above
# either through the configuration file or PAM configuration),
# or, option-2: give those specific users a restricted/limited shell
# access, by using "scponly" or "rssh" options (and use a different port
# number for such users), then those specific user's connection will have
# access to only very limited or very restricted set of commands, in that
# way, those specific users will not have remote execution priviledges,
# they will only have limited file+folder copy, move, etc permissions.
# Also see below articles:
# https://www.debian.org/doc/manuals/securing-debian-howto/ap-chroot-ssh-env.en.html


# X11 support: 
X11Forwarding no


# Don’t show Message of the Day (MOTD): 
PrintMotd no


# TCPKeepAlive : specifies whether the system should send TCP keepalive messages
# to the other side. If they are sent, death of the connection or crash of one
# of the machines will be properly noticed. However, this means that connections
# will die if the route is down temporarily, and some people find it annoying.
# On the other hand, if TCP keepalives are not sent, sessions may hang indefinitely
# on the server, leaving “ghost” users and consuming server resources. Default is
# “yes” (to send TCP keepalive messages), and the server will notice if the network
# goes down or the client host crashes. This avoids infinitely hanging sessions.
# To disable TCP keepalive messages, the value should be set to “no”.
# TCPKeepAlive (non-tunneled, disabled): 
TCPKeepAlive no


# Allow client side to pass locale environment variables: 
AcceptEnv LANG LC_*


# UseDNS : specifies whether sshd should look up the remote host name and check
# that the resolved host name for the remote IP address maps back to the very 
# same IP address. The default is “no”.
UseDNS yes
# If your server's internet routable IP-address does not have proper rDNS (reverse
# DNS) setup, that is, it does not matches with your server's host & domin name,
# then use "no".


# If you are setting up a restricted sftp server accesible via SSH tunnel,
# then, you should use "ForceCommand" and "ChrootDirectory" directives.
# Use "Match" directive to selectively restrict certain set of users only.
#Match user djm
#    ForceCommand internal-sftp
#    #ChrootDirectory /chroot/home/djm
#    ChrootDirectory /chroot/%h
# Above 3 lines will cause the user 'djm' to be chrooted to "/chroot/home/djm"
# directory at login, and the use of the in-process sftp server will be
# forced for all connections, so, user 'djm' will not be able to login
# interactively, or run arbitrary commands, so login will only be useful
# for sftp transfers.
# And to make the internal-sftp chroot work for user 'djm', add below two lines: 
#    #Subsystem      sftp    /usr/libexec/sftp-server
#    Subsystem       sftp    internal-sftp
# Create chroot: (change <user_name> with "djm" without double quotes) 
#    mkdir /chroot
#    mkdir -p /chroot/home/<user_name>
#    mkdir /chroot/home/<user-name>/bin  
#    cp -pr /bin/bash  /chroot/home/<user_name>/bin/.  
#    cp -pr /bin/ls    /chroot/home/<user_name>/bin/.  
#    cp -pr /lib64     /chroot/home/<user_name>/.


# Match : Introduces a conditional block. If all of the criteria on the Match
# line are satisfied, the keywords on the following lines override those set
# in the global section of the config file, until either another "Match" line
# or the end of the file is reached. If a keyword appears in multiple Match
# blocks that are satisfied, only the first instance of the keyword is applied.


# If you want to restrict a user in such way, that, that user is not allowed
# to access sftp (so user cannot transfer any file), and not allowed to gain
# shell access (so user cannot type or use other commands on the server), but
# you only want to allow usage of very specific network port based services,
# then below three lines will achieve that.
# Thanks to user "BasketCase" @ irc.freeonde.net #openssh for showing below 1st
# & 2nd line, i added 3rd line to give access to only znc irc proxy server:
#     Match User irc-proxy-user
#     ForceCommand /usr/sbin/nologin
#     PermitOpen 127.0.0.1:6697