Tag Info

New answers tagged

0

I was getting the same message while SSH tunelling to Debian. It turned out the remote system had no free space. After freeing up some disk space and rebooting, the tunnel started working.


2

If you understand what is going on in X11 forwarding, you will know that it is not so simple as described in the answer from @yaegashi. X11 forwarding is creating another layer under the ssh and it can't be chained as normal terminal data streams. But you are able to do it using port forwarding: Based on this blog post, which does it as hardcoding in shell ...


2

Why doesn't that solution with ProxyCommand work for X11 forwarding? I think you can directly reach mum's computer with X11 forwarding using the following configuration. Host mum ProxyCommand ssh -q -W localhost:1993 login@vps0 ForwardX11 yes


2

Second case is very useful in situation when example.com can connect to [google.com] host while your box can't. For example, you have VPN connection which is restricted to a number of boxes, while you want to access host not in list. ssh -L 123:target.host.com:456 user@vpn.host.com. So, basic usage is to jump INSIDE the network or jump OUTSIDE the network ...


0

A workaround using wait: With wait you could use a PID to wait for: wait $PID, but we will simply use the argument for running our second command. Note that all output must be ignored for not being passed as argument to the wait command (thus leaving us with an argumentless use of wait as in command & wait) process1 & wait $( process2 &> ...


1

This is not answering you question, but this answer on SU is solving your problem, I guess: Using ProxyCommand in your ~/.ssh/config should do everything for you: Host server HostName server.tld User {server user} Host proxy ProxyCommand ssh server -W %h:%p User {proxy user} Then you can access your server simply by using ssh server


0

If I interpret your command correctly, would it not be the same as this? ssh -t user@jumphost ssh user@destination ... All your -L seems to be doing is a port forward to the SSH server of the jumphost - but you're already connecting to that so why the additional tunnel? In this scenario the jumphost would also be the SSH client for the 2nd connection. If ...


0

Hi I have trouble with this as well. Specifically with udisk. (I'm running Ubuntu desktop 14.04) To fix for udisks I did this. Backup and edit sudo vi /usr/share/polkit-1/actions/org.freedesktop.udisks.policy look for all the: <allow_active>yes</allow_active> and then change the: <allow_any>no</allow_any> to: ...


2

Can someone crawl back down your SSH connection and infect your computer? No. Can they see there's a connection from your external IP address then scan/enumerate/potentially exploit your gateway (e.g. router)? Yes. What you should really be concerned with is if the proxy provider is worth trusting with your web traffic. By proxying your traffic through ...


3

There were such examples if you were using X11 forwarding, for example as described in this report: https://thejh.net/written-stuff/openssh-6.8-xsecurity Similar issue was published many years ago: http://www.giac.org/paper/gcih/571/x11-forwarding-ssh-considered-harmful/104780 All these should be fixed now, but using -X forwarding to untrusted machines ...


2

Quoting Comcast Business Internet: Static IP is not supported on retail devices due to technical limitations. Static IP is only supported via Comcast Business CCR & BWG leased devices: CCR (Comcast Commercial Routers: SMC D3G-CCR or Netgear CG3000DCR) / BWG (Business Wireless Gateways: Cisco DPC3939B or Cisco DPC3941B). For more information ...



Top 50 recent answers are included