OpenSSL: socket: Connection refused connect:errno=111 - ssl

I am trying to connect to one Linux server from a client,
openssl s_client -connect <IP of Server>:443
I am getting the following error:
socket: Connection refused
connect:errno=111

Check the ports of the server by any tool.
For Example,
nmap <IP>
Starting Nmap 5.21 ( http://nmap.org ) at 2015-05-05 09:33 IST
Nmap scan report for <IP>
Host is up (0.00036s latency).
Not shown: 996 closed ports
PORT STATE SERVICE
22/tcp open ssh
111/tcp open *****
139/tcp open *****
443/tcp open openssl
MAC Address: 18:03:73:DF:DC:62 (Unknown)
Check the port number is in openstate.

As I mentioned in the comment that the host name is missing. You would mention is right before the port number.
$ openssl s_client -connect myHost.com:443
Edit: now that you mention that there is a hostname in the command so we are fine there. Now check to see if host/port is blocked. To check you can use nmap or telnet or any other port scanner.
If you can ping / connect to the host but not to the server process available on a particular port then there is a firewall blocking access.
The firewall could be on the host and if iptables is the firewall(assuming Linux) then you need to add a rule to allow the connection. For a quick test, you could disable the firwall (NOT RECOMMENDED). Or you could run the server process on a port that is open.

This has nothing to do with SSL. Connection refused means that either there is no server or the connection is blocked by firewall. In your case (before your edit) the server is also plain wrong, i.e. ":443" is no valid server name (hostname missing).

Related

Browser unable to connect to web2py over secure SSH tunnel

I followed the instructions in the web2py manual on how to connect to a remote web2py via ssh tunnel. SSH to my server appears to work just fine:
[~/prg]$ ssh -L 8002:127.0.0.1:8002 username#linux-server.com
Linux schemelab2 4.6.5-x86_64-linode71 #2 SMP Fri Jul 29 16:16:25 EDT 2016 x86_64
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
You have new mail.
but just as others have failed, when I attempt to visit http://localhost:8002 or https://localhost:8002 I get a number of connection refused messages:
channel 3: open failed: connect failed: Connection refused
channel 4: open failed: connect failed: Connection refused
channel 3: open failed: connect failed: Connection refused
channel 3: open failed: connect failed: Connection refused
channel 3: open failed: connect failed: Connection refused
channel 3: open failed: connect failed: Connection refused
channel 4: open failed: connect failed: Connection refused
channel 3: open failed: connect failed: Connection refused
channel 3: open failed: connect failed: Connection refused
channel 3: open failed: connect failed: Connection refused
If it helps any, here is my sshd_config
Also note:
telnet localhost 8002 yields
schemelab#schemelab2:~$ telnet localhost 8002
Trying ::1...
Trying 127.0.0.1...
telnet: Unable to connect to remote host: Connection refused
schemelab#schemelab2:~$
Could be one of several possible reasons. I am assuming you are mostly interested in accessing the web2py admin page on your remote server, since web2py doesn't allow remote admin access over an insecure channel... So first things first, you want to make sure your server's IP Tables are allowing access to services on the port you are trying to connect to, otherwise these remote connection solutions probably wont work (except for perhaps Plan C). See here for more info: https://help.ubuntu.com/community/IptablesHowTo
Firstly, let me show you how I SSH tunneled to web2py via dozens of servers I used in the past. I'll be using port 8889 in my examples:
ssh -L 8889:127.0.0.1:8889 username#linux-server.com
Just like with a normal SSH, you should now see the shell of your server (which you have demonstrated). Now, in the same terminal, cd to your server's root web2py directory and do the following (do not close the terminal window after):
> cd mywebite.com
> python web2py.py -a password -i 127.0.0.1 -p 8889
*web2py startup stuff*
Now on your local browser visit http://127.0.0.1:8889/admin and you should see the web2py admin page from your server.
Plan B - Using self-signed SSL certificate
If you're still having issues with ssh tunnel, another option you can try is using a self-signed SSL certificate.
Making a self-signed certificate is very easy with OpenSSL, and you can also use some online self-signed certificate generators (though I don't recommend this) to save you even more time.
Once you have your generated .crt and .key files, sftp to your server and upload the files to your server's root web2py directory (or upload them to Dropbox, ssh to your server, cd to your root web2py directory and wget the file links). Finally ssh to your server and do the following (do not close the terminal window after):
> cd mywebite.com
> python web2py.py -a password -p 8889 -i 0.0.0.0 server.crt -k server.key
*web2py startup stuff*
Now on your browser enter (notice the https) https://xxx.xxx.xxx.xxx:8889/admin (xxx... being your server IP), or you can do https://mywebsite.com:8889/admin if you already have your domain name setup.
Now you should see a SSL security warning on your browser. Simply ignore this warning and add an exception, and finally you should be able to see the web2py admin page from your server.
Plan C - Edit web2py source
This is the least recommended plan to allow admin over insecure channel, and should be used as a last resort. You can simply edit the part of the web2py source code that disables admin by just adding one line of code. In
<server's root web2py directory>\applications\admin\models\access.py (around line 21) put request.is_local=True before the part that disables admin over insecure channel:
'...'
request.is_local=True #TESTING ONLY. COMMENT OUT OR REMOVE IN PRODUCTION!
if request.env.http_x_forwarded_for or request.is_https:
session.secure()
elif not request.is_local and not DEMO_MODE:
raise HTTP(200, T('Admin is disabled because insecure channel'))
'...'
Now you can access your server's web2py admin by simply visiting http://xxx.xxx.xxx.xxx:8889/admin (xxx... being your server IP), or you can do http://mywebsite.com:8889/admin if you already have your domain name setup.
Note this is a quick and dirty solution and should be used only temporarily and for testing. Don't forget to remove or comment out that line in production!

Unable to run 'chef-client' from 'workstation' by knife ssh

When I run knife ssh "name:node1" "chef-client"
WARNING: Failed to connect to admagnifico.magnifico.fvds.ru -- Errno::EHOSTUNREACH: No route to host - connect(2) for [fe80::225:90ff:fe19:4b12]:22
And I can't find out why it so...
on node runs ufw with enabled 22, 443, 80
The hostname admagnifico.magnifico.fvds.ru is resolving to an unreachable IP address. The firewall isn't involved. That hostname isn't resolvable from here so I'm guessing it's an internal DNS setup.

haproxy fails to bind sockets with ssl option

I am trying to configure haproxy 1.5 on Ubuntu 3.2.0-91-generic as a TLS proxy for plain TCP traffic to a non-TLS server running on the same machine. The local non-TLS server is running on port 9501, and I want haproxy to listen on port 9500, decrypting incoming TLS connections on that port and forwarding the unencrypted TCP traffic to the server on port 9501. I'm doing all this on 172.28.11.94, which is a local intranet address that's bound to my eth0 interface. My haproxy config looks like this:
listen rtt 172.28.11.94:9500
mode tcp
bind 172.28.11.94:9500 ssl crt /etc/haproxy/cert.pem
option tcplog
server rks 172.28.11.94:9501
haproxy reports that this is valid:
dlobron#bos-lpjbb:/etc/haproxy$ sudo haproxy -f haproxy.cfg -V -c
Configuration file is valid
But when I run haproxy, I get an error:
dlobron#bos-lpjbb:/etc/haproxy$ sudo haproxy -f haproxy.cfg -V
Available polling systems :
poll : pref=200, test result OK
select : pref=150, test result FAILED
Total: 2 (1 usable), will use poll.
Using poll() as the polling mechanism.
[ALERT] 011/114700 (6149) : Starting proxy rtt: cannot bind socket [172.28.11.94:9500]
I verified that my local non-TLS server on port 9501 is fine:
dlobron#bos-lpjbb:/etc/haproxy$ telnet 172.28.11.94 9501
Trying 172.28.11.94...
Connected to bos-lpjbb (172.28.11.94).
Escape character is '^]'.
203 WELCOME
The warning about select() not working is a little strange, but it seems like it's falling back to poll(), which should be fine. But I can't figure out why it can't bind to port 9500 when I run it as root, as I'm doing here. Any help would be much appreciated!
The very helpful guys on the HAProxy mailing list pointed out my problem: the first line of my server stanza is:
listen rtt 172.28.11.94:9500
This is telling HAProxy to bind to 172.28.11.94:9500, and then the "bind" line in my config file is telling it to bind a second time to that same point - hence the error. I changed the first line of the stanza to just:
listen rtt
and it's now fine.

hg push Connection refused

I use a http://bitbucket.org private repository, usually works well, but now I can't do push.
When I try get this message:
hg push
remote: ssh: connect to host bitbucket.org port 22: Connection refused
abort: no suitable response from remote hg!
Many thanks.
Connection refused means that either their firewall is blocking you or they are not running ssh on port 22 (the default). I would recommend either contacting their customer support or talk to whomever gave you access.
Since port 22 was blocked, I used the alternate URL ssh://hg#altssh.bitbucket.org:443/account_name/repo_name/ as described here.
I had the same problem, and actually this solution helped me out:
vim ~/.ssh/config
Add these lines and save it.
Host github.com
Hostname ssh.github.com
Port 443
Host bitbucket.org
Hostname altssh.bitbucket.org
Port 443
taken from https://gist.github.com/goddoe/5692bfc3cdc374d918a87882963edf36

netstat says 443 is open, but I cannot connect to it with telnet .. why?

I've built a self hosted wcf server, using wsHttpBinding. I'm running Win 2003 server R2 SP2.
If I configure it to listen on http://localhost:443/MyService, everything works fine. I can connect to http://localhost:443/MyService with Internet Explorer, and I get the standard "Bad Request" message
Now, if I try to switch to HTTPS, I'm witnessing a strange phenomenon.
Here's what I've done :
I've changed my wcf config file from http://localhost to https://localhost and from Security=None to Security=Transport (as explained in numerous wcf tutorials)
I've registered my HTTP port like this :
httpcfg delete ssl -i 0.0.0.0:443
httpcfg set ssl -i 0.0.0.0:443 -h ea2e450ef9d4...
Note that the certificate I've used is a "real certificate" (i.e. issued by a trusted CA, namely Comodo). The server responds to ping on the NS mentioned in the certificate.
Now, the following will timeout :
Microsoft Telnet> open localhost 443
Here's the output from netstat (The Pid '4' is the 'System' process):
netstat -nao
Proto Local Adress Remote Adress State Pid
TCP 0.0.0.0:443 0.0.0.0:0 Listening 4
And here's a screenshot from TCPView captured when I issued the open command in telnet :
alt text http://img26.imageshack.us/img26/3376/tcpview2si6.jpg
I'm a bit puzzled. To me, if netstat says the server is listening on 443, the telnet connection to 443 shouldn't timeout, and I should have at least a blank prompt, expecting me to type some encrypted stuff :)
So far I've tried to :
Redo all the steps from scratch following exactly the MSDN tutorial
Used port 10443 instead of 443
Disable the firewall
Use a self signed certificate
I don't know what to try next .. any ideas?
The telnet client is not going to know to send a properly constructed request to initiate an https handshake, so I imagine the ssl secured server is just waiting for more data.
The telnet client is certainly not going to know what to do with the response from a ssl secured server (it's certainly not going to prompt you for data to send along). Communication can only happen once the https handshake has completed.
You need to use a client that knows how to do a handshake. The openssl binary can do this out of the box.
Telnet cannot be used to comunicate with encrited webs.
Checkout this microsfot note. It says "NOTE: This example assumes that the Web server is configured to use the default HTTP port (TCP 80). If the Web server is listening on a different port, substitute that port number in the first line of the example. Also, this example does not work properly over an HTTPS/SSL connection (TCP 443, by default), because the telnet client cannot negotiate the necessary encryption commands to establish the SSL session. Although an initial connection is possible over the HTTPS/SSL port, no data is returned when you issue a GET request."
Update: Checkout this other note HOW TO: Determine If SSL Connectivity Is Not Working on the Web Server or on an Intermediate Device
As FerrariB said, telnet does not perform the negotiations necessary to open an SSL connection. Telnet knows nothing about certificates, nor encryption. Thus, you are guaranteed to not be able to communicate with HTTPS port 443 via telnet. You will have to find another way to do whatever you are trying to do.
Check out the Wikipedia page on TLS for example, where it says directly:
If any one of the above steps fails, the TLS handshake
fails, and the connection is not created.
This is precisely what you are seeing by trying to use telnet to communicate with an SSL endpoint.
in command prompt: netstat -nao |find "443"
the last columns show a number:
pic no.1
Now open task manager.find result number in 1st section in pid column (if pid wasn't enabled, choose it from view tab) program name show the program which uses the port.
disable the program that uses the port /in my case I stopped it from services