A Haskell implementation of the SSH V2 Protocol.
Build the library and the example client and server with
ln -s stack.ghc-7.10.yaml stack.yaml
stack build --flag "ssh-hans:build_examples"
Note that the examples are not built by default, so we must enable
building them by setting the build_examples flag above. If you are
using Cabal instead of Stack, you can build the examples with
cabal install --flag build_examples
See client/README.md and server/README.md for info on the example
client and server.
We only support keys in OpenSSH format, corresponding to the -o
option to ssh-keygen. To convert an existing key to OpenSSH format:
ssh-keygen -o -p -f ~/.ssh/id_rsa
To generate a new, password-less OpenSSH format key:
ssh-keygen -o -N '' -f test_key
- Closing a session channel kills the connection.
This is only a problem when opening more than one channel, and shouldn't be hard to fix. Problem is illustrated in this commit:
commit a5f250212e6e07fc55df7a4f0c6d01d25a81324e
Author: Nathan Collins <[email protected]>
Date: Fri Dec 25 01:34:49 2015 -0800
Illustrate channel close bug.
Running multiple echo clients concurrently we see that the first to
close its connection causes the server to clean its channel up to
soon, causing the server's channel handler loop for that client to
crash when that channel is later looked up again.
- Some OpenSSH 5.3 servers advertise support for "hmac-sha2-512", but kex fails when this algorithm is selected for MAC in either direction. According to OpenSSH docs [1], support for "hmac-sha2-512" was not added until version 5.9, so I'm not sure why 5.3 servers are advertising support.
[1] http://www.openssh.com/txt/release-5.9
The SSH RFCs explain the protocols, messages, and network data encodings. See http://www.snailbook.com/protocols.html for a full list of relevant RFCs. The main RFCs relevant to understand this code are RFCs 4250 though 4254.
This library implements both client and server functionality, and much code is agnostic to whether it's being run in a client or server. So, in many places we use "us" and "them" to refer "the local side of the connection" and the "remote side of the connection".
The term "session backend" is used throughout the code to refer to a program which interprets an "exec", "shell", or "subsystem" request on a session channel.
The implementation usually assumes that the other end of the network will not deviate from the protocol, and kills connections quickly if the other end does something unexpected.
There is no support for checking that server signatures are known
(cf. ~/.ssh/known_hosts) in clients.
The connection implementation in src/Network/SSH/Connection.hs is
incomplete; see that file for more information.