By far, the easiest way is to just copy it via scp. Plus, this syntax actually works unlike some of the other suggestions.
You can't beat this syntax for ease. It allows you to recursively copy, rsync or what ever you'd like without the hassle of considering potentially complex pipes. This syntax is intuitively clear, will be more readily supportable by ...
If the internet is a series of tubes, Unix is a series of pipes -- something like:
cat ginormous-file | ssh user@host1 "cat | ssh user@host2 \"cat >out\" "
If you need to traverse more hosts, add more pipes (and more nested layers of \-escaped quotation) as needed. (Note however that if the pipeline/escaping gets so complex that ...
SSH tunnel isn't really a great idea as a permanent solution. SSH is TCP based. Most things you can tunnel within SSH is TCP based (including mysql). Tunneling TCP over TCP can have performance implications. Because your system will try to handle the backoff and such on both connections at the same time.
If you want a secure permanent connection between ...
If I'm not mistaken, SIT is symmetrical: the same thing is done on both sides.
Configuration should be pretty straightforward:
description 6in4 to <client>
no ip address
ipv6 address 2001:db8:::1/64
tunnel source <local ipv4>
tunnel destination <client ipv4 addr>
tunnel mode ipv6ip
I ended up going with the Ethernet bridging. Lots of extremely verbose examples to wade through online, but it turns out to be pretty easy:
First, on A, /etc/network/interfaces was changed from:
iface eth0 inet static
iface br0 inet static
Here's the issue:
smtpd_helo_restrictions = reject_invalid_helo_hostname,
The last of those, reject_unknown_helo_hostname, tells Postfix to reject mail if the hostname given in the HELO command cannot be resolved. If you remove that, your problem should go away.
You should reverse the ...
You can change your HELO policy to:
...and add your home mail server's address to mynetworks = ... line.
Although the answer by @JennyD is valid and should solve your problem, it can be better to keep your ...
The parameters are basically the same (autossh passes them directly to ssh). Remove -f if you don't want autossh to background itself. You probably want the -N option to not execute a shell on the server. Select a free port for the -M option (the port one above that must also be free). On Debian/Ubuntu you can omit this because the package includes a wrapper ...
The Teredo tunneling protocol will likely do what you want, but you have to work with the protocol in picking addresses; the same is true of 6to4. You have picked your IPv6 addresses out of the air.
The old IPv4 concept, of some private (RFC1918) address ranges which were globally unroutable but anyone could use (including over multiple sites, as long as ...
What you want is not a reverse tunnel but a regular tunnel.
ssh -L 80:someserver.com:80 user@myserver
This will create a listening socket on port 80 of your laptop (localhost) that will go to someserver.com through the SSH server on myserver.
I usually combine tunnels with the options -CfN, -C will enable compression (speeds things up a bit), -f sends the ...
Bind your NAT rule to the IP address openvpn is listening on. Your current rule is intercepting all traffic going through the server with a destination port of 53 (in this case, traffic traversing your tun interface). Always try to make your rules as specific as possible; if you don't, weird things like this will happen.
Try something like this:
What you really need to do is send the traffic over some sort of private network. It's really quite expensive to build your own private wide-area network, so it'd be good if we could utilise the Internet somehow... but then, the private network wouldn't be a physical one, but would instead be "virtual". In fact, that sounds like a really snappy name for a ...
It's an old thread, but I think it's worth posting possible solution.
I had the same issue with several browsers and it turned out to be configuration issue. If that's the case, the following command should work and show IP address of remote machine:
links -socks-proxy localhost:8000 www.myipaddress.com
First comment on the question is correct in that ...
On win7 machine, open putty and set the following settings for the linux ssh session:
Connection->SSH->Tunnels->Source port: 1433, Destination: 192.168.0.3:1433, select local radio button.
Now you should be able to connect to localhost:1433 from the win7 machine.
When you do ssh tunnel it make a encrypted communication between your system to remote server and bind the remote opened port to your defined port.
ssh -L 33333:localhost:3306 firstname.lastname@example.org
here 3306 as you said is mysql port no.
use IPADDRESS instead of localhost i.e 127.0.0.1
Connection to 10.10.0.31 closed.
linux@tuxworld:~$ ssh -fNg -L ...
See man ssh:
-N Do not execute a remote command. This is useful for just forwarding ports (protocol version 2 only).
So, use ssh -N -L 3307:127.0.0.1:3306 remoteserver
Not having a shell with password-based login is not normal, are you sure you didn't change something else as well?
Do you have an existing monitoring platform? For VPN tunnels, I tend not to trigger alerts from the endpoint firewalls (e.g. SNMP), but monitor different sides of the link... A ping check from your monitoring solution is pretty darn good for this, as the tunnel will either be up and passing traffic or down.
Despite this, you can configure email alerts for ...
6to4 using 184.108.40.206 has been deprecated and should not be used anymore. Because it is very unreliable the source address selection mechanism (RFC 6724) specifies that a system should prefer IPv4 over 6to4 if possible.
It is possible to change this in /etc/gai.conf but I would strongly recommend not using 6to4 at all.
Your thought of using a dynamic port forward for this will never work. Think through it logically - you need to open a local port that forwards from your local machine, through hostA, to port 22 on hostB. There are a couple of ways you can achieve this. First, the inelegant, manual way:
First, set up the tunnel:
$ ssh -L2222:hostB:22 user@hostA
From OpenVPN's perspective there's no difference between a site-to-site and client-to-site connection, it's just a matter of the configuration you want. You need to decide whether you can support both with a single server instance, or whether you need two server instances running on different ports.
A site-to-site VPN will typically have iroute directives ...
I agree with CanOfSpam3 that using -D8080 is a better option then setting up a proxy with Apache. However, to answer your question, I would guess you have missed the Listen line in Apache to listen to port 8080 in addition to the usual ones. <VirtualHost> alone does not make Apache listen to the IP:Port mentioned, you also need to ask Apache to listen ...
This is the problem:
with this line you tell openswan that the endpoint of the tunnel is "everything", so all packets are routed through the vpn.
Replace 0.0.0.0/0 with the network(s) you want to reach behind the gateway. The config on the client and server has to match, so edit both.
The autossh utility may do what you want
autossh is a program to start a copy of ssh and monitor it, restarting it as necessary should it die or stop passing traffic.
You should really do the job correctly and create a VPN between the two systems using openvpn (or similar).
as noted in the updates to the question, the problem is that after the kernel passes the packet to whatever raw sockets are listening on that protocol, it then hands it off to any kernel modules registered for that same protocol. since I had been using a sit tunnel on my netbook, the tunnel4 module was still loaded even though I had temporarily set up the ...
Add client = yes to each service to fix that error message.
You also want to set options to set up proper SSL security; see below.
# Enable proper SSL security. Without this, you are completely insecure!
verify = 2
CAfile = /etc/ssl/certs/ca-certificates.crt
options = NO_SSLv2
client = yes
accept = 127.0.0.1:5679
connect = 220.127.116.11:5680
They can't see what you are doing, but they can see how much you are doing something. This means that if you start downloading a file, they will not see where you are getting the file from, but they will see that there was a spike of traffic for your SSH connection.
However, do not forget that they might still see the websites you are visiting if you do ...
Raymonds answer is most likely (without seeing the rest of your config) the problem you're having with the apache portion.
Have you looked at using the SSH Socks tunnel? Instead of -L8080:localhost:8080 you could -D8080, which would using socks let you tunnel anything socks compliant. So for your example, you should be able to ssh -D8080 <server address&...
Use a proxy server installed on either server 1 or 3, configured to allow connections to the sites in sources.list from the private network servers. As a bonus, if you go with a caching proxy like squid or approx you'll use less bandwidth for downloading packages common to the servers.
For regular web proxies like squid, you can either set the $http_proxy ...
The correct command is:
ssh user@server -D 8000
In the case you still can't connect check if another process is using this port. The most easy way to do this is with:
netstat --listen |grep 8000
If that is the case just use another port.