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!
Related
I just installed a Gitlab on my VPS (at gitlab.mydomain.com). Thing is I can connect to it through HTTPS but not through SSH, even if I add a generated SSH key from my VPS.
My firewall doesn't block connections (I set up my UFW to allow connections on port 22)
When doing systemctl status ssh after I try to connect to my Gitlab, I can read things like :
Failed password for root from x.x.x.x port xxxxx ssh2
Received disconnect from x.x.x.x port xxxxx:xx: [preauth]
fatal: Timeout before authentication for xx.xxx.xxx.xx port xxxxx
I'd like to find a solution or to know if somebody already faced this problem (and how did you solve it by the way !)
I also did try to connect from different connections (Wi-Fi, 5G, ethernet) and none of them did work.
I can give more details if needed.
Thanks by advance,
Thibault
I would like to login to another server via ssh via a jump sever. I would like to run system tests on the sever and receive their evaluation / result. The whole thing should take place automatically and I don't want to have to copy the individual test files to the target system.
my_compuer --SSH--> Jump_Server --SSH--> Server(run system tests)
For security reasons, tcp forwarding is disabled in the sshd config of the jump server.
A dedicated username and a public key are required for both ssh connections.
The establishment of an SSH tunnel does not work due to the missing tcp forwarding. Here I get the error message "channel 1: open failed: administratively prohibited: open failed". When I active tcp forwarding the ssh connection is working as expected.
Would ssh proxy represent a possibility to enable an ssh connection with deactivated tcp forwarding? Which additional authorizations would be required here on the jump server?
What furhter options would I have?
I was updating the ssh port of an Oracle Cloud Infrastructure machine
I changed /etc/ssh/sshd_config
The port was
#Port 22
I changed it to
Port 40531
Then
restarted the sshd service systemctl restart sshd
open the port on the OCI Web
however, now I cannot connect.
ssh -vvv -p 40531 -i ~/.ssh/vm.key opc#129.xxx.xxx.xxx
OpenSSH_8.2p1, OpenSSL 1.1.1e 17 Mar 2020
debug1: Reading configuration data /etc/ssh/ssh_config
debug2: resolve_canonicalize: hostname 129.xxx.xxx.xxx is address
debug2: ssh_connect_direct
debug1: Connecting to 129.xxx.xxx.xxx [129.xxx.xxx.xxx] port 40531.
debug1: connect to address 129.xxx.xxx.xxx port 40531: Connection timed out
ssh: connect to host 129.xxx.xxx.xxx port 40531: Connection timed out
I saw a Cloud Shell but I'm not sure if it can be used to connect to the machine to perform maintenance tasks
Is there a way to connect to the VM from the web oci interface to fix the ssh issues?
I used to use a VPS service that has a web console from which you can enter to fix problems like this
is there something like this in OCI?
Note:
SELinux was disabled on the machine
if you are about to do this on your machine, remember to update the SELinux configuration prior restart the sshd service or you will be locked out, another option is to disable SELinux totally (this is what I did)
The changes above described worked well, the only thing that was causing issues on my side
(I don't really know why) is that I was connected from a VPN
After I disconnected the VPN and tried to connected again it worked
Update:
I figured out why the ssh using a different port was not working. The VPN I use is a corporate VPN which has very strict inbound and outbound rules, The VPN outbound rules were blocked by the TCP on port 40xxx.
Update:
if you are struggling with a VM you can connect using the below instruction
Creating the Instance Console Connection
Before you can connect to the serial console or VNC console, you need to create the instance console connection.
To create the console connection for an instance
Open the navigation menu. Under Core Infrastructure, go to Compute and click Instances.
Click the instance that you're interested in.
Under Resources, click Console Connection.
Click Create Console Connection.
Upload the public key (.pub) portion for the SSH key. You can browse to a public key file on your computer or paste your public key into the text box.
Click Create Console Connection.
When the console connection has been created and is available, the state changes to Active.
Thanks to #bmuthuv for the info
You can connect to Serial Console of the VM where you could get access to GRUB Menu during a Reboot operation. You can subsequently use typical Linux commands to get to Shell from Grub. You can subsequently undo anything you would like to.
Serial Console connection can be created on OCI Web Console in the Instance's page.
I have an API server (Debian Apache2) with OpenSSL installed and working. I also have a staging and production web server (also Debian Apache2, exactly the same spec - they are VM clones). All servers are on the same subnet. I can browse to the wsdl from my local machine on 443 successfully, and I can wget the wsdl successfully from my staging server on 443, but a wget from my production web server will not connect:
--2015-04-16 10:26:18-- https://www.example.com/index.php/api?wsdl
Resolving https://www.example.com (https://www.example.com)... XX.XX.XX.XX
Connecting to https://www.example.com (https://www.example.com)|XX.XX.XX.XX|:443... failed: Connection refused.
I can connect over https from a PHP nusoap client on staging no problem, but the same code on my production server returns:
wsdl error: HTTP ERROR: cURL ERROR: 7: couldn't connect to host
url: https://www.example.com/index.php/api?wsdl
content_type:
http_code: 0
header_size: 0
request_size: 0
filetime: -1
ssl_verify_result: 0
redirect_count: 0
total_time: 5.272228
namelookup_time: 5.271805
connect_time: 0
pretransfer_time: 0
size_upload: 0
size_download: 0
speed_download: 0
speed_upload: 0
download_content_length: -1
upload_content_length: -1
starttransfer_time: 0
redirect_time: 0
certinfo: Array
primary_ip: XX.XX.XX.XX
primary_port: 443
local_ip:
local_port: 0
redirect_url:
An openssl s_client -connect from both web servers produces the same output.
After my production server returns connection refused, there are no new entries in the API server's error.log, therefore this must be a client issue.
Is there a Debian-specific/internal firewall config I may have inadvertently changed that would prevent the one client from connecting to a secure web server over HTTPS and not another?
"Connection refused" usually indicates a failure to complete the initial TCP connection. Things to check include:
iptables, firewalls, hosts.deny
is apache listening on the interface/ip address the is attempting to connect to?
Does wget or curl work from the local server when you use http://127.0.0.1/ but not http://THE-SERVER'S-PUBLIC-IP-ADDRESS/ ?
What do you see when you run wget with --debug and --verbose ?
Does anyone know why I am unable to connect to my server using the Notepad++ NppFTP plugin with SFTP?
I have a CentOS 6.4 server with SSH on port 22.
When I try and connect using NppFTP I get the following output:
[NppFTP] Everything initialized
Connecting
[SFTP] Connection failed : Error reading socket
Unable to connect
Disconnected
This used to work when I had my SSH port set to 3264 but when I changed the SSH port back to 22 NppFTP stopped working. All the settings for the profile are correct including the right IP, username, password and port (22).
I can connect with SFTP using FileZilla and WinSCP successfully with these same SFTP details and I can connect with SSH using PuTTY.
I can connect with SFTP to other servers using NppFTP so I believe there is an issue in my server config I'm just not sure where or what.
I looked at the access logs but found no attempt at a connection from NppFTP, I turned the firewall off and still nothing.
In the end I got in touch with my server company and it turns out it was a problem on their end. This is what they had to say:
"This was caused by an IPS rule inspecting the network packets coming into the infrastructure, which helps identify brute force attacks."
Very strange, but after they made the change NppFTP can now connect successfully.