Comments on "Does Installing SSH Enable More Exploits Than it Solves?"
May 27th, 2006 by Doug
There is an article up at InformIT by John Tränkenschuh
titled
href=”http://www.informit.com/articles/printerfriendly.asp?p=471099&rl=1″>SSH
Issues: Does Installing SSH Enable More Exploits Than it
Solves?. The basic premise of the article is that SSH usage is
enabling security holes, in most cases quietly, that otherwise would
not have been present. The specific example given is that of SSH agent
forwarding, and how compromise of the agent-forwarding host would
result in intruder access to any of the end systems. While I agree
that SSH can be configured in a way that makes it less secure, I don’t
think ceasing use of SSH is the answer (the author never states
explicitly that this is his goal, however, the title of this article
certainly suggests
this). SSH can be configured
securely, but like any other complex security system, it takes a
little effort.
I think most admins would accept the basic premise that remote
connectivity is a must in
today’s always-on IT
environment. Widespread adoption of SSH (and OpenSSH in particular)
has been responsible for a welcome downturn in the use of telnet and
the Berkeley r-tools (rsh, rlogin, etc.). While most admins would also
agree that discontinuing use of any remote connection protocol would
enhance security, I think it is unrealistic to assume suddenly
discontinuing SSH usage would fix anything. Most sysadmins would find
a way to do work remotely, whether by falling back to insecure
protocols, or by using VPN clients. In any case, the same or worse
risks would be present as with SSH. Interestingly, the compromise of
the intermediate agent-forwarding host in the author’s example may not
be the worst security risk in that case - the admin’s client may be a
weak link in the authentication chain if it has, say, SSH root login
and password authentication enabled. The unsophisticated attacker that
compromises an admin’s home workstation and non-root user account with
an SSH brute-force login script would be able to jump to other systems
by simply scanning a shell history file and setting a few environment
variables (assuming an ssh-agent running that had cached
credentials). The same problem exists with home VPN’s used by
telecommuters. A compromise of the VPN client while the VPN tunnel was
active would lead to corporate LAN access. It’s why companies like
Check Point provide VPN clients that can be remotely configured during
connection initiation to
disallow any non-VPN traffic
while a tunnel is active.
Anyway, raising awareness of insecure SSH usage is certainly
beneficial, so in that respect, I think the article is a good one (it
is the reason I
wrote
href=”http://geekpit.blogspot.com/2006/04/five-minutes-to-more-secure-ssh.html”>Five-Minutes
to a More Secure SSH, after all). I think the title could have
been a bit less sensational, however.
Technorati tags:
rel=”tag”>SSH,
Security,
Unix,
Sysadmin
![[SDF Public Access Unix System] [SDF Public Access Unix System]](http://www.unixlore.net/images/sdf.jpg)
My thanks for your insightful review of my old article. We both agree that great SSH awareness of the VPN risks is always a good thing. Like you, I don’t think people must de-install SSH.
JT
“Anyway, raising awareness of insecure SSH usage is certainly beneficial,”