OK, so I've checked all over Google and PuTTY's FAQ site. No help. Also, sorry to be asking a Win question here, but I believe this problem occurs with ssh command in Linux-to-Linux connection, too. Here goes...

I'm at school (college) and I have access to PuTTY on all the school's computers. The IP addresses are dynamically assigned, but I know what mine is currently. PuTTY connects to my Linux box in my room (Dell Latitude Laptop FedoraCore1) from every computer on campus except computers in the Chemistry building (where I spend most of my time).

Description of exactly what happens:
I enter my IP address, select SSH, protocol 2 and hit enter (click open). The terminal screen pops up with my IP address in the top bar of the window, and there is a cursor. Otherwise, the window is black, blank. It sits there for a few seconds (5 or so) and then closes with no error message.

Again, I only have this problem with a few computers. Only select boxes in one room of the Chem building have this problem (two of them, I believe). Might it be due to the RSA keys? It seems that for computers that I have never connected from, it whether or not to store the RSA key for that box. Perhaps the key for those specific ones that don't work got moved into the deny pile somehow? Anyways, thanks for any and all help.

PuTTY has options for debug logging and saving the log file. I don't have a Win* box in front of my right now, but just dig through the client interface and you should find it. Read the debug log after the failed connection to see what the errors are.

The log is empty. Except for the title, which includes "PuTTY <date> <time>" and that is it. No errors. Nothing.

You need to turn up the level of detail on logging. There is one option that will log every SSH command that is sent during the session negotiation.

One other thing to note: this problem only began to occur a few days ago, maybe three or four. Before, that I could connect from these computers no problem.

Here's what I get for the failed connection:
It's like it just times out.

This is what it lists for the computers I can connect from:

There's probably a firewall in the way, then. You can do a simple test by doing:and seeing if you get the OpenSSH banner (which you probably won't). You should either get a "connection timed out" or "connection refused". The first means there's probably a firewall in between that's dropping packets, and the second would mean there's a firewall that's rejecting packets.

It's also possible that there isn't a route from that network segment to where your machine lives. Trying traceroute'ing to it.

Crap I just pressed the Back button and deleted my response. Anyways, I think this is what I had.

I tried to telnet to 22, this is the output (that I can remember)
Also, for some reason, traceroute is not working on the Linux box in this building. It is listed in /usr/sbin, and /usr/sbin is exported as a PATH from /etc/profile. For whatever reason, though, traceroute command is not found. I tried using other shells, no dice. I don't have admin privileges on that machine, either, so that might be the problem. Is there a DOS command similar to traceroute? If so, I may be able to try to trace from the Win computer I'm currently on (the one that has troubles connecting). Thanks for your help.

There is a dos command for traceroute. It is tracert x.x.x.x

Hope it helps.

Thanks. So I did traceroute from DOS on the comp that can't connect with PuTTY and it was able to trace to the box in my room. Any other ideas?

Ask the network administrator.

The port is being blocked by a firewall. "Connection closed by remote host" means you get an RST back, i.e. the firewall rejected (rather than dropped) the SYN packet. The fact that you could traceroute to it shows that it's not a routing issue.

Yes, definitely sounds like a firewall. If the systems administrator won't do the right thing and open port 22 for you, you might want to tweak your Dell box and have sshd listen on an unprivileged port, say port 2222 or something and use putty to connect to that. That sort of thing normally works

Somehow, the issue has resolved itself.

I'm not sure why one or two workstations on a subnet would have packets rejected while other ones on the same subnet would allow them. The path to my Laptop is the same regardless of the workstation I use at the Chem building. Very confusing...

As far as the system administrator listening to my requests...I have had enough dealings with IT here that it would not be worth it. They are clueless when it comes to non-M$ OSes. They are even pretty clueless with OS X. For example when I had an IP address pointer issue that involved Samba, they told me that "it is against acceptable use policy to run a server. Disable it immediately." Of course I didn't because the equivalent service is automatically enabled in XP and every other student on campus uses that resource (they don't have a good idea/definition of what a 'server' is). And when I told them that I was running Linux, they said they "do not support alternative OSes such as Linux." Mind you I had asked them a general networking question (i.e. why does my machine's name resolve to an IP address that is not mine?).

So as far as asking the system administrator goes, it's about as useful as asking a rock. But thanks for the suggestion.

I think the only one that has ever helped me (besides LQ.org) is my Chem professor, who admins a Linux Beowulf cluster in the Chem building. Anyways, thanks for all the help guys. It's been really great. And if I run into the problem again, I will try having sshd listen on an alternate port.