Dear General,
Before starting your putty session:
1. go to the Session Logging category
2. select Log SSH packet data
3. make a note of where your putty log is, it is probably best to start
with a new one.
Now attempt a connection to your server. On rejection, peruse your
putty.log file.
The complete negotiation from the client's perspective will be logged
and you should be told why the server is rejecting you.
Alternatively, you may see no negotiation with the server at all. If
this is the case the server is not running or is blocked for you.
However, from your description I would guess that your server is
negotiating with you. Perhaps it is configured to reject you, perhaps
because of a restriction at the server end that you are not following.
You might be able to work this out or you might need to talk to your IT
administrator with this information.
The other (remote) possibility that occurs to me is that you are falling
foul of some fancy all in one security product. Occasionally these
products decide that perfectly acceptable networking products like VNC,
putty, banking applications, email, etcetera are viruses or trojans and
cut them off after a successful protocol negotiation. You could check
the web site of or google for the security products you are running and
see if there is a (recent) clash with putty. If this happens, the all in
one security products eventually get an update which solves the problem.
In any case good luck,
Jeremy
GeneralNMX wrote:
[safeTgram (optim1) receive status: NOT encrypted, NOT signed.]
I'm trying to figure out why I can't ssh from work. Our IT admin is
always busy, so I can't ask him. PuTTY (yes, Windows-only office,
unfortunately) returns "Server unexpectedly closed connection" when
connecting to the ports I setup for SSH. Originally I set it up for the
IP range my office uses, but now the ports are open willy-nilly and
still returns the same thing. My router, running Debian, shows rejected
packets when I use the wrong port, but nothing when I use the right
port, so the packet isn't being rejected. Shields Up! shows the port
open, and I can login locally using that port, so I know sshd is
configured correctly. Considering that the corporate firewall may be
blocking 22 for security reasons, I've tried different ports, like 465,
etc.
Where would I start debugging a situation like this? I just added a log
statement to the forwarded packet to make sure I am receiving the packet
and forwarding it properly. Shields Up! confirms this.
For my workstation, it runs Windows XP with just the basic firewall
turned on. I have administrator-level access to the machine (the real
administrator account), so it has to be something inbetween.
Matt
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
