4 ms·

fwiw, in the “Port” directive in sshd_config you can just add another port number declaration and SSHd will listen on both ports. Port 22 Port 80 M

by dijit 3y ago

fwiw, in the “Port” directive in sshd_config you can just add another port number declaration and SSHd will listen on both ports. Port 22 Port 80 Much cleaner than iptables magic; though I have done similar iptables redirects before it is almost always a bad idea. :)

sleepybrett 3y ago
Possible that this was a feature added after this event?
- dijit 3y ago
  possible, but I see recommendations along these lines going back to 2011 https://serverfault.com/questions/284566/configuration-for-multiple-port-ssh https://serverfault.com/questions/284566/configuration-for-m...
  - jrockway 3y ago
    I feel like the blink tag part of the story dates it to before 2011. (I just tested to see if blink tags still worked. It did not.)
    - fiddlerwoaroof 3y ago
      Unless it’s anonymized, Hurricane Jeanne dates it to 2004
      - btilly 3y ago
        That fits the "almost 20 years ago" line in the blog post.
        jrockway 3y ago
        That's hilarious. I missed that line and the name of the hurricane line. But blink tags, those stick with me.
- tedunangst 3y ago
  Multiple ports have been supported for more than 20 years.
- hnlmorg 3y ago
  I remember doing some relatively complex stuff with SSH config 15 or 20 years ago with IP filtering, different users having different chroots, IP forwarding rules based users connecting and rules around what SSH clients / protocols were allowed. Part of that was also defining custom ports too. All of which were just defined in sshd_config. None of this was new stuff back then. It just wasn’t well blogged (in fact it was so poorly written about that my very first blog post was on exactly this topic. Blog is long gone now though). However if anyone took the time to read the man pages, you’d see all the functionality is already backed into openssh
emj 3y ago
Do you believe it to be arcana for new sysadmins, or some technical reason it is a bad idea?
- taway1237 3y ago
  It's less surprising and the obvious way to do it. Iptables are very powerful, but not needed in this case.
m463 3y ago
hmmm... if port NNNN got through, maybe it went to something already listening on NNNN? but an iptables redirect could fix that. just idle speculation. I'm pretty sure "Port" worked with older ssh servers, maybe. openssh was only 4 years old 20 years ago. EDIT: hmmm what about needing privileges or an selinux config change?
- hnlmorg 3y ago
  Unlikely. While selinux is more than 20 years old, it was merged into the mainline kernel a few years after its initial release and it would have taken a while longer for that kernel to trickle down to distros, and then sysadmins installing.
  - jtriangle 3y ago
    Even when it was trickled down to the distros, it was unfortunately very much in vogue to disable it... Hell even in current year I occasionally come across guides that suggest disabling it... great way to get ctrl-w'd smh
r00f 3y ago
If server has strict iptables policy for incoming packets, you would still need to go to iptables allow second port. so if you need to iptables anyway, why just not redirect without editing sshd config? the less modifications the better chance to not forget to revert them
fiddlerwoaroof 3y ago
An advantage of “iptables magic” is that the service doesn’t ever have to run as root: I’ve done this before to great success to have a web server be accessible on standard ports even though it was running as an unprivileged user.
- f33d5173 3y ago
  There's a capabilities thing you can do to add the permission to a process without changing users. You can also have it bind to the port as root then drop permissions afterwards.
  - fiddlerwoaroof 3y ago
    Yeah, but requiring the process to start as root adds a window of vulnerability and the process has to drop privileges correctly. You could also do it in the load balancer/router.
    - superb_dev 3y ago
      Systemd can setup the privileges before starting the process
    - greyface- 3y ago
      Run this as root once: setcap 'cap_net_bind_service=+ep' /path/to/executable Now, the process doesn't need to start as root and drop privs.
- dijit 3y ago
  this is actually dangerous advice. The reason privileged ports require root is so that they cannot be easily intercepted by userland processes. The entire reason for the root requirement is this; it's expected that after your port assignment you drop your privileges to a lesser user. But requiring root to bind is a feature, not a bug. If you do not have this then intentionally crashing the process for a user and rebinding the port as a standard user (even `nobody`) is possible. This means if you break into someones mail server and run as the mail user, you would be able to bind ssh ports (if they are not privileged ports <1024). Of course your mail server should be running as the `mail` user or some equivelent, because only the binding of the ports should be done on startup as root and then it should drop into the mail user.
deleted 3y ago
[deleted]
miduil 3y ago
Honestly I also wonder now, I've read through the OpenSSH release notes which is one single HTML page with all releases since 2000, but unfortunately couldn't quickly spot when they would have introduced this change. https://www.openssh.com/releasenotes.html https://www.openssh.com/releasenotes.html

by dijit 3y ago

sleepybrett 3y ago

Possible that this was a feature added after this event?

dijit 3y ago
possible, but I see recommendations along these lines going back to 2011 https://serverfault.com/questions/284566/configuration-for-multiple-port-ssh https://serverfault.com/questions/284566/configuration-for-m...
- jrockway 3y ago
  I feel like the blink tag part of the story dates it to before 2011. (I just tested to see if blink tags still worked. It did not.)
  - fiddlerwoaroof 3y ago
    Unless it’s anonymized, Hurricane Jeanne dates it to 2004
    - btilly 3y ago
      That fits the "almost 20 years ago" line in the blog post.
      - jrockway 3y ago
        That's hilarious. I missed that line and the name of the hurricane line. But blink tags, those stick with me.
tedunangst 3y ago
Multiple ports have been supported for more than 20 years.
hnlmorg 3y ago
I remember doing some relatively complex stuff with SSH config 15 or 20 years ago with IP filtering, different users having different chroots, IP forwarding rules based users connecting and rules around what SSH clients / protocols were allowed. Part of that was also defining custom ports too. All of which were just defined in sshd_config. None of this was new stuff back then. It just wasn’t well blogged (in fact it was so poorly written about that my very first blog post was on exactly this topic. Blog is long gone now though). However if anyone took the time to read the man pages, you’d see all the functionality is already backed into openssh

emj 3y ago

Do you believe it to be arcana for new sysadmins, or some technical reason it is a bad idea?

taway1237 3y ago
It's less surprising and the obvious way to do it. Iptables are very powerful, but not needed in this case.

m463 3y ago

hmmm... if port NNNN got through, maybe it went to something already listening on NNNN? but an iptables redirect could fix that. just idle speculation. I'm pretty sure "Port" worked with older ssh servers, maybe. openssh was only 4 years old 20 years ago. EDIT: hmmm what about needing privileges or an selinux config change?

hnlmorg 3y ago
Unlikely. While selinux is more than 20 years old, it was merged into the mainline kernel a few years after its initial release and it would have taken a while longer for that kernel to trickle down to distros, and then sysadmins installing.
- jtriangle 3y ago
  Even when it was trickled down to the distros, it was unfortunately very much in vogue to disable it... Hell even in current year I occasionally come across guides that suggest disabling it... great way to get ctrl-w'd smh

r00f 3y ago

If server has strict iptables policy for incoming packets, you would still need to go to iptables allow second port. so if you need to iptables anyway, why just not redirect without editing sshd config? the less modifications the better chance to not forget to revert them

fiddlerwoaroof 3y ago

An advantage of “iptables magic” is that the service doesn’t ever have to run as root: I’ve done this before to great success to have a web server be accessible on standard ports even though it was running as an unprivileged user.

f33d5173 3y ago
There's a capabilities thing you can do to add the permission to a process without changing users. You can also have it bind to the port as root then drop permissions afterwards.
- fiddlerwoaroof 3y ago
  Yeah, but requiring the process to start as root adds a window of vulnerability and the process has to drop privileges correctly. You could also do it in the load balancer/router.
  - superb_dev 3y ago
    Systemd can setup the privileges before starting the process
  - greyface- 3y ago
    Run this as root once: setcap 'cap_net_bind_service=+ep' /path/to/executable Now, the process doesn't need to start as root and drop privs.
dijit 3y ago
this is actually dangerous advice. The reason privileged ports require root is so that they cannot be easily intercepted by userland processes. The entire reason for the root requirement is this; it's expected that after your port assignment you drop your privileges to a lesser user. But requiring root to bind is a feature, not a bug. If you do not have this then intentionally crashing the process for a user and rebinding the port as a standard user (even `nobody`) is possible. This means if you break into someones mail server and run as the mail user, you would be able to bind ssh ports (if they are not privileged ports <1024). Of course your mail server should be running as the `mail` user or some equivelent, because only the binding of the ports should be done on startup as root and then it should drop into the mail user.

deleted 3y ago

[deleted]

miduil 3y ago

Honestly I also wonder now, I've read through the OpenSSH release notes which is one single HTML page with all releases since 2000, but unfortunately couldn't quickly spot when they would have introduced this change. https://www.openssh.com/releasenotes.html https://www.openssh.com/releasenotes.html