mirage / awa-ssh Goto Github PK

Same issue as in #58.

I've been trying to install awa-ssh using opam, but so far without success.

• Awa requires a newer version of nocrypto than the current release (0.5.4).
• If I upgrade to the dev head of nocrypto, I can no longer install x509 (val ca_error_of_sexp : Ppx_sexp_conv_lib.Sexp.t -> ca_error is not included in val ca_error_of_sexp : Sexplib.Sexp.t -> ca_error).
• I've tried downgrading various other packages but have not found a combination of versions that will allow awa to build.

Since we at the moment only support having one channel we could send [email protected] when connecting so the server, if it is aware of [email protected], can close the connection once the last (and only) channel is closed. The feature is documented in openssh's PROTOCOL document.

since #16 decoding of unencrypted private keys in openssh key format is supported.

what is missing:

• encoding openssh key format
• encryption thereof (bcrypt)

I am interested in trying some network automation with OCaml. Is this library a good candidate for a general-purpose client to connect to network switches and routers, or is it specifically designed to be used only inside of Mirage? Thanks!

In keys.ml, we returns a simple string which does not compose well with rresult when this package is available (specially with mirage). It should be nice to return an Msg of string, and, by this way, be able to use for instance Rresult.R.failwith_error_msg.

I have made some progress regarding the communication between awa_test_client & awa_*_server : https://github.com/palainp/awa-ssh/tree/server-update

Now I can connect the client to both awa_ssh servers (I still have an issue with awa_test_server as when the client disconnects the server hangs) and run a command (the default ls /tmp/bla).
I had to add Rsa.sexp_of_pub (marked as TODO) which luckily already exists, remove some guards on plaintext keys as the Kex.is_keyed method force the server to fail in my test configuration (I guess there may be a clever solution here :) ), and (another smart solution will be needed) remove the test in Wire.get_pubkeys the client gives us rsa-sha2-256 which not match the rsa-ssh string we obtain with Hostkey.sshname.

I'm still have some problems when I try to connect the server with the openssh command, it fails with the following (I have no key for this server in .ssh/know_hosts):

[user@localhost awa-ssh]$ ssh -p 18022 -i ~/.ssh/id_ed25519 [email protected] -vvvv
OpenSSH_8.0p1, OpenSSL 1.1.1g FIPS  21 Apr 2020
[...]
debug1: kex: algorithm: diffie-hellman-group14-sha256
debug1: kex: host key algorithm: ssh-ed25519
debug1: kex: server->client cipher: [email protected] MAC: <implicit> compression: none
debug1: kex: client->server cipher: [email protected] MAC: <implicit> compression: none
debug1: kex: diffie-hellman-group14-sha256 need=64 dh_need=64
debug1: kex: diffie-hellman-group14-sha256 need=64 dh_need=64
debug2: bits set: 1012/2048
debug3: send packet: type 30
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug3: receive packet: type 31
ssh_dispatch_run_fatal: Connection to 127.0.0.1 port 18022: key type does not match

Just after the server sends >>> (Msg_kexdh_reply .... I'm guessing the diffie-hellman-group14-sha256 pointed out by ssh is exactly what I need to investigate now.

• the OpenSSH 8.3 release announcement mentions that ssh-rsa public key fingerprints will be removed soon (using SHA-1 is not anymore a good idea) RFC8332 is the easy way out (RSA fingerprints with SHA2); other options include: ECDSA with NIST P-256/384/512 and ED25519 (require further work on fiat / hacl to get ECDSA / EDDSA support) --> see #11
• SHA-2 support for client authentication (RSA key) --> see #11 (without 8308, but using an educated guess)
• hmac support for [email protected] and friends (the etm variants, specified in https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/PROTOCOL?rev=1.37&content-type=text/x-cvsweb-markup)
• supported ciphers are AES-{128.192,256}-{CTR,CBC}, AEAD would be nice to have (CCM/GCM)
• support a non-AES cipher (poly1305/chacha20) #14
• curve25519 support for key exchange (RFC 8731) - same as [email protected], see #15
• ed25519 support for host keys and user keys (RFC 8709), see #16
• find a hardened sshd configuration and figure out what else needs to be done for interoperability -> see e.g. https://medium.com/@jasonrigden/hardening-ssh-1bcb99cd4cef

now that multiple host key (and user authentication key) types are implemented, the authenticator (in the client) should be slightly improved:

• if a rsa key fingerprint is provided for authentication, the client should request a rsa hostkey
• if a ed25519 key is provided for authentication, ed25519 hostkey should be requested

for user authentication it seems like "whatever the server accepts" is the way to go. our client implementation only has a single private key anyways. this won't scale for a fully-featured ssh, but should be fine for now.

I tried to upgrade one of my services from awa 0.0.3 to 0.1.0, and this resulted in a authentication failure issue. The update also involves git and mimic (and thus, tracking code changes is not very easy). What happened in the history:

• awa 0.0.3, git 3.4.0: Keys.of_seed calls into Miage_crypto_pk.Rsa.generate ~bits:2048 to generate the key with the provided seed
• awa 0.0.5, git 3.7.0: now Keys.of_string is used (in Git_mirage_ssh), which calls since 5afcb11 into X509.Private_key.generate -- that uses bits:4096 by default.

Long story short -- if you have an old unikernel (< git 3.7.0, awa < 0.0.5) and attempt to update, you may need to re-create ssh keys. Sorry about that. Good news is that you can nowadays just use an ED25519 key provided directly, no RNG & seed required.

This issue is just for documentation purposes, I'll close it immediately.

When a client connects with an unknown key type (e.g. ECDSA) to an awa-ssh server the server doesn't recognize the key type and gives up parsing. It would be more graceful if the server handles unknown keys by informing the client that the provided key isn't accepted.

I finally have some time over the next couple weeks to work on this. The client works well out of the box, and I was able to connect with a password with simple modifications (to a linux host, I don't have a vendor network box handy at the moment). The trouble is trying to port this into the existing client in a way that works. Per RFC4252: "The client MAY send several authentication requests without waiting for responses from previous requests." When I send a single auth request, I don't have a problem, but the event loop seems to have trouble when it receives more than one reply. Using the following in handle_auth_failure,

    let met = Ssh.Pubkey (pub, None) in
    let metp = Ssh.Password ("supers3cr3t", None) in
    Ok ({ t with state = Userauth_request met },
        [ Ssh.Msg_userauth_request (t.user, service, metp); Ssh.Msg_userauth_request (t.user, service, met) ],

I get back:

awa_test_client.exe: [DEBUG] <<< (Msg_unimplemented 7)
awa_test_client.exe: [DEBUG] unexpected (Msg_unimplemented 7)

The unimplemented number is 6 or 7 depending on the auth order. I am not very strong with OCaml, but I would love to try and tackle this if you don't mind providing some pointers along the way. Thanks!

A reminder.

As mentioned in mirage/ocaml-git#482 both private keys and authenticators should be constructable from a string easily (used as command-line arguments to programs):

• the authenticator should specify type and fingerprint (or public key)
• the private key should specify type and seed (or private key)

This should be done before the next release. The current state is Keys.auhenticator_of_string and Keys.of_seed.

I think it's time to add CI to this project 👍.