Find a flaw

It's easy, it works, and the only reason to leave SSH on port 22 is for the sake of convention.

It's either that or implement some unnecessarily complex scheme like port knocking when simply changing the port eliminates 99% of problems.

who said anything about password auth? I explicitly said preshared keys.
I just don't want my server to appear on network scans for no reason

it's a healthy design to not answer on invalid handshake message. not even " unnecessarily complex scheme", probably even simpler
could even work with password authentication when PAKE used (which should but as I said, I haven't read the standard yet)

Yeah port knocking would be the closest thing to op "stealth" idea.
You said you wanted the chinks to stop trying to bruteforce your shit and keys will do just that. No for the complete invisibility on a network yeah port knocking would work.

If reassigning a port is harder than configuring a dynamic change in firewall to allow access to specific ports on an arbitrary sequence of port connections, then I really wonder wtf type of system you are running.

Not saying port knocking is particularly hard to implement, it just doesn't seem worth it in most situations.

I mean, if you wanna hide from state actors it's probably a decent idea, but skiddie botnets filling your logs with failed connection attempts doesn't usually justify the extra effort to me.

whoops it's explicitly in standard, well there you have a flaw

Attached: Screenshot from 2018-12-04 20-03-06.png (554x136, 10K)

Kek not even state actors can get into properly configured SSH

Skiddies botnet don't scan non standards ports so he'll be safe. Just change the port OP you don't need to be invisible. Also there is a higher probability of you fucking it up somehow when messing around with iptables or some port knocking daemon (sry don't know one) than there is by just changing the listen port
Most ssh compromises happen because of shit passwords or secret keys not staying secret... But I wouldn't discard the power of some 3 letters agencies.

>Most ssh compromises happen because of shit passwords or secret keys not staying secret... But I wouldn't discard the power of some 3 letters agencies.
I would. There's little technical stuff that is secret about three letter agencies. It's what they do with it that's secret.
Let's take eternal blue; SMBv1 is a security trainwreck and this was common knowledge. That they found a zero day in it is not really a surprise, no-one would have ever bet money on SMBv1 being secure.
SSH however has a long history of actually being secure. They're on difference scales.
three letter agencies are more likely to just activate the hardware backdoor.

goto

I assume you already have key-only authentication. The next step would be setting up fail2ban. I run very strict settings on my server, after only one failed authentication attempt you get banned with iptables for 365 days. Chinks be gone!

Perhaps
The hardware stuff does scare me though, probably because I feel so out of my depth when reading up on x86 related papers... And prob also because no community, no open source patch can ever happen for that...

Careful lad, don't forget to add a whitelist with your commonly used IPs to fail2ban.
Else there's a denial of service condition that could be made.

Although it's very amusing to watch chinks smash themselves against fail2ban. I need to set one up for my http server - it's not hosting anything but chinks keep trying phpmyadmin and other low hanging fruit and it's filling my logs with junk. Fucking chinks ree

Anyway, SSH is extremely cool and everyone should use it.

Also I once read about a guy hosting "Free Tibet" kind of stuff just so that chinks FW would block any outbound traffic to his ip.
Doesn't work if they bounce around any non China proxy and I don't even know if it's true but if it is, this is fucking hilarious

I know of 2 static public IP addresses that I can use freely as a client without worries of attacks coming from there, those are on a whitelist. Additionally I have a VPN network, which is whitelisted as well, utilizes client certificate authentication and runs on an unscanned non-default port above 1023. Even if that port is not accessible through a restrictive firewall (the point of running SSH on 22 in the first place are problematic firewalls in my area allowing traffic through that port), I still have a secondary server in an address space that doesn't get scanned, which is always connected to the VPN while hosting a second VPN on its own on port 443, over which I can route traffic. Additionally I have a tightly secured web-based terminal for the main server in a nondefault vhost as a subdomain in a zone only managed by my own name servers. Lastly there are other people with root access on this server, each having multiple dynamic IPs through which they could connect to the server and unban me.
tl;dr good luck kiddo, I'm behind 7 proxies

Yeah, that's what I was saying, but dude didn't like the idea of simply changing the default port for some reason >"that's a crappy work around"

I'm glad it's there, regardless of not being perfect

>change the listening port to anything else in the non privileged range.
most retarded advice ever
now you're vulnerable to a local dos that could kill sshd and start a compromised replacement in its place as a standard user because the listening port is not in the privileged range

Reminder that security by obscurity is not real security.

Not l33t 3n0uGh for him I guess..

Alright...calling BS on (You) but I m gonna take the bait.
>local dos killing sshd
>compromised replacement
Anyway an sshd not running as a privileged user wouldn't be able to setuid anything so it's essentially useless, an unprivileged user/attacker running a ("rogue") daemon is the only one capable of logging in there so at that point...
And I m not even talking about host keys appearing all messed up for any sane clients that would definitely NOT ignore his ssh client warnings..

That isn't the point. It would just need to kill the root sshd in some way and then run its own thing. That would listen on the same port and pretend to be a normal sshd up to the point where it captures the username and password. Then it could do whatever it likes, dump the user out with some error, or present some sort of simulated shell.

>Anyway an sshd not running as a privileged user wouldn't be able to setuid anything so it's essentially useless, an unprivileged user/attacker running a ("rogue") daemon is the only one capable of logging in there so at that point...
you can accomplish that with binaries like su which are already setuid and use the captured username and password
>And I m not even talking about host keys appearing all messed up for any sane clients that would definitely NOT ignore his ssh client warnings..
a valid point
then again, how many people actually care for that and don't just click through the warning/delete the entry in known_hosts
sshd is definitely one of the harder things to compromise, but user incompetence always makes it easier

ssh is meant to be hardened manually, but it isn't usually because niggers like OP just think "hurrrr it has secure in its name it must be safe"
medium.com/@jasonrigden/hardening-ssh-1bcb99cd4cef

its perfectly ok to have root permitted as ssh login
change my mind.

Short of disabling password authentication, what else is there to do?
Moving the port is just foolish, port knocking?

Technically any physical implementation is easily crackable.

Good point with port knocking instead of changing the port, but doing both would be even better.

>Short of disabling password authentication, what else is there to do?
Well I have this in my sshrc to notify me of all new ssh connections. For a remote server it would send an email
R_HOST="$(echo "${SSH_CONNECTION}" | cut -d " " -f 1)"
notify-send -t 8640000 "NEW SSH CONNECTION" "USER: ${USER}\nR_HOST: ${R_HOST}\\n${SSH_CONNECTION}"

More importantly if there was ever a vulnerability in one of the services, there'd still be other security measures in place.

Well, interesting talk (glad to see you can still have a /g conversation on /g) but we're way past the point of chink botnets bruteforcing weak passwords on a default port 22 install so I think OP is secure.

Oh and BTW you can't kill (or SIG"anything") a process you don't own so killing sshd running as root means either you're already root (fun times ahead) or you found a DoS vuln in sshd (congrats in the CVE)

why would i do that
change your mind, that is

Dropbear > openssh
Prove me wrong

Clever, but I've still never heard of anyone breaking SSH, just spamming you endlessly if you don't have fail2ban

what is port knocking

Attached: jeopardy-998x698.jpg (998x698, 69K)

Exactly. It would require a vulnerability that causes sshd to crash. Protecting against unknown attacks is a good idea. There's no point in having a larger attack surface for no reason.