I want to access my work computer, which is behind a firewall, from my home computer.
As the work firewall blocks unexpected incoming connections, I would have to open a reverse SSH tunnel from my work computer to my home computer like so:
ssh -R 12345:localhost:22 homeuser#homeip
From my home computer, I could then use port 12345 to access the work computer:
ssh -p 12345 workuser#localhost
The problem is that this requires me to open holes in my home firewall and forward ports to my home computer.
This is my question:
Is there any method by which I could have both machines meet each other half way?
Assuming that I am at my home computer and a co-worker is at my work computer, and we both know each other's local IP (that the computer gets from the router) and internet IP (that the router gets from the ISP), is there some way each of us could initiate an outgoing connection to the other?
No. If you don't want to forward ports in routers, then you need some mutually accessible computer in between for both computers to connect to. (This could be a virtual machine such as those offered by Digital Ocean, or a web host that offers shell login, or you could dedicate something like a Raspberry Pi on your home network with SSH forwarded to it so it's always available.)
If you wanted to access port 22 on the remote computer:
ssh -R 12345:localhost:22 user#your.sshgateway.com
Then on the home computer:
ssh -L 2222:localhost:12345 user#your.sshgateway.com
Then you can connect to the remote computer with:
ssh -p 2222 workuser#localhost
Related
Really hoping someone here can point me in the right direction,
Expected result: SSH successfully into a remote device.
Challenge/Back story:
We have devices out in remote places around the country,
These devices do not have a fixed public IP address
(Using GSM as its internet breakout)
These devices are able to SSH and break out.
My thought, with regards to maintaining these devices is to (if possible) use a server in the cloud as a middle man, have these devices create some sort of a reverse tunnel to our middleman server then have us as admins intercept it or something to that effect.
Again to summarize, Device cannot be ssh'd into directly, but can breakout.
Aim to be able to hit their terminal from the office.
have been looking at mitmssh but not coming right on that front.
Server A (no fixed address, cannot SSH into it directly but has breakout)
Server B (standard server which can be used as a middle man
Server C (Us admins)
Tried something along the lines of "ssh user#serverA -R serverB:12345:ServerA:22"
Which creates the tunnel, but struggling with grabbing hold of that SSH connection.
I think I regularly use something very similar. My target machine connects to the machine with a stable address with:
ssh midpoint -R 2022:localhost:22
my ~/.ssh/config file knows the real HostName. My config file on my work machine defines a ProxyCommand option to use this tunnelled TCP connection. like:
Host target
ProxyCommand ssh -q midpoint nc localhost 2022
the reason for using netcat was to get ssh-agent behaving.
I've just been searching around and it seems OpenSSH now has specific handling for this (-W command line option, and JumpHost in the config file). E.g. https://stackoverflow.com/a/29176698/1358308
I am aware of how to access my router under normal circumstances (simply entering your public IP address), however I have forwarded a few ports to a web server that I have setup. Ports 22, 80, 8080 are all forwarded (for different reasons), and my public IP is set up through a DNS system.
Now when I attempt to access my router settings (through my public IP) it re-directs me to my website. I tried entering:
PU:BL:IC:IP:8080
and
PU:BL:IC:IP:80
with no success. I did attempt to disable my web server (which I still have access to) and that also failed. Is there anyway around this without having to go home and change setting manually. I have DMZ disabled if that's any help.
You have forwarded port 22, which is usually the SSH port. There are three ways to access your router from SSH:
Use SSH port forwarding to poke a hole through the router to access you're router's admin interface from the local computer. To do this in OpenSSH from the command line, you would use the option -L 12345:router-ip:80. In PuTTY, you would use the Connection/SSH/Tunnels category to add a local forwarded port with source 12345 and destination router-ip:80. Then you can access your admin interface from your local machine by browsing to http://localhost:12345. If your router uses a different port than 80, change that in the examples above. If you want to use a different local port than 12345, you may change that as well.
Use a text-mode browser, such as lynx or elinks, from the SSH connection. This is the simplest to set up, but using modern web apps in text-mode browsers can be difficult or impossible.
If you have an X server running at your current location, use SSH's X11 forwarding to run a graphical browser. Use the -X option for OpenSSH at the command line, or check the X11 forwarding box in Connection/SSH/X11 in PuTTY.
I have my beaglebone black running stock Angstrom Linux and is connected to ethernet at my home. I can login from any PC connected to my home network using SSH. I would like to know how can I login from another network, say I am at my office and I am connected to internet. I want to login into my beaglebone black which is connected to internet at my Home. How can I do this?
Thanks in Advance
You have a public IP address, that is given to you by your Internet operator. This public IP however will be different than the IP of your Beagle in your local network.
To login to your Beagle from the Internet, you need to connect to your public IP address, and need to add port forwarding to your router, so that port 22, which is the socket port that is used by ssh, is forwarded from your public IP to your local IP.
So, you need to login to your router management console, and go to "port forwarding" options, and select to forward TCP/IP connections to port 22 be forwarded to your Beagle IP. For this to work longer term, you should set static IP address to your Beagle, otherwise if your board stays offline for long time, the DHCP server on your router will probably assign different IP at some point, and the forwarding would need to be setup again.
There is a good guide on the static IP address setting in Beagle/Angstrom here: http://derekmolloy.ie/set-ip-address-to-be-static-on-the-beaglebone-black/
One more thing: Since your operator will also assign different public IP for you from time to time, you might want to have some kind of Dynamic DNS service in use. With this kind of service, you can create your "custom" DNS address (for example user3180454.no-ip.com), that will always point to your Public IP address to which you can create ssh connection (the service will require some method to keep this IP address up to date, you will see instructions on how to do it from the service you use).
Couple services like this:
http://no-ip.com/
http://freedns.afraid.org/
You might also want to try out the Weaved connection service installer for BeagleBone Black. I'm using it to connect:
SSH on port 22
BBB web server on port 80
tightVNC server on port 5901
Shell in a Box on port 4200
Apache web server on port 8080
See:
https://developer.weaved.com/portal/members/betabeagle.php
If you are:
Connecting to from a BeagleBoard via USB Ethernet
from Mac Air running Mavericks & connected to web via Wifi
I found this very helpful:
http://makezine.com/2012/07/16/use-your-mac-laptop-as-a-wireless-proxy-for-raspberry-pi/
In short >> install/run a proxy server (with Squidman) & your life will be easier.
I know this is an old question. But I thought I'd suggest another option. I use TeamViewer (https://www.teamviewer.com) to connect to my work/home computers. You could use something like this to connect to your home computer from the office. Once connected to your home computer, you could then do whatever you need to do on your home network. No port forwarding required.
I have the following network:
PC1 --|¯¯¯¯¯¯¯¯¯| |¯¯¯¯¯¯¯¯¯|-- board2
PC2 --| gateway |-- (eth0) [server] (eth1) --| gateway |
PC3 --|_________| |_________|-- board1
As you can see, the server (running Linux) has 2 interfaces so that the PCs and embedded boards are not on the same subnetwork.
I would like to develop a simple application (or use an existing one) that tunnels incomming Telnet connections from eth0 (using a specific port) to boards through eth1.
I don't have root privileges on the server, but I have a regular Unix account. I don't want the PCs to actually "log in" to the server; I just want them to pass through it to connect to the boards. The server has Python, PHP and Perl installed.
I want to support multiple connections. The port number could be used to forward the connection to the right board (say I have 10 boards, then the tunnel listens on ports 3000 to 3009).
I can imagine a simple Web application to do that, but I want a native Telnet connection that will support CTRL+C and all that stuff and allow you to use any terminal emulator on the PCs (i.e. PuTTY or another one), which run Windows.
Any help would be much appreciated.
It sounds like you're looking for a TCP proxy. A proxy accepts connections on one port, connects to another ip/port, and then passes traffic back and forth.
If you have xinetd on your system you already have what you need. The redirect directive for a service causes xinetd to open a connection to another host/port and act as a proxy. See this document for an example.
balance is another very simple proxy tool that will do what you need. This is probably easier to run as a non-root user, especially since it's configured entirely on the command line.
Since you're not root on your server you'll need to run these on ports > 1024, but otherwise you should be all set.
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.