This has never happened before, but my laptop is now unable to access any remote servers. I have tried with 3 independent servers that I have access as recently as last week.
I am not asked for my password,
home:~ x$ ssh -v -p22 user@server
OpenSSH_5.2p1, OpenSSL 0.9.7l 28 Sep 2006
debug1: Reading configuration data /etc/ssh_config
debug1: Connecting to server [194.57.168.xx] port 22.
debug1: connect to address 194.57.168.xx port 22: Operation timed out
ssh: connect to host serverport 22: Operation timed out
What might I have done wrong? I cleared the known_hosts file after I started having this problem. I can see that ssh_config is probably what is causing me this problem
When I ping any of the remote servers I get no response and on cancelling the request I have 100% packet loss.
As Duke mentioned, it's certainly a network problem. Could be an issue due to network configuration of the laptop or could be possible network admin changed VLANs behind your back and forgot to enable routing among them.
I would rather need a clear picture of your network and the network config of the OS you are running to conclude something.
As has been previously mentioned, more information about your network topology would probably help in troubleshooting this. That being said, let me toss out a couple situations that might apply to your problem, or if not, maybe they can help get you thinking in the right direction.
First, just because a ping does not succeed does not mean there is a problem. If you are on different subnets or networks, that might be normal. Most networks block ICMP (ping) traffic from entering their networks if not being more restrictive. If however, you have been able to successfully ping before, and now you cannot, then it would seem that there is indeed a network problem and you should contact someone on your network team.
Second, most UNIX and Linux servers use TCP_WRAPPERS to protect network services on their server. This means that in the hosts.allow file, there is most likely an entry allowing you and your computer access via SSH. This is done by allowing your IP address (or subnet perhaps) or hostname access to the system. If by some chance the IP address on your PC has changed (say, by DHCP) that could cause the error you see. Or if they are using a hostname to allow access, it could be a DNS problem if the server you are connecting to cannot perform a reverse DNS lookup on your IP. So there are a couple things to check, make sure your IP hasn't changed and make sure that reverse DNS is working properly for that IP. Plus, the server you are connecting to could be having DNS problems even if DNS in general is functioning on your network.
I hope this helps, please post an update with more information if you are still having problems, or if you find the solution.
As you get error with given command and your SSH command is user@server (I hope it is some server name not IP).
So it is trying to connect to 194.57.168.xx .
Now if ping failed it could that server is down/network is down or Server has ping disabled on n/w or on server or even from your laptop f/w.
Do some basic check
Check if you internet connection is good
Check if you can connect to another server on same n/w
if you have internet working . then try connecting via another server. Some times routes are set bad or shortest connection is down.
Call some one on Datacenter and check if server is up or not.
else .. :wall: we have a Road block.
home:~ x$ ssh -v -p22 user@server
OpenSSH_5.2p1, OpenSSL 0.9.7l 28 Sep 2006
debug1: Reading configuration data /etc/ssh_config
debug1: Connecting to server [194.57.168.xx] port 22.
debug1: connect to address 194.57.168.xx port 22: Operation timed out
ssh: connect to host serverport 22: Operation timed out
ping defaultgateway
ping servername
ping ipaddress
(on windows lapptop) tracert ipadress (firewalls on the way)
(on linux lapptopp) traceroute ipaddress
other issues
disable firewall and check things don't work again
accesslist on server
reinstall ssh or try another client (it was my issue bug in ssh2)
At this point it could be any number of the things people are saying; or a combination of them.
You're going to have to go down the OSI Model to figure it out. I'd post a link but apparently I need to have five posts first. All this "I have a feeling" stuff is completely useless. Troubleshooting is methodical and logical and not guessing. Troubleshoot from layer 1; the physical layer, first. That means double checking and reseating any of the connections betweent the points. Then check your network config and the server network config. Then verify the "network route" is in place and useable; if your in *NIX route is the same as traceroute in M$. If the results of that don't end up at your server then you have a routing issue. If it does, then you have a software configuration issue. ( For all you "leet" people, I'm going under the premise that not everyone is blocking ICMP like a retard.)
There is also the possibility that the bandwidth at either points is being overwhelmed. I often get that when I try to SSH into my home network from a coffee shop and forget to turn off bittorrent.
...and for things like bittorrent, it's often not really bandwidth that's being overwhelmed as much as the number of simultaneous connections. Distributed file sharing is awful in the way it spams thousands of connections when attempting to find just a few of them, filling the tiny connection tables of a hardware wireless router to the point that for any new connections to be made, an old one must die or timeout first.
Someone posted, so it was pulled back to the top. Let's hope the problem was solved in a more timely manner than that. I'd agree though that using ICMP as a test is a bad idea. Protocols aren't treated the same by firewalls, ACLs, etc. and many companies block it to prevent the reverse-enginnering of their network. Using netcat ('nc') or telnet to check the connection is a good first check. Couple that with a good network trace or tcpdump and you can normally find the issue fairly quickly. You can also start another SSH daemon on a port (such as 80/443) not in use that's often allowed by default through all networks and see if you're able to connect there. Start simple and work back up the OSI model.
