8543 posts
Posted 26 November 2012 - 11:05 AM
nsh, or Net Shell, is an advanced remote shell program that you can use to control any computer remotely! Simply install nsh on both computers and run it in hosting mode on the machine you'd like to connect to.
nsh features:
To specify a program to run for each client that connects (like an authentication program), as well as a program to run locally, use the following command. Both of these options default to /rom/programs/shell.
nsh host [outbound] [local]
The best way to get nsh is via packman, with the command packman install nsh, as this will fetch nsh and its dependencies automatically. You could also grab it from pastebin:
nsh: X5Fysdi4, or simply: pastebin get X5Fysdi4 nsh
framebuffer (suggested)I: Aaza6h5v, or simply: pastebin get Aaza6h5v framebuffer
You can start nsh with nsh host on the server computer and nsh <serverID> on the client.
nsh comes with the ability to send and receive files! You can add the get (KJ9Tu2Y9) and put (zeS6uFY7) programs (also available via packman as nsh-get and nsh-put, respectively) to the nsh host and connected clients can use these to send and receive files. The syntax is from the client's perspective, so running get file1 file2 while connected will get file1 from the server and save it as file2 on the client. When saving files to the client, you cannot overwrite existing files. This is to prevent the possibility of a rogue nsh server luring clients into connecting, then overwriting their startup with something nasty without asking the client. Binary files are also now somewhat supported. There are binary versions of the get and put programs available on the github repository. The put program works quite well, but the get program needs to be given a moment or two to save the file to prevent some odd behavior or disconnections due to the nature of the binary file writing procedure.
With the addition of the framebuffer API (you do not need to separately install it if you have LyqydOS installed, it will find that copy), nsh can now handle session resuming. When connecting to a server, simply type nsh <server> resume to resume a previous session. If no previous session is available, you will simply start a new session. This is the only way to prevent killing a process started in a previous session when reconnecting. The framebuffer API being present also provides a significant reduction in rednet usage, so you should notice better responsiveness on slower connections. Of course, the framebuffer API is not required, but you will notice significant benefits to having it present.
Also available is a small nsh API that programs on the server can use. It exposes the following functions while nsh is running:
A sample authentication program, available via packman as nsh-auth or fetchable from pastebin: ySEWczEr or simply: pastebin get ySEWczEr auth
I will be further extending nsh in the (hopefully near) future to be able to run programs on the client to handle responses from programs running on the server, to further extend the capabilities beyond what can reasonably be built into nsh itself.
nsh features:
- Connect any combination of advanced computer, regular computer and turtle.
- See the remote shell as if you were at that computer.
- Use the hosting computer's local shell like nothing is different.
- Run specific programs for incoming sessions and the local session (authentication!).
- Transfer files between client and server (requires get and put programs).
- Client file protection prevents server from overwriting local files.
- Forward connections seamlessly (connect to another computer from a remote session).
- Resume a previous remote session you had forcefully disconnected from.
Spoiler
To specify a program to run for each client that connects (like an authentication program), as well as a program to run locally, use the following command. Both of these options default to /rom/programs/shell.
nsh host [outbound] [local]
The best way to get nsh is via packman, with the command packman install nsh, as this will fetch nsh and its dependencies automatically. You could also grab it from pastebin:
nsh: X5Fysdi4, or simply: pastebin get X5Fysdi4 nsh
framebuffer (suggested)I: Aaza6h5v, or simply: pastebin get Aaza6h5v framebuffer
You can start nsh with nsh host on the server computer and nsh <serverID> on the client.
nsh comes with the ability to send and receive files! You can add the get (KJ9Tu2Y9) and put (zeS6uFY7) programs (also available via packman as nsh-get and nsh-put, respectively) to the nsh host and connected clients can use these to send and receive files. The syntax is from the client's perspective, so running get file1 file2 while connected will get file1 from the server and save it as file2 on the client. When saving files to the client, you cannot overwrite existing files. This is to prevent the possibility of a rogue nsh server luring clients into connecting, then overwriting their startup with something nasty without asking the client. Binary files are also now somewhat supported. There are binary versions of the get and put programs available on the github repository. The put program works quite well, but the get program needs to be given a moment or two to save the file to prevent some odd behavior or disconnections due to the nature of the binary file writing procedure.
With the addition of the framebuffer API (you do not need to separately install it if you have LyqydOS installed, it will find that copy), nsh can now handle session resuming. When connecting to a server, simply type nsh <server> resume to resume a previous session. If no previous session is available, you will simply start a new session. This is the only way to prevent killing a process started in a previous session when reconnecting. The framebuffer API being present also provides a significant reduction in rednet usage, so you should notice better responsiveness on slower connections. Of course, the framebuffer API is not required, but you will notice significant benefits to having it present.
Also available is a small nsh API that programs on the server can use. It exposes the following functions while nsh is running:
nsh.getRemoteID() --returns the computer ID of the client who is connected to the session the function is called from, or nil if called from local session.
nsh.send(<message>) --sends a rednet message to the connected client.
nsh.receive([timeout]) --returns any messages received from the connected client that are not intercepted by nsh itself. For instance, you cannot receive the event packets with this method.
nsh.getClientCapabilities() --requests the capabilities string from the connected client. Returns nil if a response is not received within one second.
nsh.getRemoteConnections() --fetches a list of all directly connected computers.
A sample authentication program, available via packman as nsh-auth or fetchable from pastebin: ySEWczEr or simply: pastebin get ySEWczEr auth
Spoiler
local pass = "fooBarBaz"
term.clear()
term.setCursorPos(1,1)
print("remote@"..(os.getComputerLabel() or os.getComputerID()))
term.write("Login Required: ")
if read("*") == pass then
shell.run("rom/programs/shell")
end
I will be further extending nsh in the (hopefully near) future to be able to run programs on the client to handle responses from programs running on the server, to further extend the capabilities beyond what can reasonably be built into nsh itself.
