[dev] Suckless remote shell?

From: Markus Wichmann <nullplan_AT_gmx.net>
Date: Sun, 3 Nov 2013 10:28:53 +0100

Hi all,

I was wondering: I know that ssh is crap once you look at what it
actually does (overcomplex configuration/encapsulation/protocol), so is
there any alternative already in existence? If not, I have a proposal
for one: Shell over SSL.

The reason for SSL is that AFAIK most of the suck in it comes from the
CA system, that is, the huge number of pre-installed unlimited-trust
entities, that can be completely disabled. So, what I thought to do was:

- Server accepts only client certs from same CA as its own cert.
- Server only accepts connections with client cert!
- Identification by common name in client cert.
- Authentication by client cert validation against CA.
- Then run a process which takes over the connection and only passes
  data back and forth between the SSL connection and a pseudo terminal
  running "login -f $username".

I had managed to whip something like that up in a couple of hours, but
unfortunately, some plumbing is still unresolved, namely terminal handling.

We could just put the client's terminal into pass-through mode
(non-canonical, read 1, time 0, no echo, no transformations on input or
output and whatever else may be necessary), which has the problem that
every keystroke sends a packet. Which not only means that we are sending
tonnes of packets containing only a single byte of information, but
their timing can compromise the privacy of the client->server
connection, if the attacker knows the client's keyboard layout. Simple
buffering could solve that problem, but how much to buffer and when?
Most terminal programs that actually read input from the terminal are so
highly interactive that they read everything in noncanonical mode, which
means no buffering allowed.

Well, how is it? Critique? Endorsement?

Ciao,
Markus
Received on Sun Nov 03 2013 - 10:28:53 CET