The version I run on my desktop has Emacs, a common list compiler, and SLIME a lisp IDE. This would be good for collaboration and testing of any functionality that includes internet protocols.
My server has CentOS and so the package manager is YUM I believe.
Thanks,
Bruce
I don't know if you can run Lisp-in-box on a server, but you could run a
Lisp with SWANK on your server. Then, your collaborators and yourself
would be able to connect to it with
M-xslime-connectRET.
And if you want to use a secure connection, just make sure SWANK
listen only on localhost, then you can make an SSH tunnel.
ssh -f -N -L 4005:localhost:4005 $user#$host
Bonus:
This
blogpost
is about collaborative coding with Common Lisp.
Related
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 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.
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...
As part of a TDD (test driven development) project I want a simple OSX service/server that simply forwards data between two clients. The purpose is to enable communication between one piece of code running in iOS (being tested) and another running in OS X.
I think I need both parties to connect to the server for the duration of the test, which points at TCP
There are lots of examples for creating simple clients using NSStream, but have failed to find what creates the Server side.
I would have thought it would be normal for this forwarding software to be a client of the final server, rather than both the other pieces of code being a client to it (as it's both counter-intuitive and somewhat difficult to acheive):
iOS App -> Forwarding Server -> OSX Server
You can achieve this using netcat (which is installed by default on OSX), simply with:
$ nc -l -p local-port -c "nc osx-host osx-port"
(see below)
and the iOS app simply needs to connect to local-port on whatever machine this forwarding server is running on.
EDIT When I actually tested my answer I found that the netcat supplied with OSX cannot support port forwarding, and the answer I supplied only works with the Linux version (I believe there is a BSD-rewrite which OSX uses).
Anyway, this can be achieved if you are happy to install macports and use socat. Here's a working example that redirects port 8888 to www.google.com:80:
$ sudo port install socat
$ socat TCP-LISTEN:8888,fork TCP:www.google.com:80
If you then connect to http://localhost:8888 within your browser, this will hit Google.
Port Forwarding In Windows for iOS .
1. Install Python 2.7 on windows system
2. Connect your iPhone to windows system
3. Download USB MXD1.0 and put it in C Drive
4. Run Command Prompt : OpenC:\usbmuxd-1.0.8\python-client in cmd
5. Run **\Python27\python.exe tcprelay.py -t local port:remote Port**
Eg :**\Python27\python.exe tcprelay.py -t 9892:9892**
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?).