[tylerhall]

Good sleuthing, but the missing port number is simpler than that. I just blacked it out of the screenshot. I know very well that running sshd on a non-standard port has no benefits security-wise, but it does lessen the length of my log files from dumb script kiddies. I redacted the port in the screenshot for that reason.

[jonny_eh]

You should mention that in the caption, or use a non-black colour as a mask.

[simias]

>I know very well that running sshd on a non-standard port has no benefits security-wise

I don't know if Mac OS is different but on other unices ports above 1024 are not privileged, meaning that anybody can bind them. Now it increases the attack surface only a tiny bit (you have to have your sshd offline, and the attacker have local access, and them bind a fake sshd to your port in order to MitM. And even then they won't be able to spoof the server key unless it's not chmoded correctly).

Still, better safe than sorry IMO, I also use a non-standard sshd port but I keep it in the low range. In my experience it's more than sufficient to get rid of 99% of dumb attacks that generally don't bother looking beyond port 22.

[INTPenis]

I think using a non-standard port is a good layer of security, among other layers.

My personal suggestion though is to use 1022 because it's below 1024. This means only root is allowed to bind to it. Preventing possible connection jacking attacks if an attacker is able to crash your own server and run theirs to harvest your passwords.

[jlgaddis]

You might add a few "-v"'s to your "ssh" command-line for more verbose debugging information.

[bo1024]

A port is mentioned in this line, you may want to redact it. Where I put X's below, is a port number.

> So, I tried ssh ip-address -pXXXXXXXXX

[tylerhall]

Thanks, but that's not the port number :-) That was just for illustrative purposes.

[bo1024]

Ok great.

[0x0]

Have you tried running ssh in lldb/gdb and dumping a stacktrace when it hangs? Might have to copy the ssh binary to a temp dir to avoid SIP denying ptrace.

[ThePowerOfFuet]

Doesn't even need to go this hardcore; simply reading the verbose output would show where things are getting stuck.

[0x0]

The verbose output didn't seem to point out the exact system call or libc call that got stuck. A lldb/gdb bt stacktrace could pinpoint what's hanging (for example, some people mentioned parsing /etc/services). I don't think this has been resolved yet?

[ThePowerOfFuet]

Disable password auth and go with keys only, and your logs will go quiet.