On 26 Jun 2002, Niels Möller wrote: > lsh seems slower than openssh, in particular for bulk file transfers. > Help with profiling and tuning would be appreciated. I'm not sure if > it uses more cpu, or generates more network traffic, or both.
>From my *highly* unscientific monitoring with top and ps, it doesn't seem any more CPU intensive than Opensshd, if your really curious I'll throw get a bit more work into checking that aspect. I've not measured the network traffic, but I can do so, and will put it on my todo list. I don't really think that's going to be much of an issue though, since I don't notice (and have not had anyone else tell me otherwise) much of a difference between the response on the local lan and those on dialup lines. The lag could also be on the client side, The client software ranges from Cygwin/Openssh, to Putty, to Penguiterm, to WinSCP2 (all W2K or NT4), to OpenSSH's client (various versions) on Linux. The lag from client to client is different somewhat (putty is a crapload slower than the OpenSSH client), but all of them seem, or are at least percieved to be, slower when hitting the LSH servers, as opposed to hitting the OpenSSHd servers. > > > Hmm, at what time scale? lsh intentionally fiddles with the VMIN and > VTIME attributes of the terminal in order to get more than one > character at a time when you're typing fast, but at least I don't > notice that when typing. the scale is pretty small, I could try and record a MPEG or AVI if you wish, but, during normal it's not that noticeable, it's only when you do something like "sit on the space bar" that you can see it heistate before advancing. Interesting, nobody has complained about the *display* (e.g pulling up a file) speed, only pauses when typing. > > That sounds hard. For a start, it's mostly pointless to run root > processes under chroot (if you do it for security reasons), as it's > easy for root to break out under most unix-like OS:es. And to be able > to log in users, lshd needs to be able to read /etc/passwd (and > /etc/shadow, if you use shadow passwords), chdir to users' home > directories, etc. > I was really thinking more along the lines of Neils Provos's Systrace (http://www.citi.umich.edu/u/provos/systrace) as opposed to a real chroot, sorry for the confusion. I should never do email before I wake up :-). My idea being to implement something similar to (but not a clone of) OpenBSD's priv seperation. The idea being, make it darned near impossible for LSh to do something other than log the user(s) in and chdir to the correct dir, even if the server is compromised. Since we can't really chroot it, the only other options I can think of are something along the lines of Systrace or somehow breaking the code up into two pieces, where we only use or have root privs is for the binding process and the login/chdir process. Probably completly unworkable and insane, but it's really CYA on my part. I want try and ensure, as much as reasonably possible, that even if any of the LSH test boxes were ever compromised via lsh, that that would not automagicly give the attacker an avenue to root level privs.
