Port Forwarding for a local SSH Server.

I have just finished setting up my home SSH server and It’s working nicely, all I need to do now is make it publicly available so I can access it when I’m on another network, now sounds simple enough right? Well I’m sure it is but I for some reason can not get it working for the life of me..

Here’s what I have got configured for the port forwarding in RouterOS (v6.47.9):

Chain: dstnat
Dst. Address: (my public IP address)
Protocol: 6 (tcp)
Dst. Port: 1024

Action: dst-nat
To Addresses: 192.168.1.125 (my SSH server IP)
To Ports: 22

What I want to do is login to my SSH server via my public IP address, essentially in my mind this would be done like so:

ssh (machine username)@(public IP address) -p 1024

Anyway, any help would be much appreciated.

(If required my sshd_config file is located below)

#      $OpenBSD: sshd_config,v 1.103 2018/04/09 20:41:22 tj Exp $
# This is the sshd server system-wide configuration file.  See
# sshd_config(5) for more information.
# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin
# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented.  Uncommented options override the
# default value.
Include /etc/ssh/sshd_config.d/*.conf
Port 22
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::
#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_ecdsa_key
#HostKey /etc/ssh/ssh_host_ed25519_key
# Ciphers and keying
#RekeyLimit default none
# Logging
#SyslogFacility AUTH
#LogLevel INFO
# Authentication:
#LoginGraceTime 2m
#PermitRootLogin prohibit-password
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10
#PubkeyAuthentication yes
# Expect .ssh/authorized_keys2 to be disregarded by default in future.
#AuthorizedKeysFile     .ssh/authorized_keys .ssh/authorized_keys2
#AuthorizedPrincipalsFile none
#AuthorizedKeysCommand none
#AuthorizedKeysCommandUser nobody
# For this to work you will also need host keys in /etc/ssh/ssh_known_ho>
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes

# To disable tunneled clear text passwords, change to no here!
#PasswordAuthentication yes
#PermitEmptyPasswords no
# Change to yes to enable challenge-response passwords (beware issues wi>
# some PAM modules and threads)
ChallengeResponseAuthentication no
# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no
# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes
#GSSAPIStrictAcceptorCheck yes
#GSSAPIKeyExchange no
# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM yes
#AllowAgentForwarding yes
#AllowTcpForwarding yes
GatewayPorts yes
X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes
#PermitTTY yes
PrintMotd no
#PrintLastLog yes
#TCPKeepAlive yes
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS no
#PidFile /var/run/sshd.pid
#MaxStartups 10:30:100
#PermitTunnel no
#ChrootDirectory none
#VersionAddendum none

# no default banner path
#Banner none
# Allow client to pass locale environment variables
AcceptEnv LANG LC_*
# override default of no subsystems
Subsystem sftp  /usr/lib/openssh/sftp-server
# Example of overriding settings on a per-user basis
#Match User anoncvs
#       X11Forwarding no
#       AllowTcpForwarding no
#       PermitTTY no
#       ForceCommand cvs server
PasswordAuthentication yes

/export hide-sensitive file=anynameyouwish

Have to see the config, just ensure you replace any public IPs with fake numbers/letters etc…

I see no reason to make the rule depend on that. As long as the connection attempt comes in on the right port, what does it matter what IP it comes in on?

This is true whether it’s the source of your immediate problem or not. Don’t make firewall rules more complicated than they have to be.


ssh (machine username)@(public IP address) -p 1024

>

Options have to come before the host name. The correct command is "ssh -p 1024 ..."

If this isn't it (and I'm pretty sure it is after having tested it here) then include "ssh -vvv ..." output.

And just in case you’re having problems while testing from within home LAN (and trying to ssh to your public address): you need to implement hairpin NAT for that.

Do you want it to catch also outgoing connections to port 1024? If not, and I assume you don’t, then you need to limit destination.

I come from the land of long DHCP leases on Internet routers, which some choose to treat as “nearly static” but which change juusst often enough that all the admins forget any rules they’ve set up against that IP by the time it changes on them again.

It’s better to say “in-interface=WAN”, “in-interface=ether1”, or similar, depending on your local interface list configuration.

Even if you have a static IP today, unless you also have an AS, if you change ISPs, you’ll have to abandon that IP on that change and get a new one. DNS fixes this up, but will you remember to update the firewall rules?

By the way, I’ve since considered the OP’s SSH command, and I’m now certain it’s wrong: where the option is now, it’ll be considered a command to the remote system, which will in all likelihood not know how to “-p 1024”. Even if it connects (i.e. by putting the correct port into ~/.ssh/config) it’ll bounce you back out, most likely with an error when the remote command doesn’t do anything useful.

Well, if you have in-interface(-list)=, it’s better. It’s not compatible with hairpin NAT, but if you’re sure that you don’t need that, it’s good enough. If you also need hairpin NAT and you don’t have static address, you can use dst-address-type=local, possibly with additional dst-address(-list)= if it’s for some port that you also need to use on router (e.g. 80 for WebFig). And you don’t need to update anything.

Here is an example to port forward a Wireguard port.
Mikrotik-PortForwarding.png
Just replace the Wireguard ports with TCP 22.
Firewall rule allows incoming TCP 22 traffic and NAT rule forwards this traffic to the local IP address.