I have a slackware (13.37 I believe) system that is basically used as a family file server. I have been away from the home for a long time and only way I was connecting was through a secure shell that was working, which I have not done in a while. I went to go in and it won't connect with a secure shell program (securecrt). Due to storms and what not linux and the router were shut off giving it a new IP address. We can from the console ping a computer from outside and get a responce, nmap shows linux is listening on the internal IP address. From a windows machine in same room portqry shows it is listening on port 22, but can not ssh in. Portqry from another country shows the external IP is listening on port 22. Router/modem had port forwarding to the linux ip and since portqry showed it was listening I assume that is working. SSH WILL NOT work in same room or in other country. I thought it might have been the host.allow file preventing it but removed everything dealing with ssh except for all. I am considering finding a way to talk to someone in the house that is helping me and upgrading from slackware 13.37 to slackware 14 once we can arrange for the dvd's to be made and set asside the proper amount of time, but would like to make sure i can get this working again before going through all this trouble and time. Considering it not me at the console and I am relying on someone else viewing the /var/log/secure log I am told someone else was able to get in but I not so sure of this think it was an attempt that failed, but I have not ruled out that this is the problem. the /etc/resolv.conf has search set for localhost and isp as well as primary and secondary nameservers for their dns numbers. Any suggestions on what else I could check would be greatly appreciated. Thank you in advance on any help you can shed on this situation.

Your router getting a new dynamic IP address from your ISP back home should not affect anything so long as the target of your ssh is either the newly assigned IP address or a properly updated dynamic DNS name.

You might have someone back home set LogLevel DEBUG in the sshd_config so you get more detailed logging. Besides /var/log/secure, you might also want to check for sshd messages in other places like /var/log/syslog and /var/log/messages.

Hello

Do you know if the slackware box is setup in DHCP ?
Maybe this box got another local IP address after the shutdown and the "ListenAddress" directive of ssh_config isn't correct anymore ? Or if you set up iptables on this box, the rule are not corresponding anymore ?

The router has the forward set to the linux IP address and in linux the /etc/resolv.conf looks like this
and the dns numbers were retrieved from the supplied isp router/modem so they were updated. But this nor IPTABLES would not prevent an internal connection with ssh to the linux computer and it is. Due to work schedules we should be able to set loglevel to DEBUG in the sshd_config and test it sometime today. I set up the slackware box so I know for a fact that it is NOT set up as DHCP and is set up as a static address and far enough up that the router wouldnt even try to hand this address out for it starts handing out addresses starting at 192.168.1.2 and hands them out in numerical order and the slackware box is now and always has been 192.168.1.199 as far as IPTABLES blocking me from outside getting in I can see that possible for I have changed ISP's but IPTABLES wouldn't block an internal computer and it is, I don't have it block internal addresses for a safety measure if I can't get in for some reason on one computer in the house I can try another in the house and it should work. I think it is something that the ISP is doing or the router/modem not forwarding even though the forwards have been removed and re-added but will see sometime today when we get to work on this.

This has nothing to do with the problem you are having with ssh, but 78.237.161.12 isn't a Verizon DNS server. It's part of an assigned block of addresses in France. I'd suggest removing that from your resolv.conf. I would remove verizon.net from the search directive and just leave localhost there. Maybe add another DNS address to replace the invalid one, like Google DNS address 8.8.8.8, so you have two valid name servers listed.

It's a good idea to assign a static IP address to the system you want to ssh to since your firewall port forwarding rules in your router depend on it being unchanging.

After you turn on LogLevel DEBUG and restart sshd with "/etc/rc.d/rc.sshd restart", look in /var/log/syslog and /var/log/messages for sshd messages. Note that the sshd_config man page states that "Logging with a DEBUG level violates the privacy of users and is not recommended." With that in mind, be sure to carefully review the output of "cat /var/log/syslog | grep sshd" and "cat /var/log/messages | grep sshd" if you decide to post it. If you post any logs, please wrap them in CODE tags.

I apologize that was a typo should have been 68.237.161.12. I do believe it is a problem with the router/modem not port forwarding, even tried adding it as a DMZ but the linux logs get no entries for log in attempts, none at all. Even tried changing the port to one above 1024 and that didn't work either. There was a conflict in the logs that I solved for time being until ssh is fixed then i will investigate deeper. SSH, Samba and ftp were all trying to bind to address 0.0.0.0 until ssh is back up and working I have turned samba and ftp off (commented out ftp in /etc/services and chmod 444 /etc/rc.d/rc.samba after it was stopped). Verizon may have stopped this because they considered it a server, but it internal and I only log in if there a problem or I am notified that something is not working. One thing I did notice other then the port forwarding not working is when I run from windows

it fails to resolve ip address to name and goes on to say that port is filtered. Port 2222 is what we set ssh to when 22 wasn't working.

I forgot to mention, you should also check /var/log/debug, as that is where the sshd debug messages will go. If the request is making it through your firewall to your ssh server, there should be some indication in there.

Verizon is my ISP. They don't block port 22.

Something is going on and it don't make sense, last night before I left for work portqry couldn't resolve the IP address to a name and when I did a whois on the IP address it came cack as belonging to Comcast, this morning it resolves the IP to a name and whois shows it from verizon. But it is also showing that the port is closed. ANd before anyone asks yes I put the numbers in right didn't this morning only ran same ones I did last night.

form the outside computer run, as root, nmap -p22 <WAN_SIDE_IP>

it will look something like this:

as you can clearly see i block port 22 and I do use a different port to access my home via the WAN.

I will get the old router hooked up for me and see if a ssh connection can be made then it will prove or disprove my thoughts that it the verizon supplied router/modem that you search on shows all kinds of issues of it not forwarding.

*** UPDATE ***

Connected old router and added a Windows computer and the Linux computer to one of the open ports of the router (with it like this there was no internet access). Made sure port forwarding was correct port and pointing to the Linux computer. It still didn't work, but the connection was getting to Linux for it made an entry in the log. It turned out when I had them delete the addresses in the hosts.allow they deleted too much, fixed that and then we were able to ssh in from the Windows computer that was connected to the same router as the Linux computer.

Still had same problem when it was hooked back up to the original router and to the internet. For some reason that I can't understand why it would work if I set the Linux computer up as DMZ and connected on port 2222, I checked the /etc/ssh/sshd_config and it was set to 22. I have no idea where it was getting the 2222 from but it was working.

With it working I got either brave or stupid however you want to look at it and did the Slackware upgrade to Slackware 14 using slackpkg commands. All seemed to go well and at end I didn't run lilo for I had replaced this with grub2 some time ago. I ran the to have the new kernels added to the grub2 menu. None of the 2 new kernels would boot one gave long list of errors that when asked was just told it filled screen and other gave kernel panic on the ext4 filesystem so something wasn't getting loaded in the kernel that should have. My 3.2.12 kernel would load but without network, when I told this I remembered seeing stuff being deleted and wondered if this was part of what was deleted. Anyway if I went into the directory containing the module it would load the driver for my realtek card and I could add an address and default route gateway. This has to be done after every boot.

Even with it up and running connecting from outside was not getting through was getting almost as soon as I tried the right computer was still DMZ and tried on port 22 and 2222 with same result. Decided to install the Slackware 14 from DVD and then try knowing it is possible for it to get through, just wonder if the router has some sort of cache system. Due to work we wont be able to tackle this until the weekend after next.