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
