# [Solved] Cygwin SSHD Stopped Working

## solamour

I have sshd in Cygwin (Windows 7). "ssh localhost" from Win7 works fine, but I'm not able to ssh to Win7 from others.

```
Gentoo1 -> Gentoo2: OK

Gentoo2 -> Gentoo1: OK

Win7 -> Gentoo{1,2}: OK

Gentoo{1,2} -> Win7: Not OK
```

This is what happens when it's not working; it just sits there doing nothing.

```
$ ssh -vv win7

OpenSSH_5.8p1-hpn13v10, OpenSSL 1.0.0e 6 Sep 2011

debug1: Reading configuration data /home/solamour/.ssh/config

debug1: Reading configuration data /etc/ssh/ssh_config

debug2: ssh_connect: needpriv 0

debug1: Connecting to win7 [192.168.0.1] port 22.

debug1: Connection established.

debug2: key_type_from_name: unknown key type '-----BEGIN'

debug2: key_type_from_name: unknown key type '-----END'

debug1: identity file /home/solamour/.ssh/id_rsa type 1

debug1: identity file /home/solamour/.ssh/id_rsa-cert type -1

debug1: identity file /home/solamour/.ssh/id_dsa type -1

debug1: identity file /home/solamour/.ssh/id_dsa-cert type -1

debug1: identity file /home/solamour/.ssh/id_ecdsa type -1

debug1: identity file /home/solamour/.ssh/id_ecdsa-cert type -1

```

And here is the output for "ssh localhost" (working case) from Win7.

```
C:\>ssh -v localhost

OpenSSH_5.8p1, OpenSSL 0.9.8r 8 Feb 2011

debug1: Reading configuration data /etc/ssh_config

debug1: Connecting to localhost [::1] port 22.

debug1: Connection established.

debug1: identity file /home/solamour/.ssh/id_rsa type 1

debug1: identity file /home/solamour/.ssh/id_rsa-cert type -1

debug1: identity file /home/solamour/.ssh/id_dsa type -1

debug1: identity file /home/solamour/.ssh/id_dsa-cert type -1

debug1: identity file /home/solamour/.ssh/id_ecdsa type -1

debug1: identity file /home/solamour/.ssh/id_ecdsa-cert type -1

debug1: Remote protocol version 2.0, remote software version OpenSSH_5.8

debug1: match: OpenSSH_5.8 pat OpenSSH*

debug1: Enabling compatibility mode for protocol 2.0

debug1: Local version string SSH-2.0-OpenSSH_5.8

debug1: SSH2_MSG_KEXINIT sent

debug1: SSH2_MSG_KEXINIT received

debug1: kex: server->client aes128-ctr hmac-md5 none

debug1: kex: client->server aes128-ctr hmac-md5 none

debug1: sending SSH2_MSG_KEX_ECDH_INIT

debug1: expecting SSH2_MSG_KEX_ECDH_REPLY

debug1: Server host key: ECDSA bc:a1:14:e7:a3:25:36:6f:a4:91:36:f2:6f:cf:45:1d

debug1: Host 'localhost' is known and matches the ECDSA host key.

debug1: Found key in /home/solamour/.ssh/known_hosts:1

debug1: ssh_ecdsa_verify: signature correct

debug1: SSH2_MSG_NEWKEYS sent

debug1: expecting SSH2_MSG_NEWKEYS

debug1: SSH2_MSG_NEWKEYS received

debug1: Roaming not allowed by server

debug1: SSH2_MSG_SERVICE_REQUEST sent

debug1: SSH2_MSG_SERVICE_ACCEPT received

debug1: Authentications that can continue: publickey,password,keyboard-interactive

debug1: Next authentication method: publickey

debug1: Offering RSA public key: /home/solamour/.ssh/id_rsa

debug1: Server accepts key: pkalg ssh-rsa blen 279

debug1: read PEM private key done: type RSA

debug1: Authentication succeeded (publickey).

Authenticated to localhost ([::1]:22).

debug1: channel 0: new [client-session]

debug1: Requesting no-more-sessions@openssh.com

debug1: Entering interactive session.

Last login: Mon Nov  7 13:52:23 2011 from ::1

solamour@win7 ~

```

I disabled Win7's firewall, and I clearly remember it worked a while ago, although I'm not sure what happened since then. I welcome any suggestions.

__

solLast edited by solamour on Tue Nov 08, 2011 5:24 am; edited 1 time in total

----------

## Hu

What does a packet capture show being sent/received in the failed case?

----------

## solamour

 *Hu wrote:*   

> What does a packet capture show being sent/received in the failed case?

 

Must be referring to "tcpdump" or something similar. Truth be told, I never got around learning how to use it. If you'd be generous enough to show me the steps, I'll follow through and share the result. Thank you.

__

sol

----------

## Hu

Try tcpdump -p -s0 -w /tmp/ssh-fail.pcap 'tcp and port 22'.  You might need to include -i interface if tcpdump picks the wrong interface by default.  When you have reproduced the failure, hit ^C to kill tcpdump.  The generated file is not human readable.  You can try to read it yourself using net-analyzer/wireshark or post it here.  If you post it here, you could base64 encode it so that we can download and read it or you could post the output of tcpdump -n -r /tmp/ssh-fail.pcap.  The former would be more flexible, but the latter is easier and may be sufficient.

----------

## solamour

It turned out that there was a different firewall in Win7 other than the built-in one. After turning that off, everything worked out OK. Thanks for the tcpdump tip. It really did the trick.

__

sol

----------

