I have a program that connects to a remote machine via SSH. I want to upload and run a binary on that machine. In order to do that I need to know what OS it is (I will support Linux, Mac and probably Windows), and what CPU architecture (I will probably only support x86_64, but it would be good to be able to detect others and print a sensible error, if this is possible).
It doesn't look like the SSH protocol itself provides any of this information. Is there a simple, ROBUST way to do this? With as few hacks as possible (no hairy Bash scripts!).
The best thing I can think of is to try running uname -s -m, and whatever the Windows equivalent is and parse the results.
The SSH protocol doesn't provide any information about the remote system except its protocol version. However, oftentimes vendors will include a string in the protocol string. For example, if you do nc gitlab.com 22 </dev/null | head -n 1, you can tell that GitLab runs Ubuntu.
However, not all remote systems provide this information, so for a reliable test, you'll probably need to log into the system. As mentioned, you can run uname on Unix systems, and cmd /c ver on Windows systems to find out what OS you're on. Note that the latter will not work on Windows if you log into a MinGW-based bash on Windows, since the /c will be rewritten as C:\; you'll need to double the slash or use uname there.
I'm not aware of a single command that you can invoke that will work on all systems, so you'll probably have to make multiple shell requests. You are probably better off doing this using an SSH library, since the OpenSSH binary will print any banner from the remote side whether you want it or not, and that can be confused with the output you get from the remote side.
Related
I develop a POSIX shell script to check SSL certificates and connections.
The script is not running on AIX and I would like to see if I can adapt it.
Is there a free (or cheap way) to get a shell account on an AIX machine to test an open source project?
A relatively cheap way to get a shell account on an AIX machine would be https://www.ibm.com/cloud/free.
It looks like it's free for limited use.
I'm new to the WSL2 and wondering if it's possible to run the same WSL2 ubuntu instance on both my desktop and laptop.
Now I am able to use wsl --export and wsl --import method to save and load the system to/from my portable hard drive. But these methods takes a long time.
I notice that wsl --import load a file named ext4.vhdx. Is there a way to load straightly from this file?
Update v2.0:
I was able to get a workaround and it works great.
Thanks to Booting from vhdx here, I was able to load straightly from my vhdx file on my portable hard disk. Windows track down its subsystem with regedit, So we can write our own(p.s: make sure to get BasePath right, it starts with "\\\\?", or you will not be able to access the subsystem' filesystem on your host system.):
Windows Registry Editor Version 5.00
[HKEY_USERS\【your SID here】\SOFTWARE\Microsoft\Windows\CurrentVersion\Lxss\{【UUID here】}]
"State"=dword:00000001
"DistributionName"="distribution name"
"Version"=dword:00000002
"BasePath"="vhdx folder path" 【 e.g. "\\\\?\\E:\\S061\\WSL\\ubuntu-20"】
"Flags"=dword:0000000f
"DefaultUid"=dword:000003e8
I suppose the best way to do this would be to store ext4.vhd on a network storage device accessible to both devices.
I have previosly mentioned how to move ext4.vhd. You can check that out here
Basically you need to export from one machine and import it while making sure the vhd file is configured for wsl to access from the network storage
Since this should *officially* not supported expect some performance hits
Another way would be to run WSL on one computer and ssh/remote desktop to it from another device on the network
I'm of the strong belief that sharing the same ext4 vhd between two VM's simultaneously would be a bad idea. See this and this Unix & Linux StackExchange, including the part about ...
note that sharing LVs/partitions on a single disk between the servers at the same time is NOT very safe. You should only access whole disks from any of the servers at one time.
However, as dopewind's answer mentioned, you can access the WSL instance on one computer (probably the desktop) from another (e.g. the laptop). There are several techniques you can use:
If you have Windows 10 Professional or Enterprise on one of the computers, you can enable Remote Desktop, which allows you to access pretty much everything on one computer from another. RDP ("Remote Desktop Protocol") even works from other devices such as an iPad or Android tablet (or even a phone, although that's a bit of a small screen for a "desktop"). That said, there are better, more idiomatic solutions for WSL ...
You could enable SSH server on the Windows 10 computer with the WSL instance (instructions). This may sound counterintuitive to some people, since Linux itself running in the WSL instance also includes an SSH server (by default). But by SSH'ing from (for example) your laptop into your desktop's Windows 10, you can then launch any WSL instance you have installed (if you choose to install more than one) via wsl -d <distroName>. You also avoid a lot of the network unpleasantness in the next option ...
You could, as mentioned above, enable SSH on the WSL instance (usually something like sudo service ssh start) and then ssh directly into it. However, note that WSL2 instances are NAT'd, so there's a whole lot more hackery that you have to do to get access to the network interface. There's a whole huge thread on the WSL Github about it. Personally, I'd recommend the "Windows SSH Server" option mentioned about to start out with, then you can worry about direct SSH access later if you need it.
Side note: Even though I have SSH enabled on my WSL instances, I still use Windows SSH to proxy to them, to avoid these networking issues.
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.
Is there a difference between using salt-proxy ssh and directly salt-ssh? I'm interested because according to documentation both aimed to run remote commands without agent installation on the end machine.
You cant simply do salt-ssh on a proxy minion, for which you would have to write your own custom ssh interface to the remote system, because your proxy minion may not support doing salt-ssh.
How to choose between using salt-ssh vs salt-proxy totally depends on the type of a minion system.
As stated in the saltstack documentation - https://docs.saltstack.com/en/latest/topics/ssh/index.html and
https://docs.saltstack.com/en/latest/topics/proxyminion/index.html
For salt-ssh to be used, the remote system must have python installed - one of the criteria. For example, controlling ubuntu from centos.
As stated in the salt-proxy doc,
Proxy minions are a developing Salt feature that enables controlling
devices that, for whatever reason, cannot run a standard salt-minion.
Examples include network gear that has an API but runs a proprietary
OS, devices with limited CPU or memory, or devices that could run a
minion, but for security reasons, will not.
The Setup
We have an aircon unit in the office but it takes a good hour to start cooling the place down, I have an IR USB device that communicates via a com port. I have a utility to send various IR codes to control an aircon unit.
I use .bat files to load the .exe and the .bin file
irtoy.exe -d COM4 -p -a 100 -f ACPowerToggle.bin
My question is what's the best way I can execute this on a remote server? Is it possible from a web server or something else?
I suggest using an SSH server like OpenSSH, as well as providing secure access, you can execute programs, manage everything needed as well as direct access to the computer's operating system.
Edit:
Yes, you can use both iOS and Android apps to access your SSH server using a smart phone.