Remote login stopped working!
 

I'm not exactly sure when this happened--probably less than 1 month ago--but remote login has (mostly) stopped working on my computer. I can still log in from the other computer on my home network, but not from any computer outside the network. I don't have a firewall and I don't think my ISP has anything to do with it because I can still log in to the other computer I have at home.

When I try to log in, I find the following message in my system log:
Jan 25 17:55:11 Juliet xinetd[5707]: START: ssh pid=5776 from=xxx.xxx.xxx.xxx
Jan 25 17:57:12 Juliet sshd[5776]: fatal: Timeout before authentication for xxx.xxx.xxx.xxx

Here's what a login from a machine on the local net looks like:
Jan 25 17:58:07 Juliet xinetd[5707]: START: ssh pid=5781 from=192.168.112.1
Jan 25 17:59:43 Juliet sshd[5781]: Accepted publickey for XXXXX from 192.168.112.1 port 49405 ssh2

Does anyone know what that "Timeout before authentication" error is all about? Has my SSH daemon somehow gotten misconfigured?

I'm running Mac OS 10.3.7 with all security updates. (The other computer on my home network is running 10.2.8.)

Check if your 'sshd' user-account is still there:
nidump passwd / | grep ssh
You should get:
sshd:*:75:75::0:0:sshd Privilege separation:/var/empty:/usr/bin/false

And I'm assuming that you have tried restarting your Mac.

Yup, it's there, except the shell is "/dev/null" instead of "/usr/bin/false", but that really shouldn't matter (and in any case, I CAN login from that one machine, so it's not totally screwed up).

Yes, indeed.

You could try turning on debugging mode in sshd via the "-d" option. You first need to find out where sshd is started from - if I recall correctly it is started via xinetd so look in /etc/xinetd.d

Problem solved, cause still a mystery
 

I studied the sshd man page and, on a hunch, decided to try the "-g 0" flag to sshd. Hayne, you are correct: I had to modify the file /etc/xinetd.d/ssh and change the line
server_args = -i
to
server_args = -i -g 0

I then had to turn remote login off and back on again in the "Sharing" pane.

This worked, although it takes a very long time to log in (about 2 minutes). There's a recent thread http://forums.macosxhints.com/showthread.php?t=32784 suggesting that turning off IPV6 might help, but it didn't help me.

I also tried the debugging flag. Turning on debugging in the xinetd configuration file caused SSH to fail immediately. So I had to launch it from the command line using sudo sshd -d. And suddenly it works! However if I launch from the command line without the debugging flag, it doesn't work. So the debugging flag is also causing the problem to disappear.

My current hypothesis is that the delay has something to do with the following message that appears now, after a successful login:
Jan 25 19:36:02 Juliet sshd[7384]: reverse mapping checking getaddrinfo for hidden.hostname.com failed - POSSIBLE BREAKIN ATTEMPT!

Anyone know how to fix that?

It's starting to sound like your problems might be merely slow DNS servers.

No, not slow DNS servers, his source address doesn't reverse resolve. Either get your DNS fixed or add it to "/etc/hosts" (or the equivalent, I'm at work and not on a mac right now)

What is reverse resolution?
 

So what exactly does that mean? I would have assumed that it means that SSH can't figure out the hostname from the IP address, except that hostname appears right there in the log message (I obfuscated it in the example above, but there's a real, usable, DNS name in my log message).

Yeah it shows in the message, but it wasn't REVERSE-resolved to get it. Add your source IP to /etc/hosts on the sshd server and it should work.

Hello There,

We have been having the same issues here. Ho wdo we add a source IP to the etc/hosts file. I can view it when mounting the server. How should the information be formatted?

TIA - Vijay

Well, I haven't tried this yet, but I did change the "VerifyReverseMapping" setting from yes to no in /etc/sshd_config. That got rid of the error message in the logs, but it still takes forever to log in, so there's another problem somewhere.

I hope this isn't off-topic, but someone here might know the answer. I have noticed a real slowdown in connecting to my server. I read the hint earlier about disabling IPv6, but that doesn't seem to have helped. In perusing this thread though, I took a look at my /etc/xinetd.d/ssh file and noticed this:

Can I change the 'flags' line to 'REUSE IPv4'? Can anyone tell me what this is? My server's system.log has this to say when I connect:
Thanks in advance.

[QUOTE=derekhed]
Can I change the 'flags' line to 'REUSE IPv4'? Can anyone tell me what this is?
I have:and everything works fine. This repaired an error I was getting (but I don't remember the error right now).

Does "everything works fine" mean it works faster? Did you have a speed problem? I will try this anyway, thanks for being the guinea pig!

You may edit your /etc/hosts file with pico, you'll need super user rights to do so:
sudo pico /etc/hosts

Note the format already existing in the file. Here is a sampling of mine:

Nope....
 

It still takes just over 40 seconds to get the password prompt, though I no longer get the IPv6 error in my system.log. Oh well, RTFM.

I reset my Network settings in the System Preferences and removed all DNS entries. Now my connections are extremely fast. I am not sure why doing this made a difference, but suspect my prefs might have been corrupted. Anyhow, hope this might help someone else.

Hi,

To get sshd to listen on IPv4 only, add "-4" to the server_args and tell xinetd to only use IPv4 in /etc/xinet.d/ssh

example:

The fastest way to apply the change is to restart xinetd

NB: if you connected remotely, this will kick you off the system.

What that does is send a HUP [hangup] signal to all instances of xinetd. This in turn causes xinetd to reload it's settings.

IPv6 shouldn't be a problem, it just causes annoying messages in the log file.

I suspect the slow login problems for most people are DNS related. The original problem is caused by name resolution taking longer then 2 minutes to generate a response, no login attempt is made, so ssh hangs up. (Notice the times of the log entries).

You can check your DNS like this:

1) Check your current settings

This means that the machine appends public.com to any local lookups. The machine is set to query two nameservers at the above IP addresses. If this file is empty, you cannot do namelookups via DNS.

If the machine is setup via DHCP, this information generally comes from the DHCP server. Any changes you make to the file will probably get overwritten when the machine is restarted.

2) nslookup is a great tool but has been deprecated. Here is an example:

nslookup suggests we should consider using host or dig instead.

Here is an example of the host command:

If name resolution is working correctly, you should get a response. In this case, www.google.com is aliased [ points to a few IP address, for load balancing] and we get a couple of the aliases.

Here is an example of the dig command:

Another problem sometimes is that your local machine cannot resolve it's own name. The easiest way to fix that is to be sure that your local machine is listed in the /etc/hosts file and that the name points to the IP address of the network card.

I am not very strong on OSX, so if I made any errors or if there is an easier way to set something, please correct.

Thanks for all that info!

If I am finding that the killall isn't working, what should I try next? I also tried kill -9 and the xinetd process survived. I don't want to have to restart.

Try
and then to start it up again
If for some reason that does not work and you have physical access to the machine, go to the Sharing PrefPane and uncheck everything. xinetd should then be stopped. Then reselect all of them that were checked before.

As it turns out, I had to restart the xinetd process by physically accessing my machine. I logged out, and couldn't log back in again. When I looked, there was no xinetd process, thus I had to 'sudo xinetd' and all was well. Not sure what made it crap the bed like that. I am moving the entire system to another drive soon anyway, so I am not going to worry about it.

Thanks again.

Apologies. I just realized how silly that was...either requiring physical access. I was not yet awake. [At least that's my excuse...and I'm sticking to it.]