- Host:
Amazon Linux with OpenSSH 6.6.1, OpenSSL 1.0.1k-fips 8 Jan 2015
- Client:
Win 10 with Cygwin OpenSSH 7.3p1, OpenSSL 1.0.2h 3 May 2016
I can ssh interactively with no problem:
win10$ ssh [email protected]
aws$
This port forwarding also works:
win10$ ssh -NTL 9003:localhost:80 [email protected] &
win10$
I use the latter to access phpmyadmin on the server through:
http://phpmyadmin.localhost:9003
That works fine.
In order to use netbeans to debug php code running on the server, I do:
win10$ ssh -NTR 9000:localhost:9000 [email protected] &
This used to work okay. But after upgrading Cygwin, I now get:
ssh: connect to host example.com port 22: Operation not permitted
Adding a -vvvv to the command line doesn't give much more information:
win10$ ssh -vvvv -NTR 9000:localhost:9000 [email protected]
OpenSSH_7.3p1, OpenSSL 1.0.2h 3 May 2016
debug1: Reading configuration data /home/user/.ssh/config
debug2: resolving "example.com" port 22
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to example.com [nn.nn.nn.nn] port 22.
debug1: connect to address nn.nn.nn.nn port 22: Operation not permitted
ssh: connect to host example.com port 22: Operation not permitted
I believe that the previous version of ssh that worked for me doing this was Cygwin on WinXP with OpenSSH 7.1p2, OpenSSL 1.0.2f, 28 Jan 2016
Nothing has changed on the server. Since port 9000 is not privileged, I don't think it should be a permission problem, especially since the server config hasn't changed, but I have to admit that port forwarding is basically magic to me. Any ideas what might be wrong or how to collect more/better information?
This isn't much of an answer, it's just what I have observed. I rebooted my Win10 PC, which applied some updates that were pending. I also have Eset Internet Security installed on it, with firewall filtering mode set to interactive. After the reboot, when I tried the forwarding that previously failed, Eset prompted that ssh.exe had been modified and asked if it was okay to keep the rules allowing it to initiate traffic. I said it was okay, and then it started working again. Before the reboot, Eset had no complaints. And as noted, the forwarding for port 9003 worked okay.
I don't know what to take away from this as a learning experience, other than the usual Windows mantra from XP days of "run Windows Update, and reboot frequently" but the problem is now resolved!