5 ms·

I disagree with just one point. Non-standard ports. They work wonders against lots and lots of traffic from Chinese bots which are too stupid to see that pass

I disagree with just one point. Non-standard ports. They work wonders against lots and lots of traffic from Chinese bots which are too stupid to see that password logins are disabled but there's a fucking lot of them, they just won't stop knocking, and it does take cycles to fend them off in any way. You stop listening on port 22, and 99% of that shit traffic just goes away. I know, it's not by the book, and that well ackchyually I should yak yak this and yada yada that. But it's so fucking cheap and simple to do, and it goes brrr, so I just don't care.

WesolyKubeczek 3y ago
Case in point: > changing your SSH port to non-root port (>1024) means that if the SSH daemon dies, any userland process can take its' place. this is bad. Man, if you have sshd that likes to die a lot, you've got bigger problems already. If you have userland processes that can take your sshd port over maliciously, you're already fucked and should really reprioritize your worries. > changing your SSH port means that you'll have to do a bunch of fuckery to get basic functionality working. ~/.ssh/config goes brrrrrr > you will very likely waste hours of your life. Only if I need to dictate the contents of that file to my iPhone, otherwise it's seconds. > you will have to google "rsync ssh non standard port" every time you want to use rsync rsync uses ssh process under the hood, and that will pick up my shiny config and go brrrrr. Man, what if you need, dare I say, oh gosh, ProxyCommand!? Won't your head explode? How many times will you have to google it? Are you a goldfish who went sysadmin? > you will have to remember scp flags. this is also bad. probably worse. scp from OpenSSH honours OpenSSH configs, so it goes brrrr. > you will have to tell the port to anyone else who tries legitimately accessing your system. "Here's a fragment that you copy and paste into your ~/.ssh/config. Remember to do a chmod 0600 on it if the file is not there already." My god, is it me getting old, but when I was young it was customary to know the basics of your tools.
- lxgr 3y ago
  > userland processes that can take your sshd port over maliciously, It doesn't need to happen maliciously. The result is the same: You might be locked out permanently. > if you have sshd that likes to die a lot, you've got bigger problems already It doesn't have to die, it can also just happen during startup. Let's say you initially configure port 2222, restart sshd, everything works well, so you remove port 22, restart one more time, and stop thinking about it. Then, on your next reboot, it turns out that port 2222 is actually the preferred port of some other automatically starting service that just happened to not be running during your experiment, but which is now racing sshd for port 2222: That's bad. > rsync uses ssh process under the hood, and that will pick up my shiny config and go brrrrr. And just as many applications including an SSH client won't pick up the config from .ssh/config (for example because they can't read that directory because they're sandboxed). > Man, what if you need, dare I say, oh gosh, ProxyCommand!? Won't your head explode? How many times will you have to google it? Are you a goldfish who went sysadmin? SSH is used by all kinds of people, not all of them condescending sysadmins.
  - WesolyKubeczek 3y ago
    > Let's say you initially configure port 2222, restart sshd, everything works well, so you remove port 22, restart one more time, and stop thinking about it. > Then, on your next reboot, it turns out that port 2222 is actually the preferred port of some other automatically starting service that just happened to not be running during your experiment, but which is now racing sshd for port 2222: That's bad. Isn't it sysadmin 101 "How not to get locked out"? You should know already what else might be running on the box, or learn the hard way. > And just as many applications including an SSH client won't pick up the config from .ssh/config (for example because they can't read that directory because they're sandboxed). Put the relevant config where the sandbox can see it. > SSH is used by all kinds of people, not all of them condescending sysadmins. SSH should be used by people who at least know what a file is and how to protect their private key, I think that putting in a few lines of configuration (or having a provisioning tool do it for them) is a non-issue. Except if you are willing to die on that hill and think up artificial obstacles.
- justsomehnguy 3y ago
  > Man, if you have sshd that likes to die a lot, you've got bigger problems already. This one. One amusing thing what these apologists completely ignore (because they don't know shit?): just fucking DNAT a high port to localhost:22 and drop externalip:22. Bam, works.
- Retr0id 3y ago
  I always change my ssh ports from the default, not for any security reasons, but because I'm frequently on stupid networks that block traffic on port 22. In my experience, non-standard ports are more likely to work, in general.
serf 3y ago
it's fine until you run into some stupidly written tool or abstraction layer that relies on ssh being port 22. yes, it sucks to make efforts to accommodate your worst software, but sometimes it's easier to throw the cycles away than to dick around with a custom iptables entry to fix someone elses poor software design choices.
- BiteCode_dev 3y ago
  You use ssh to proxy x to 22 and connect stupid tool to that.
- WesolyKubeczek 3y ago
  > it's fine until you run into some stupidly written tool or abstraction layer that relies on ssh being port 22. Good part of being me is not having to deal with such tools. If I see something like this, I consider finding an alternative immediately because the hardcoded port will be the least of its problems. If it assumes and insists on a port, there's a good chance it doesn't even piggyback on an ssh command or libssh and reimplements lots of ssh itself. What ever could go wrong with this approach? If it's a tool to which source is available, it can be patched up. It can be used on the right side of the LAN where you can use well-known ports all you want. Embrace and use VPNs, they are good! I'm somehow convinced that if the ground rules are laid out up front in no ambiguous terms, the workaround will be found on the side of the badly-written software.
- pepa65 3y ago
  Nothing should rely on ssh being on 22 without taking config into account. Never use stupid tools!

WesolyKubeczek 3y ago

Case in point: > changing your SSH port to non-root port (>1024) means that if the SSH daemon dies, any userland process can take its' place. this is bad. Man, if you have sshd that likes to die a lot, you've got bigger problems already. If you have userland processes that can take your sshd port over maliciously, you're already fucked and should really reprioritize your worries. > changing your SSH port means that you'll have to do a bunch of fuckery to get basic functionality working. ~/.ssh/config goes brrrrrr > you will very likely waste hours of your life. Only if I need to dictate the contents of that file to my iPhone, otherwise it's seconds. > you will have to google "rsync ssh non standard port" every time you want to use rsync rsync uses ssh process under the hood, and that will pick up my shiny config and go brrrrr. Man, what if you need, dare I say, oh gosh, ProxyCommand!? Won't your head explode? How many times will you have to google it? Are you a goldfish who went sysadmin? > you will have to remember scp flags. this is also bad. probably worse. scp from OpenSSH honours OpenSSH configs, so it goes brrrr. > you will have to tell the port to anyone else who tries legitimately accessing your system. "Here's a fragment that you copy and paste into your ~/.ssh/config. Remember to do a chmod 0600 on it if the file is not there already." My god, is it me getting old, but when I was young it was customary to know the basics of your tools.

lxgr 3y ago
> userland processes that can take your sshd port over maliciously, It doesn't need to happen maliciously. The result is the same: You might be locked out permanently. > if you have sshd that likes to die a lot, you've got bigger problems already It doesn't have to die, it can also just happen during startup. Let's say you initially configure port 2222, restart sshd, everything works well, so you remove port 22, restart one more time, and stop thinking about it. Then, on your next reboot, it turns out that port 2222 is actually the preferred port of some other automatically starting service that just happened to not be running during your experiment, but which is now racing sshd for port 2222: That's bad. > rsync uses ssh process under the hood, and that will pick up my shiny config and go brrrrr. And just as many applications including an SSH client won't pick up the config from .ssh/config (for example because they can't read that directory because they're sandboxed). > Man, what if you need, dare I say, oh gosh, ProxyCommand!? Won't your head explode? How many times will you have to google it? Are you a goldfish who went sysadmin? SSH is used by all kinds of people, not all of them condescending sysadmins.
- WesolyKubeczek 3y ago
  > Let's say you initially configure port 2222, restart sshd, everything works well, so you remove port 22, restart one more time, and stop thinking about it. > Then, on your next reboot, it turns out that port 2222 is actually the preferred port of some other automatically starting service that just happened to not be running during your experiment, but which is now racing sshd for port 2222: That's bad. Isn't it sysadmin 101 "How not to get locked out"? You should know already what else might be running on the box, or learn the hard way. > And just as many applications including an SSH client won't pick up the config from .ssh/config (for example because they can't read that directory because they're sandboxed). Put the relevant config where the sandbox can see it. > SSH is used by all kinds of people, not all of them condescending sysadmins. SSH should be used by people who at least know what a file is and how to protect their private key, I think that putting in a few lines of configuration (or having a provisioning tool do it for them) is a non-issue. Except if you are willing to die on that hill and think up artificial obstacles.
justsomehnguy 3y ago
> Man, if you have sshd that likes to die a lot, you've got bigger problems already. This one. One amusing thing what these apologists completely ignore (because they don't know shit?): just fucking DNAT a high port to localhost:22 and drop externalip:22. Bam, works.
Retr0id 3y ago
I always change my ssh ports from the default, not for any security reasons, but because I'm frequently on stupid networks that block traffic on port 22. In my experience, non-standard ports are more likely to work, in general.

serf 3y ago

it's fine until you run into some stupidly written tool or abstraction layer that relies on ssh being port 22. yes, it sucks to make efforts to accommodate your worst software, but sometimes it's easier to throw the cycles away than to dick around with a custom iptables entry to fix someone elses poor software design choices.

BiteCode_dev 3y ago
You use ssh to proxy x to 22 and connect stupid tool to that.
WesolyKubeczek 3y ago
> it's fine until you run into some stupidly written tool or abstraction layer that relies on ssh being port 22. Good part of being me is not having to deal with such tools. If I see something like this, I consider finding an alternative immediately because the hardcoded port will be the least of its problems. If it assumes and insists on a port, there's a good chance it doesn't even piggyback on an ssh command or libssh and reimplements lots of ssh itself. What ever could go wrong with this approach? If it's a tool to which source is available, it can be patched up. It can be used on the right side of the LAN where you can use well-known ports all you want. Embrace and use VPNs, they are good! I'm somehow convinced that if the ground rules are laid out up front in no ambiguous terms, the workaround will be found on the side of the badly-written software.
pepa65 3y ago
Nothing should rely on ssh being on 22 without taking config into account. Never use stupid tools!