6 ms·
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 peri
by makecheck 7y ago
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/sshconnect.c#L488 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.
- 0x0 7y agoMaybe 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?
- tylerhall 7y agoGood 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 7y agoYou should mention that in the caption, or use a non-black colour as a mask.
- 0x0 7y agoHave 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 7y agoDoesn't even need to go this hardcore; simply reading the verbose output would show where things are getting stuck.
- 0x0 7y agoThe 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?
- bo1024 7y agoA 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
- jlgaddis 7y agoYou might add a few "-v"'s to your "ssh" command-line for more verbose debugging information.
- deleted 7y ago[deleted]
- simias 7y ago>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 7y agoI 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.
- ThePowerOfFuet 7y agoDisable password auth and go with keys only, and your logs will go quiet.