HiddenSSH Config file, Cloud Firewall Single Node
Configured for running on a single node/server in cloud enviroment, with OpenSSH IP restrictions.
Note that this configuration works with public/private keys and not passowords.
Reasoning, Password authentication is very out dated method and has come to end of life long time ago but refuse to die because wide adaption.
Cloud-optimized SSHD config for single-node environments with IP-restricted user logins, hardened encryption, logging, and firewall integration.
#########################################################
# https://hiddenssh.com #
# #
# sshd_cloud_firewall_single_node #
# version 1.4 #
# Early version has bugs when it comes to IP blocking #
#########################################################
# Notes: if issues, run following commands.
# mkdir -p /run/sshd
# chmod 0755 /run/sshd
# chown root:root /run/sshd
# NETWORK
# -------
# If you want to change the port on a SELinux system, you have to tell
# SELinux about this change.
# semanage port -a -t ssh_port_t -p tcp #PORTNUMBER
#
Protocol 2
Port 22
AddressFamily inet
ListenAddress 192.168.0.1
# VPN if you are using VPN you need to listen on local address also
#ListenAddress 10.0.0.1
PermitTTY yes
TCPKeepAlive yes
# DEAMON
# -------
VersionAddendum HiddenSSH-cloud
PidFile /var/run/sshd.pid
# Encryption
# ----------
# The command "sshd -T | grep macs" shows the supported MAC algorithms
# aes256-cbc uses AES in cipher-block chaining (CBC) mode, which can be vulnerable to certain attacks if not used correctly.
# aes256-gcm@openssh.com uses AES in Galois/Counter Mode (GCM), which provides both encryption and authentication,
# making it resistant to certain types of attacks. However, it may not be as widely supported
# twofish256-ctr is a good option but not supported by all systems
# chacha20-poly1305@openssh.com is its performance. The ChaCha20 stream cipher is generally faster than AES, especially on systems without hardware s>
# Run /proc/cpuinfo to set the flags
# Use aes256-ctr if things break.
Ciphers aes256-gcm@openssh.com
# If you want to choose one MAC algorithm for the best security, hmac-sha2-512-etm@openssh.com would be the best choice.
MACs hmac-sha2-512-etm@openssh.com
# NIST P-curves are possibly back-doored by the U.S. National Security Agency.
# ecdh-sha2-nistp256, ecdh-sha2-nistp384, ecdh-sha2-nistp521
KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256
# Public key types accepted
# ssh-rsa is needed for password out in cloud password logins, because its the most common default method.
# rsa-sha2-512 makes life easy for MacOS people.
PubkeyAcceptedKeyTypes ssh-rsa,ssh-ed25519,rsa-sha2-512
RekeyLimit 4G 1h
Compression yes
# Logging
# -------
SyslogFacility AUTH
LogLevel info
# Hardening login
# ---------------
LoginGraceTime 2m
StrictModes yes
MaxAuthTries 5
MaxSessions 5
MaxStartups 10:30:100
ChallengeResponseAuthentication no
UseDNS yes
UsePAM yes
PermitRootLogin no
DenyGroups root
PermitEmptyPasswords no
DenyUsers root admin administrator user test guest webmaster backup ftp ssh postgres mysql oracle tomcat apache www-data git docker mail pi
ClientAliveInterval 0
ClientAliveCountMax 5
HostbasedAuthentication no
IgnoreUserKnownHosts no
ChrootDirectory none
# INFORMATION
# -----------
# Needed for: SCP
# Needed for: sshfs
Subsystem sftp /usr/libexec/openssh/sftp-server
# User Settings
# --------
# With this option set to "yes", users can set arbitrary environment variables that can potentially override system settings and be used to launch ma>
# or perform unauthorized actions. This can be especially dangerous if the user connecting via SSH has administrative privileges on the system.
PermitUserEnvironment yes
Match user user1,user2
Match all
PermitUserEnvironment yes
PasswordAuthentication no
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys .ssh/authorized_backup
#TrustedUserCAKeys /etc/ssh/certificate-auth/user1-hiddenssh-cert.pub
# WARNING
AllowAgentForwarding no
AllowTcpForwarding no
PermitTunnel yes
GatewayPorts no
# Firewall
# ---------
# Only allow a user to login, and with correct ip.# gateway
# Need to be set in SSH iptables chain
# Need to be set in /etc/hosts.allow
# Need to be set in sshd config AllowUsers
#
AllowUsers user1@192.168.0.10 user2@10.0.0.10
# Accept locale-related environment variables
# -------------------------------------------
AcceptEnv LC_IDENTIFICATION LC_ALL LANGUAGE
AcceptEnv XMODIFIERS
AcceptEnv hiddenssh oraclesecretkey oracleauthtoken cloudflaretoken openaikey
Iptables and firewall integration.
iptables -N ssh-ingress
iptables -A INPUT -j ssh-ingress
iptables -P INPUT DROP
iptables -A ssh-ingress -s 192.168.0.0/32 -d 192.168.0.1/32 -i Interface -p tcp -m tcp --dport 22 \
-m state --state NEW,RELATED,ESTABLISHED \
-m comment --comment "User1" -j ACCEPT
You need to match IPs in sshd_config and iptables,
because they work on different levels.
Iptables operates at the network/kernel level — it controls which source IPs can reach OpenSSH at all.
OpenSSH filters connections at the application level — it restricts which IPs each user is allowed to log in from.
Pay close attention to user1@ this part defines the user, rest defines the IP, this is specific for each user.
# Firewall
# ---------
# Need to be set in SSH iptables chain
AllowUsers user1@192.168.0.10 user2@10.0.0.10
Pay close attention to ssh-ingress chain, and Policy of the CHAIN: DROP
Chain INPUT (policy DROP)
target prot opt source destination
ACCEPT 0 -- 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED
ssh-ingress 2 -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:22
Chain OUTPUT (policy DROP)
target prot opt source destination
ACCEPT 0 -- 0.0.0.0/0 0.0.0.0/0 ctstate ESTABLISHED /* NEEDED for 2 way communication */
Chain ssh-ingress (1 references)
target prot opt source destination
ACCEPT all -- 192.168.0.0/32 anywhere ctstate NEW,ESTABLISHED /* User1 */
ACCEPT all -- 10.0.0.10/32 anywhere ctstate NEW,ESTABLISHED /* User2 */