A secure remote client/server terminal, written in Golang. Intended as a test-bed for experimental key exchanges and symmetric session crypto. Integrated traffic chaffing.
Go to file
Russ Magee cb7a79063e Added validation user actually exists on system 2018-10-03 22:31:35 -07:00
herradurakex Fixed syntax errors from re-org 2018-07-04 22:06:07 -07:00
hkexnet Made padding size random [max/2, max); use of improved goutmp host lookup 2018-10-02 21:23:45 -07:00
hkexpasswd -hkexpasswd: now can add new users 2018-09-07 20:56:42 -07:00
hkexsh Dial() and Accept() again conform to net.Dial(), net.Accept() return signature 2018-09-29 12:15:53 -07:00
hkexshd Made padding size random [max/2, max); use of improved goutmp host lookup 2018-10-02 21:23:45 -07:00
spinsult Updates to main Makefile (and added spinsult Makefile) 2018-07-04 23:07:09 -07:00
LICENSE.gpl misc. cleanup, LICENSE.{gpl,mit} updates 2018-04-07 13:04:10 -07:00
LICENSE.mit misc. cleanup, LICENSE.{gpl,mit} updates 2018-04-07 13:04:10 -07:00
Makefile Updates to main Makefile (and added spinsult Makefile) 2018-07-04 23:07:09 -07:00
README.md README.md - added EXPERIMENTAL warning to hkexcp section 2018-09-01 10:44:13 -07:00
TODO.txt .hkexsh_id file supports multiple authtokens (multi remote hosts, aliases for same remote host) 2018-09-14 11:58:10 -07:00
consts.go Split hkexsh and hkexnet consts into separate files 2018-09-17 17:27:13 -07:00
cp.cmd Continuing groundwork for cp mode - refactor main client code into shell/copy subroutines; -r option 2018-08-06 22:29:51 -07:00
hkexauth.go Added validation user actually exists on system 2018-10-03 22:31:35 -07:00
hkexsession.go GenAuthToken() now uses client-supplied ConnHost 2018-09-14 01:13:14 -07:00
termmode_unix.go MSYS+mintty support; pkg renaming to hkexsh 2018-04-04 15:43:27 -07:00
termmode_windows.go MSYS+mintty support; pkg renaming to hkexsh 2018-04-04 15:43:27 -07:00

README.md

HKExSh

'hkexsh' (HerraduraKEx shell) is a golang implementation of a simple remote shell client and server, similar in role to ssh, offering encrypted interactive and non-interactive sessions as well as file copying.

The client and server programs (hkexsh and hkexshd) use a mostly drop-in replacement for golang's standard golang/pkg/net facilities (net.Dial(), net.Listen(), net.Accept() and the net.Conn type), which automatically negotiate keying material for 'secure' sockets using the experimental HerraduraKEx key exchange algorithm first released at Omar Elejandro Herrera Reyna's HerraduraKEx project.

One can simply replace calls to net.Dial() with hkex.Dial(), and likewise net.Listen() with hkex.Listen(), to obtain connections (hkex.Conn) conforming to the basic net.Conn interface. Upon Dial(), the HerraduraKEx key exchange is initiated (whereby client and server independently derive the same keying material).

Above the hkex.Conn layer, the server and client apps in this repository (server/hkexshd and client/hkexsh) negotiate session settings (cipher/hmac algorithms, interactive/non-interactive, etc.) to be used for further communication.

Packets are subject to random padding, and (optionally) the client and server channels can both send chaff packets at random defineable intervals to help thwart analysis of session activity (especially for interactive shell sessions).

NOTE: Due to the experimental nature of the HerraduraKEx algorithm used to derive crypto keying material, this algorithm and the demonstration remote shell client/server programs should be used with caution and should definitely NOT be used for any sensitive applications, or at the very least at one's own risk.

As of this time (Jan 2018) no verdict by acknowledged 'crypto experts' as to the level of security of the HerraduraKEx algorithm for purposes of session key exchange over an insecure channel has been rendered. It is hoped that experts in the field will analyze the algorithm and determine if it is indeed a suitable one for use in situations where Diffie-Hellman or other key exchange algorithms are currently utilized.

Finally, within the hkexpasswd/ directory is a password-setting utility using its own user/password file distinct from the system /etc/passwd, which is used by the hkexshd server to authenticate clients.

Dependencies:

Get source code

  • $ go get -u blitter.com/go/hkexsh
  • $ cd $GOPATH/src/blitter.com/go/hkexsh
  • $ go build ./... # install all dependent go pkgs

To build

  • $ cd $GOPATH/src/blitter.com/go/hkexsh
  • $ make clean all

To set accounts & passwords:

  • $ echo "joebloggs:::*" >hkexsh.passwd
  • $ sudo mv hkexsh.passwd /etc
  • $ sudo hkexpasswd/hkexpasswd -u joebloggs
  • $ <enter a password, enter again to confirm>

WARNING WARNING WARNING: the -d debug flag will echo passwords to the log/console!

Running Clent and Server

In separate shells A and B:

  • [A]$ cd hkexshd && sudo ./hkexshd & # add -d for debugging

Interactive shell

  • [B]$ cd hkexsh && ./hkexsh joebloggs@host-or-ip # add -d for debugging

One-shot command

  • [B]$ cd hkexsh && ./hkexsh -x "ls /tmp" joebloggs@host-or-ip

NOTE if running client (hkexsh) with -d, one will likely need to run 'reset' afterwards to fix up the shell tty afterwards as stty echo may not be restored if client crashes or is interrupted.

File Copying using hkexcp (EXPERIMENTAL - See issue tracker)

hkexcp is a symlink to hkexsh, and the binary checks its own filename to determine whether it is being invoked in 'shell' or 'copy' mode. Refer to the '-h' output for differences in accepted options.

General remote syntax is: user@server:[/]src-or-dest-path If no leading / is specified in src-or-dest-path, it is assumed to be relative to $HOME of the remote user. File operations are all performed as the remote user, so account permissions apply as expected.

Local (client) to remote (server) copy:

  • cd hkexsh && ./hkexcp fileA /some/where/fileB /some/where/else/dirC joebloggs@host-or-ip:/remoteDir

Remote (server) to local (client) copy:

  • cd hekxsh && ./hkexcp joebloggs@host-or-ip:/remoteDirOrFile /some/where/local/Dir

NOTE: Renaming while copying is NOT supported (ie., like cp's 'cp /foo/bar/fileA ./fileB). Put another way, the destination (whether local or remote) is ALWAYS a dir.

hkexcp uses tar with gzip compression (ala a 'tarpipe') under the hood, sending tar data over the hkex encrypted channel. Use the -d flag on client or server to see the generated tar commandlines if you're curious.