This is a read-only snapshot of the ComputerCraft forums, taken in April 2020.
jaredallard's profile picture

OpenSSH

Started by jaredallard, 23 November 2014 - 06:34 AM
jaredallard #1
Posted 23 November 2014 - 07:34 AM
OpenSSH


A while back while looking up SSH in ComputerCraft I found a thread that essentially barely did much of anything in terms of SSH. It wasn't end-to-end encrypted, it didn't basically draw whatever the other computer would see, and it wasn't transparent to programs. This gave me the idea of trying to port an-OpenSSH like system to ComputerCraft. Thus this was made.

Features:
* AES End-to-End encryption.
* Overides print(), io.write(), read(), term.write(), and term.clear() inorder to displayexactly what would be on the other terminal, on yours.

Limitations:
* Only runs on http://github.com/ccLinux/kernel with the flag 'debug' or 'shell_dump' right now, but this will be fixed, or have the APIs built in.


Server: https://github.com/ccLinux/opensshd
Client: https://github.com/ccLinux/openssh-client

There will be relevant documentation and such on their own respective git repositories soon.

Code review/feedback would be great.
Lyqyd #2
Posted 24 November 2014 - 01:02 AM
The second line under Features probably should be listed under Limitations.

Edit: To clarify, this could be improved by transporting all of the user input events from the client to the server, running the server session in a coroutine, and redirecting that coroutine to a TRoR target to transport screen changes back to the client, similar to the way nsh works. Your program in its current state can't make use of the edit program, for instance.
willwac #3
Posted 27 November 2014 - 06:52 PM
Does the program return print, read, etc. when it's done?
FUNCTION MAN! #4
Posted 27 November 2014 - 09:38 PM
Does the program return print, read, etc. when it's done?

Yes.
Edited on 27 November 2014 - 08:38 PM
jaredallard #5
Posted 28 November 2014 - 06:15 AM
The second line under Features probably should be listed under Limitations.

Edit: To clarify, this could be improved by transporting all of the user input events from the client to the server, running the server session in a coroutine, and redirecting that coroutine to a TRoR target to transport screen changes back to the client, similar to the way nsh works. Your program in its current state can't make use of the edit program, for instance.

True,

Ah, yes, that's a good idea, I shall get onto that as soon as possible.