I am using Little Snitch to control my local applications' internet connection. But when I am at the University, I have to tunnel via ssh to a network-server in order to get an internet connection there.
The problem: If I do so, Little Snitch is not able to control my applications anymore, because then every application uses my ssh tunnel. What's the best way to handle that? Should I block ports on my ssh or is Little Snitch able to manage this?
I am using a Mac and open the ssh connection over the terminal with the following line:
ssh -D 2001 -o ServerAliveInterval=60 username#servername.com
If you use mac MacProxy and for Windows Proxifier are easiest solutions with more benefits. in addition to blocking any program from connecting to your SSH Tunnel you can also set direct access to your internet for some other programs.
Also you can specify ports and/or IPs for each program and lots more...
Related
I have been playing with the Termius app on Android running downloaded shell scripts that I wrote, catting files and snooping inside my device's directories; among other goofy stuff.
I have seen in some tutorials that I can remote SSH into my computer's terminal and run commands into my Android's Termius as if I'm typing on my computer's keyboard.
Having attempted these instructions myself, I've found they're no good (IMHO) and I couldn't make them work. Also, these tutorials have no good explanation for how I am actually SSHing using the Termius app.
The question is: How do I make it work and how does it work?
You would need to:
generate a key on Termius (and export it)
add that key to your Mac or Linux remote user ~/.ssh/authorized_keys
connect to the remote computer using ssh remoteUser#remoteIP
That assume you have an ssh daemon listening on that remote computer.
I am fairly new to this business and I fail to understand how to SSH from my win10 machine into my installed wsl2 ubuntu 20.4
Basically, I followed this tutorial, But I keep getting the following errors:
when I try to SSH using the public port (using curl ifconfig.me) gives me the error "connection timed out"
when I try to SSH using the private port (using ip route get 1.2.3.4 | awk '{print $7}') it gives me the error "Permission denied"
at some point I got the error "sshd: no hostkeys available -- exiting" so I followed this fix but then I got the errors mentioned before. Should I delete any from the /etc/ssh folder?
The end-goal is ssh'ing through vs-code, but I guess once I could do it from powershell, it's the same from vs-code.
It appears that you need to enter /etc/ssh/sshd_config (with sudo permissions) and change the following lines:
ChallengeResponseAuthentication yes
PasswordAuthentication yes
Since you seem to have fixed your issue with ssh, let me propose that your ultimate goal ("ssh into WSL from VSCode) might be better accomplished using Microsoft's "Remote Development" extension pack, which includes several extensions. While it sounds like you are considering using the "Remote - SSH" extension, you can also use the "Remote - WSL" extension directly.
After installing either the extension pack or the WSL extension directly, just open your WSL instance, cd to the directory with your code and then code . (including the period). This will open VSCode and install a shim into the WSL instance which will allow communication between the two.
See the docs from Microsoft for more detail.
Also, on the topic of your original question, you said that you edited sshd_config to permit password authentication (I don't think the ChallengeResponseAuthentication change was necessary). That's one way to go, but ultimately I'd recommend generating an SSH key pair, copying the private key to something like C:\Users\yourid\.ssh\id_rsa and using that instead of a password login.
And you mentioned in your original question that you were unable to access SSH on the public port. This is because WSL2 does not do NAT, so it also won't be accessible from a second computer without (a lot of) additional effort (manual port-forwarding from Windows to WSL, which will have to be reset on reboot since the WSL interface address will change).
As you've discovered, the WSL interface address will work, but remember that it will change on each reboot of Windows (technically, I think, any time the WSL subsystem is shut down and restarted). IMHO, you're better off using 127.0.0.1 or localhost.
But really, my preferred method of accessing WSL remotely is to install OpenSSH on Windows 10, port 22. Then you can simply do something like ssh -t windowsusername#mycomputername.local wsl to get access to the WSL instance. You can even do this when you have multiple WSL instances on your machine with ssh -t windowsusername#mycomputername.local wsl -d WSLInstanceName.
If you use this technique, of course, and you still want to run an SSH server in a WSL instance, you'll need to use a different port. But I really think you should do this anyways when running SSH under WSL. Otherwise, you are likely to spin up a second WSL instance at some point and run into port conflicts anyway.
The downside is that the Windows OpenSSH -> WSL hack won't allow you to run things like VSCode through SSH, but it does provide super-simple access to WSL through SSH, and works remotely (if you ever need that) as well.
I have access to two supercomputing resources between. I know that the command structure should look like:
scp -r cwr0408#oakley.osc.edu:/fs/lustre/cwr0408 /scratch/gfm12
OR
rsync -auv -e ssh --progress /source/dir/ user#dest.com:/dest
As far as I can tell there are three ways to do this:
From the terminal in the local machine calling the two remote machines with a VPN connection to the network where the network restricted machines is
This type of command would likely require the Cisco VPN client to interact with rsync or at least be running before calling rsync.
From the terminal in the remote machine via ssh which has no VPN requirements
The supercomputer without VPN requirements does not have the Cisco client installed, and all attempts to install it fail without root.
From the terminal in the remote machine via ssh which has VPN requirements. This is the most feasible.
I made attempts at the first and the third to no avail. Has anyone done this successfully? What about in the case that both systems require separate VPNs?
If I understand you, 1 super computer cannot access the other super conputer because of the VPN. Your desktop can access both super computers because you have the Vpn on your desktop.
Have you tried something like this?
ssh you#machine1 'tar cf - stuff-to-send' | ssh you#machine2 'tar xvf -'
Of course, that runs everything through your desktop, but that may be unavoidable.
I have an xterm window open on a computer. I want to access this xterm window remotely using ssh. Is it possible? By access I mean, I should be able to run commands on that open shell.
I'm not sure if it is possible to access an xterm window that's already been opened, while being over ssh. However, you can certainly open an ssh connection with X11 forwarding capabilities. Once X11 is forwarded, you can just run the program in ssh's command line, and it'll open in your forwarded X11 screen.
Here's a good article that explains in detail what you need to accomplish this: http://www.math.umn.edu/systems_guide/putty_xwin32.html
For example, after completing the details in the above article, and assuming you have Gnome Desktop installed, you could run gnome-terminal over ssh and have a Unix terminal open and forwarded over the ssh connection. Pretty much any application that has a GUI is runnable this way.
I need to run some scripts in a windows remote machine from a terminal linux, I've tried using telnet however in the windows machine it's unable and there isn't installed a ssh server. So I need other way to run the command remotely without a graphical interface.
I have the possibility for run the command from a windows machine, however I need to open a SSH Tunnel to see the remote machine, I've used psexec but it didn't work for me.
Do you have access to install software on the remote server?
Your SSH client will not be able to connect to the remote machine unless that machine is running an SSH server to respond to your client's connection request.
There are a number of possible options for SSH servers to run on Windows.
(Google for ssh server windows)
Because SSH gives an external user some access to/control over your server it is designed to be a secure tool. I would therefore recommend using an SSH server which is still actively maintained, and keep it up to date. Servers which are old and no longer supported are are likely to contain known security issues which may never be addressed, thereby leaving your server vulnerable.
There are a number of good free open-source solutions for this, so you shouldn't need to buy anything.
In the past I've worked with Windows machines running Cygwin, with the OpenSSH ssh server installed. Depending how much of the Cygwin system you choose to install, it can make the target Windows host rather like logging into another Linux box in terms of environment.
You can download the installer for Cygwin from http://www.cygwin.com/