I have the following problem I'm trying to solve.
I wanted to use deployHQ to deploy code on commits to my repository.
deployHQ configuration asks for Hostname Port Username and no-password.
deployHW are using Keypairs for identity validation (and authorization), so deployHQ provide me with a public-key to setup in my end machine authorized_keys store.
But, my machine is on a Private VPC in AWS.
So, I thought I can setup an SSH proxy, that operates on different ports.
Each port would proxy the connection to a different machine on the Private VPC part.
But, I am literally clueless on how to do it!! I understand it's not SSH tunnelling, and not TCP forwarding, but nothing really works for me.
The general idea is simple:
SSH using port 18022 to my bastion/proxy to funnel the communication to 10.10.0.2:22 in AWS Private VPC
SSH using port 18023 to my bastion/proxy to machine B:22
SSH using port 18024 to my bastion/proxy to machine C:22
SSH using port 18025 to my bastion/proxy to machine D:22
If anyone knows how to do this, or, thinks of better idea, I would really appreciate the help.
So... the solution to this is actually very simple...
Setting up reverse NAT on IpTables on the Bastion, pointing external ports to resolve to 22 on different servers.
Super simple.
Related
So I am pretty new to all of this and currently learning about ssh and NAT.
So I have a VM setup on Azure and in order to connect to it I need to ssh into it. But the problem is I am unable to ssh into it because I am behind a NAT as I am currently studying in a University, hence getting "connection timed out" error all the time.
Also I have tried changing the default port(22) to 443 or 80 still same error which confirms I am behind a NAT.
So currently the only way to ssh is to use a VPN which works fine.
But after researching a bit I found that I can also use Reverse SSH Tunneling to achieve the same but couldn't figured out a way of how to do it. I know it is a bit riskier than using a VPN only but anyway just wanted to try.
So can anyone help me?
An outgoing SSH connection (your machine -> Azure VM) should not be affected if you are behind a NAT. NAT usually blocks incoming SSH access to your machine not out from it.
Also I have tried changing the default port(22) to 443 or 80 still the same error which confirms I am behind a NAT.
You changed the default port on which machine, you or the Azure VM? Changing the default port on your machine will not affect the outgoing SSH connection as it is only for incoming SSH connection to the SSH server on your machine (if you have one running locally).
Your best bet would be to actually look at the security groups of the Azure Virtual Network you VM is located in. Make sure it allows incoming SSH connection on port 22 to your VM.
I've been having problems SSHing into my work computer from home. I have been able to succesfully ssh into one of our web servers so I know the ssh daemon is working and my connection is at least allowing some ssh. But when I try to ssh to my work computer it times out.
I went to my University yesterday and I was able to succesfully ssh into both the web server and my work computer. I've looked into our firewall at work to see if there are any blocks on my IP but it isn't blocked.
My ISP is comcast if that helps at all. I've done a few google searches and some comcast customers say that comcast sometimes blocks file sharing ports such as the ssh port (22).
Any help would be appreciated. Thanks.
First check the /etc/hosts.deny file of your work computer. That may contain lines which might suggests that certain IP may be blocked. Then check /etc/hosts.allow file. You can add your home-computers outgoing IP to your work computers /etc/hosts.allow.
NOTE: This question should belong to superusers or serverfault. stackoverflow is for questions that involves coding...
There is not one single "ssh daemon"... there is one running on each host to which you connect successfully. If you cannot connect to a host there are two primary reasons:
There is no SSH daemon running on the host. In that case you will likely get "connection refused"
There is a firewall between you and the host, and it is not allowing port 22 to pass through. In that case you will likely get timeouts.
If you are trying to connect to a host behind a firewall from "outside", as you suggest, it is extremely likely that host is not reachable from the Internet. If the IP address of the "work computer" looks like 192.168.x.x or 172.[16-31].x.x or 10.x.x.x then it is an unroutable private address and you will not be able to reach it from the outside no matter what you do unless a specific port-forwarding rule is set up on the firewall; in that case you would be connecting to the firewall's IP address, not your target host.
I created a VM in a VPN in Windows Azure. I added TCP endpoints for the particular machine which runs server 2012. But everytime I run a small program listening on TCP like the example in nodejs, any client simply refuses to connect. This happens even when I disable the firewall? I tried with linux (ubuntu) too. Can someone help me out and let me know what steps I am missing? I connected with:
server1.cloudapp.net:tcp_port
RDP and SSH work fine through TCP.
Here are a few things to check, which may provide more clue.
1) double check your endpoint, make sure the public port and private port are set correctly
2) rdp to the VM and do "netstat -an" to check if the port is indeed listening
So i've setup a windows instance, but can't seem to FTP into it. After much research, i've discovered SFTP is the way forward.
I've setup my security group, adding the following rule:
SSH tcp 22 22 0.0.0.0/0
Using the public DNS name supplied in the console, i try to SFTP in using Filezilla & Cyberduck, but they just time out.
I know the next step is sorting out the key pairs, but i doubt that'll do me any good if my server isn't even accepting connections.
Any idea what i've missed?
EDIT:
Looking at the Filezilla logs, its looks like the server isn't responding to the connection requests...
12:51:29 Status: Connecting to ec2-122-248-248-178.ap-southeast-1.compute.amazonaws.com...
12:51:29 Response: fzSftp started
12:51:29 Command: keyfile "D:\Users\berling\Lacie Fuj Sync\Freelancing\AWS_Public_Key.ppk"
12:51:29 Command: open "greg#ec2-122-248-248-178.ap-southeast-1.compute.amazonaws.com" 22
12:51:49 Error: Connection timed out
12:51:49 Error: Could not connect to server
Do i need to install an SFTP/SSH server on the server? I was under the impression it was already setup for Amazon servers for some reason... am i wrong about that?
The rule you have set up - SSH tcp 22 22 0.0.0.0/0 - where is that? Your firewall, or at the EC2 end? And why 0.0.0.0? I would recommend using real IP addresses.
Check why the connection is timing out - is SFTP getting past your firewall? Is it getting blocked at the EC2 end - firewall or network logs will be your friend here.
Have you confirmed it is timing out before starting the handshake? Check SSH logs.
Do you have an SFTP server running and configured correctly? Some require all configs to be set before they are happy - your comment that you haven't yet sorted key pairs makes me wonder if this one only accepts certificate auth.
Check those and see how you do.
Install WinSSHD on your EC2 instance. It provides RDP, SFTP, Console access - all over port 22.
Install Tunnelier on your client.
I haven't tried this particular package, but Cygwin, and Services for Unix provide OpenSSH version.
Copssh claims to install openssh, and allow migration/configuration of users:
http://sourceforge.net/projects/sereds/files/Copssh/4.0.4/
We have a local server with SVN installed on it that we are using for development/testing purpouses. We would like to checkout the data from it to the live server that is somewhere out there.
The only way to do that which I thought of was to use "svn checkout" from the live server, right? This way we do not need to FTP the changes to it, that may cause problems is we forget to upload some of the changes. And if we found a problem we can alway go back to previous stable version, right? Correct me if I am wrong about any of these.
The problem is that our local server (Ubuntu) does not have a IP that is reachable from outside. We have a router from out ISP, but we can not use that to access the local server from the live. We are willing to ask the ISP provider to setup a second IP for the local server, but for security sake they want to setup a separate machine with Windows and windows base security software (firewall - http://www.kerio.com/control/ and antivirus) that will cost us a lot. Can we just setup a free firewall on the local server (Ubuntu as I said) and solve the problem without spending additional money?
I hope I was clear.
It's always hard to comment without knowing the exact situation, but this sounds a bit crazy.
What you would usually do is set up port forwarding for one port to the local server. The server would then be reachable (for example) through 123.45.67.89:3690
That's a three-minute task to set up in a normal household router.
As long as the Ubuntu server is closed otherwise, and Subversion or whatever you are using for authentication is properly configured and up to date, this should not create security issues.
In any case, putting a Windows machine in between to act as a firewall sounds really unnecessary. Ubuntu comes with everything necessary to secure the setup properly.
If the remote server has an ssh server, then you can use ssh forwarding.
From the internal svn server:
ssh -R 7711:localhost:3690 {REMOTE_SERVER}
7711 is an arbitrary port (you can use any free port on the remote system) that will be forwarded from the remote system to port 3690 (svn) on the svn server.
3690 is the port on the internal svn server that you want to talk to (via svn://).
If you are using subversion over http:// then use port 80 instead of 3690.
If you are using subversion over https:// then use port 443 instead of 3690.
After setting up the forward, then you can do this on the remote system:
svn checkout {SCHEME}://localhost:7711/{PATH}
{SCHEME} is svn, http, https, etc.
{PATH} is the normal svn path you want to check out.
Notes:
the forwarded traffic is tunneled through the ssh connection (on a different "channel") so it is also encrypted which is a nice benefit.
by default, the remote end of the forward will listen on the loopback interface so only processes on that system will be able to use the port forwarded port.
As soon as you close the ssh session, the forwarded port will also close. It only lasts the duration of the ssh connection.
ssh forwarding is very powerful. If you can ssh between two systems, then you can get around any sort of connection problem like this.
Do man ssh and read about the -L and -R options.
Useful links about ssh forwarding:
http://www.rzg.mpg.de/networkservices/ssh-tunnelling-port-forwarding:
http://www.walkernews.net/2007/07/21/how-to-setup-ssh-port-forwarding-in-3-minutes/
check if your ISP router provide some port forwarding abilities,
You should probably forward the ssh port ( after ensuring that everyone password is secure/or enforcing login with ssh keys file), and use SVN+SSH protocol to access your repository.
You should be able to open up and forward a single port (3690 by default) on your existing IP to the local server, as pointed out by Pekka. This depends on your router, and your ability to access the configuration interface on the router.
Instead of having to deal with SSH and worry about people trying to access your local server from anywhere, you could setup a firewall to only allow incoming traffic from your single remote server. Depending on the router setup, you could simply use the builtin firewall on the local server. It would still be advisable to have some svn authentication, though.
The SSH forwarding method described by kanaka prevents the entire issue about remote access to the local machine, but it requires you to execute the forwarding command from the local server every time you need to access svn on the remote server.