Comment by makecheck | Hacker News Reader

Comment by makecheck | Hacker News Reader

So, some quick debugging here...

In his screenshot the bad login hangs at "Connecting to clickontyler.com port" (noting that no port number appears and no period at the end).

While I can’t be sure exactly which "ssh" patch Apple may have, this seems to be the relevant file and logging code (starting at line 448):

https://github.com/openssh/openssh-portable/blob/master/sshc...

In that code, the only thing that can set the "strport" value that is used in the log is a call to getnameinfo().

If that string is corrupted in any way, e.g. not terminated or perhaps has invisible characters that trigger bad terminal behavior (such as invisibility), the act of logging it might produce the apparent hang seen here.

Again, a guess but it is possible that getnameinfo() is not necessarily processing the record correctly (for whatever reason). One such example is in the "getnameinfo" man page at the end, under CAVEATS, where they show an example of not simply trusting the result of the first call.

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.

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

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.

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

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?

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

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

Ok great.

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

>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.

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.

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

Maybe there is something funny in /etc/services on this machine that throws the call into an infinite loop? Perhaps near the bottom beyond port 8192?

Reply on news.ycombinator.com