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.
Related
Replit's terminal provides a lot of features that are very similar to any Linux terminal. At first, I thought the site was using SSH to link a remote terminal to the website but when I ran the following command service ssh status, then the output was
* sshd is not running. This indicates that the site is not using SSH to link the terminal.
Does this mean the developers have created a custom terminal for their website or is there a way to show this output for remote users for security purposes?
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 PyCharm Pro. I am trying to do remote development on a server. I have read the following Jetbrains tutorials:
Deploying Applications
Remote Development on Raspberry Pi
as well as the very helpful tutorial:
Remote debugging with pycharm the missing tutorial
While I seem to be able to set everything up, authentication fails when I try to connect to the remote server using the 'SFTP' protocol. I can make an SSH and SFTP connection from the CLI in a terminal so I know the ssh configuration settings are correct. However, in my case authentication requires ssh and having a Yubi key connected to my laptop. Does that make a difference?
Has anyone had a similar issue? If so, how did you resolve it?
On MacOS the challenge is where the IDE is getting it's ssh socket agent. To make this work in my case I have to launch the PyCharm Pro IDE from a terminal.
Go to '/Applications/PyCharm.app/Contents/MacOS' directory and launch with './pycharm'
I am trying to remotely access a Jetson Nano from my mac. So far I have done the following:
I installed microsoft Remote Desktop on my mac
I connected the nano with my mac through the Micro-usb Port
In network I could see the connection "linux for Tegra" where my nano would be 192.168.55.1
With this I still cannot remote access the nano
So I open a terminal and typed
>ssh username#192.168.55.1
and I could access the nano terminal.
So I think now, I have to do
>sudo apt install xrdp
in order to be able to remotely access the GUI.
However, the nano does not have internet connection.
Is there a way that it can use the internet connection of my mac to do this?
(I am reading a tutorial on Rasppi with windows and apparently this is possible)
One of the approaches is to install X server for mac and then use ssh -Y username#192.168.55.1. You will get the command line shell first but you can type in commands like gedit - they windows will show up on the host.
192.168.55.1 is the same network as any other. All tools supposed to work over TCP/IP should work with it as well.
USB is a Serial connection by default.
On windows use a putty based tool.
For example start with MobaXterm > New session > Serial #11500
Login
Password
It won't forward internet by default.
Best simple way is to plug in your phone as USB network sharing and plug in to the laptop via micro-USB.
For Linux, Ubuntu, use a serial ("COM" related stuff) tool.
If you want to do ssh through USB it will require custom editing of networking file.
By default Nano is using a bridge called L4TBRO on 192.168.55.1, laptop is client in .100.
DNS server is on Nano's side.
You would have to create a new interface but using your laptop as DCHP and DNS servers.
Note that usb can power the Jetson Nano for continuous execution on a recent laptop. Some recommends not to and it may crash if you run a compilation on all cores. (if it crashes, just disable 2 cores via nvpmodel -m 1)
We wrote a small prototype web app using Pharo and Seaside and we want to now demonstrate to the suits that the app can be deployed into our standard Linux build. We use a mix of CentOS, Ubuntu Server and Gentoo which are run headless since most of our apps are JAVA/Apache based. Only port 80 and 443 are open to the outside world.
What are your experiences when hosting Seaside/Smalltalk server side apps?
it runs great, btw you can get free hosting for your seaside app at:
http://www.seasidehosting.st/
for more power you'd need your own server of course...
some benchmarks here:
http://gemstonesoup.wordpress.com/2007/10/19/scaling-seaside-with-gemstones/
The Seaside Book has a chapter on deployment. It describes how I typically deploy a Seaside application.
I just use a ssh tunnel to get the X display on my local machine. I'm using slicehost (US) from the Netherlands, so I have a ping time of 135 ms. That's not that nice, but ok.
Next step will be Lukas Renggli's remote frame buffer package to use a vnc viewer.
Let's see what Miguel Cobá had to say about it on it on the Gemstone mailing list:
If you have already installed a RFB in your machine then use it.
If you have RFB installed in your image and it is accesible from your
client machine, use it
But, both of them are unencrypted. If you want to encrypted you must
setup a tunnel (maybe with ssh or maybe TLS).
I think that that is redundant because you must use a tunnel and then
the RFB. So what I do, in linux is to install the minimal X libraries
and then forward the X session to my local machine.
In the server (Debian/Ubuntu instructions):
aptitude update
aptitude install xbase-clients
aptitude install xtightvncviewer
Test it from the client machine:
ssh -X remote_server
squeakvm gemtools.image &
This will start the squeakvm process on the server, but all the graphics
will be shown on the local machine (the Xserver for this particular
scenario).
Also, if you install RFB on some of your images and start them headless,
you can use xtightvncviewer to connect to inside the image through the
RFB server.
ssh -X remote_server
xtightvncviewer localhost:0 &
this will run the xtightvncviewer on the remote server but, again, will
show on your local machine. Supposing you have your image in the remote
server running RFB in the first display.
Which is the advantage:
- You don't have to open ports for RFB on the remote server
- You transmit everything encrypted through ssh
- You only run the commands on demand in the remote server. You don't
have to have VNC running always.
- You can configure your RFB in the image to accept only localhost
connections and not from everywhere.
Martin McClure adviced me to take a look at NoMachines NX (less chatty X),
but that's still on my todo list.
For another set of deployment instructions, take a look at Miguels blog
The blogosphere's been talking about this issue recently.
Doug Putnam wrote up his experiences in installing Seaside (on Pharo) on his Slicehost slice, working off James Robertson's writeup (which uses VisualWorks, I suppose?).