Since it uses SSH to transport the initial session password, as robustly as SSH is.

The initial password is only used for authentication, isn't it? Someone could (unless more details are provided) snoop on the connection or even inject packets.

Hey, Eternal Terminal developer here :-)

A one-time shared passkey is sent over ssh and then this passkey is used to encrypt/decrypt the data in both directions. The server and the client have different initial nonces.

I tried and failed to log in with ssh keys. Does 'et' require password login or can it work with ssh keys as well?

I should have said, session key (not password).

That was my concern too. So ssh is used for the initial handshake? BFHD. A lot of the interesting stuff happens afterward. The "how it works" page explicitly says this:

> ET does not implement any of the SSH protocol

That implies they rolled their own wire protocol. Maybe they did a good job (like mosh appears to have done). More likely not. I'd be OK using this on an internal network or over a VPN, but relying on it alone for security would be premature.

I think that sentence implies they're using OpenSSH not that they're rolling their own?

--Edit--

A quick glance at the repo suggests they're using NaCl to handle the encryption + the SSH server for auth

Well, NaCl is certainly an improvement over a completely NIH approach, but doesn't necessarily provide features like forward secrecy. It would certainly be nice if the ET authors would explain in their "how it works" page how they've solved problems like these. Forward secrecy over resumable channels is not a trivial problem for which the quality of solutions should be assumed.