Tag Info

Hot answers tagged

10

I have drawn some sketches The machine, where the ssh tunnel command is typed is called »your host«. Introduction local: -L Specifies that the given port on the local (client) host is to be forwarded to the given host and port on the remote side. ssh -L sourcePort:forwardToHost:onPort connectToHost means: connect with ssh to connectToHost, and ...


9

From the SSH Protocol documentation, regarding channels: All terminal sessions, forwarded connections, etc., are channels. Either side may open a channel. Multiple channels are multiplexed into a single connection. Channels are identified by numbers at each end. The number referring to a channel may be different on each side. Requests to ...


7

strace -e trace=connect -f yourprogram or using a dump file strace -o yourprogram.strace -e trace=connect -f yourprogram


5

As said in other posts, if you don't want a prompt on the remote host, you must use the -N option of SSH. But this just keeps SSH running without having a prompt, and the shell busy. You just need to put the SSH'ing as a background task with the & sign : ssh -N -L 8080:ww.xx.yy.zz:80 user@server & This will launch the ssh tunnelling in the ...


5

I have drawn some sketches The machine, where the ssh tunnel command is typed (or in your case: Putty with tunneling is started) is called »your host«. Introduction local: -L Specifies that the given port on the local (client) host is to be forwarded to the given host and port on the remote side. ssh -L sourcePort:forwardToHost:onPort ...


4

I have drawn some sketches The machine, where the ssh tunnel command is typed is called »your host«. Introduction local: -L Specifies that the given port on the local (client) host is to be forwarded to the given host and port on the remote side. ssh -L sourcePort:forwardToHost:onPort connectToHost means: connect with ssh to connectToHost, and ...


4

I have drawn some sketches The machine, where the ssh tunnel command is typed is called »your host«. Introduction local: -L Specifies that the given port on the local (client) host is to be forwarded to the given host and port on the remote side. ssh -L sourcePort:forwardToHost:onPort connectToHost means: connect with ssh to connectToHost, and ...


4

Solution 1: From your PC on network A, create a reverse ssh tunnel with something like Putty by connecting to a Linux host on Network B. The local port should be 3389, the remote host 127.0.0.1 and the port is arbitrary (lets use 6000 as an example). Then from your PC on network B, use putty to connect to the same Linux host, and do a forward tunnel. Local ...


4

When you connect to a remove machine via ssh with X11 forwarding enabled, ssh on the server creates a .Xauthority file in the user's home directory. Because ssh listens for X11 on a TCP socket, anyone can connect. Because anyone can connect, we need some way of preventing just anyone from using your display. This is done with that .Xauthority file. The file ...


3

You can do this through ssh's ProxyCommand facility. Add the following to your $HOME/.ssh/config file. Create it if it doesn't exist with just this content: Host remoteserverX User userint ProxyCommand ssh userext@externalserver nc remoteserverX %p Host remoteserverY User userint ProxyCommand ssh userext@externalserver nc remoteserverY %p ...


3

What you're looking for is called a reverse tunnel. ssh provides it through the -R switch: -R [bind_address:]port:host:hostport Specifies that the given port on the remote (server) host is to be forwarded to the given host and port on the local side. This works by allocating a socket to listen to port on the remote side, and ...


3

If tomcat is not listening on loopback (127.0.0.1) then a port forward to that will give the error message you've been receiving. If I do an ssh, with a port forward to a non-listening port (eg: ssh -L1234:127.0.0.1:9999 10.0.0.1 - where no process on 10.0.0.1 is bound to port 9999 on 127.0.0.1) , I get the same error: channel 2: open failed: ...


3

This is what you need. #user@A: ssh -N user@B -L 9999:C:9999 When you connect from A with telnet #user@A: telnet localhost 9999


3

SSH SOCKS5 Tunnelling using PuTTY: Firstly connect to your server via SSH using PuTTY. Right-click on the top bar and hit 'change settings'. Goto Connection/SSH/tunnels. Source port: 4567, select 'Dynamic' and hit 'Add' Open up your choice of browser, and configure the 'Manual Proxy settings' to listen on port 4567 on localhost (127.0.0.1). In Firefox ...


3

When you visit a website (one that's not hindered by your corporate firewall) your browser sends a request to the server listed in the URL on port 80 (by default). For example, to visit this site our browsers communicate with port 80 of the server unix.stackexchange.com When you set your proxy settings you told your browser to send everything to localhost ...


3

Very high level overview: The -D option tells ssh to listen for connections on that port using the SOCKS protocol. You configure Firefox to connect to ssh and speak the SOCKS protocol. You type http://www.google.com into your browser. Firefox connects to that SOCKS port. SOCKS can do a bunch of things, but what we're interested in is this: Firefox asks the ...


2

If the 'remote' cannot be resolved on the server you will get that error. Replace with an IP address and see if that resolves your issue... (Basically same answer as that of Neil - but I certainly found that to be the issue on my side) [I had an alias for the machine name in my ~/.ssh/config file - and the remote machine knew nothing of that alias...


2

If you have a low bandwidth I recommend compression of the video stream: ssh USER@REMOTEHOST ffmpeg -an -f video4linux2 -s 640x480 -i /dev/video0 -r 10 -b:v 500k -f matroska - | mplayer - -idle -demuxer matroska where -an turns of audio encoding. If you want audio, replace -an with -f alsa -ac 1 -i hw:3 (where hw:3 could also be hw:0 or hw:1, … See ...


2

Since computer B cannot access computer A, you will need to open a remote tunnel from computer A first. ssh user@computerB -R vvv:localhost:22


2

ping is implemented in the ICMP protocol, the ports that you forward are TCP ports. So ping is not the appropriate test for this situation, you'd rather have to test with telnet or something similar to check if the connection can be established.


2

I'm not sure exactly what you are asking, but I suspect that you are interested in the ssh -g flag, which "Allows remote hosts to connect to local forwarded ports."


2

A possibility could be to download whatever you need from your client and then send those files by scp to your server if it accept scp. scp file_to_send user@server_ip:/location_of_the_file I don't know if what your asking is possible as your server has no acces to the client.


2

Using an Expect script to send a hard-coded plaintext password is generally a Very Bad Idea. If you needs scriptable, passwordless SSH connections, it's far better to use key-pair authentication: ssh-keygen # and then follow the prompts; don't set a passphrase ssh-copy-id username@remote.host.example.com After doing so, you can ssh ...


2

OpenSSH is secure enough to be accessible over the open Internet, if configured properly. So setting up a reverse tunnel that is publicly accessible is fine, if the forwarded port is secured properly. Some tips for securing OpenSSH: Protocol 2 PermitRootLogin no HostBasedAuthentication no PasswordAuthentication no UsePrivilegeSeparation yes ...


2

You have two options. Either use different source addresses or use a socks proxy. Different source addresses Your lo interface is configured as 127.0.0.1/8, i.e. all addresses starting with 127 do belong to the current host. The syntax for your tunnel is -L [bind_address:] port:host:hostport Therefore you can use something like: ssh -L ...


2

I often do the same thing with LocalForward directives. I also use connection muxing with ControlMaster, ControlPersist, and ControlPath directives; if I want to have a connection that I use just for the tunnels, since my connections' muxers persist for 30 minutes, I can ssh user@hostname.example.com logout and have 30 minutes to open any tunnelled ...


2

Providing you have already set up your tunnel on A to C via B, then You want #user@D: ssh -N user@A -L 9999:localhost:9999 #user@D: telnet localhost 9999


2

Assuming you have: A with ip address ip_A B with ip address ip_B C with ip address ip_C From a first terminal connect to the B and set a tunnel to C on ssh (port 10022 is used for the tunnel but it can be anything else): ssh ip_B -L10022:ip_C:22 Then from another terminal, you will be able to connect "directly" to C from A by using the tunnel you just ...


2

You can do that by using lsof to check which TCP ports are in state LISTEN and used by sshd: [jenny@willow ~]$ sudo lsof -iTCP -sTCP:LISTEN | grep sshd sshd 1084 root 3u IPv6 0xffffff0003fed888 0t0 TCP *:ssh (LISTEN) sshd 1084 root 4u IPv4 0xffffff0003fed5b0 0t0 TCP *:ssh (LISTEN) sshd 47607 jenny 7u IPv6 ...


2

First, set-up squid - sudo apt-get install squid Follow the directions at the above link to configure it. Allow only localhost to be secure. Then, set-up port-forwarding - from local port 3128 to remote port 3128 (to use the squid defaults); then configure your web-browser to use port 3128 and localhost as your proxy. Requests will go over the ssh port ...



Only top voted, non community-wiki answers of a minimum length are eligible