Moral.. Don't trust ssh.
-Ryan Net Access Corporation
what idiocy. given write access to a binary, one can use the binary as a trojan horse. if it has privileges or is executed by someone who has privileges, then your trojan will have those privileges. ssh is not the problem. writable / mutable binaries are the problem, and letting someone break into your system far enough to write or mutate your binaries is the problem, and using versions of SSH (or any other privileged tool) whose signatures you have not verified out-of-band is the problem. ssh is a fine program as such things go. security is fundamentally more about the procedures for key use and key management than it is about the quality of one's locks. in other words it's the people not the technology.
Paul; I tend to agree with you on this issue and so do the people responsible for the program who have looked at the issue very carefully themselves. SSH Communications Security Ltd. http://www.ssh.fi/sshprotocols2/rootshell.html Henry R. Linneweh Paul Vixie wrote:
Moral.. Don't trust ssh.
-Ryan Net Access Corporation
what idiocy. given write access to a binary, one can use the binary as a trojan horse. if it has privileges or is executed by someone who has privileges, then your trojan will have those privileges.
ssh is not the problem. writable / mutable binaries are the problem, and letting someone break into your system far enough to write or mutate your binaries is the problem, and using versions of SSH (or any other privileged tool) whose signatures you have not verified out-of-band is the problem.
ssh is a fine program as such things go. security is fundamentally more about the procedures for key use and key management than it is about the quality of one's locks. in other words it's the people not the technology.
-- ¢4i1å
participants (2)
-
Henry Linneweh -
Paul Vixie