Zaitcev mentioned in his blog a problem with ssh and scp, that it takes a great deal of CPU resources and slows things down in certain cases. I recall using "null" cypher with ssh several years ago, just out of personal curiosity to test its speed and CPU load. It requires only a trivial patch to the openssh code to enable. Upstream is probably wise to not ship a null cypher in their own distribution, because it would be bad for most users.
But in a way, it is a shame that openssh doesn't allow the user to shoot themselves in the foot if they explicitly want to. There are a few corner cases where this option would be useful:
- Copying a file over a network where you care about protecting authentication, but you don't care about privacy of the data.
- Significantly reduce load on an LTSP server. Currently using a ssh tunnel to allow secure thin client connections to LTSP significantly reduces the # of clients that one server can handle (like 35 to 7 ratio). It would still be imperfect security wise, but if the thin client desktop session login is handled at ssh-login time, this is an improvement at least over the past LTSP over XDMCP.
- (There may be other corner cases where this kind of simple tunnel might be useful.)
I wonder if it would be worthwhile to have "broken" equivalents of these commands, that used the same kind of encryption to protect authentication, but is otherwise unprotected for speed. The word "broken" would be explicitly in the name, to constantly remind users that it sucks and is unsafe. =)
brokensh firstname.lastname@example.org (with some tunnel parameters)
Secure authentication of LTSP thin clients without speed and scalability penalty.
brokencp file.txt email@example.com:/home/username/file.t
Copy a file with strong authentication but no data privacy
Given these purposes, there is no good reason to allow a broken interactive shell. The tool could disable that entirely. Perhaps brokensh would better exist as only a library API for specific apps (like an LTSP client/server) to use. Pity that this would be a lot of duplicate code only because we don't want to add a few lines to enable null in the standard openssh package. (This is not suggesting that we should break openssh itself in this way. Bad idea.)
Aside from the loss of privacy, this would enable potential man-in-the-middle session hijacking. This might seem bad, but this is still an improvement over how most people currently use LTSP with XDMCP. The cypher should be choosable (3des, blowfish, null, etc.) prior to the LTSP client login. This allows existing users to maintain a large number of functional LTSP clients on existing servers, while enabling a proper cypher when they later acquire more powerful server hardware.
(I wonder if there are any affordable ways to off-load cypher processing of ssh for these LTSP users...)