In my Secure Shell (SSH): Advanced Techniques paper, I cover a number of ssh's advanced feature set that many of its users do not take advantage of. However, I neglect to pay much attention to the security implications of using SSH, in general. This document attempts to remedy that failing.
SSH is, at this point, probably the single most popular and critical security-related tool found on Unix-like systems. However, many of its users are unaware of its powerful feature set and, more importantly, unaware of the security repurcussions of SSH's use.
In this document I will step through and analyze each of the primary areas of possible vulnerability I perceive.
Global remote tunnels (options -g and -R) from within the
network can make internal services accessible from the
public network. For example, a client in a company's NAT
(foo.hq.example.com) might might login to an ssh server
outside the network, say shell.example.net, using a
command such as ssh -g
-R8080:intranet.example.com:80 shell.example.net.
As a result, the publicly accessible listener socket,
shell.example.net:8080 tunnels directly to
intranet.example.com:80.
In addition, organizations also may attempt to restrict
outbound connections. Again, if ssh is permitted out,
packet filtering rules are essentially useless. A client
can redirect clients at local tunnel ports to access
external sockets via mediation by a tunnel to a host
beyond the firewall.
Finally, if the organization allows inbound ssh
connections, then anything within the network becomes
accessible via tunnel. For example, if a user has a
connected host at home, c0000209.dialup.example.net, and
connects to bastion.example.com, anything reachable from
bastion.example.com is accessible to the home computer,
via commands such as ssh
-L8080:intranet.example.com:80 bastion.example.com.
By utilizing the -g flag, this socket is
generally available to the public network.
Authentication keys that lack the protection of a
passphrase can result in a ripple effect throughout your
network, or even out into other people's networks. It is
vitally important that private keys be protected by mode
700, at most. Root compromises on a host with keys will
necessarily compromise any account configured to accept
null-passphrase keys stored on the compromised host.
The flipside of this feature is that the superuser on a
remote host may exploit any private keys held by an agent.
Note, the superuser cannot compromise the private version
of the key, but can forward RSA authentication requests to
the user's agent, gaining accessing to whatever hosts
that user has access to. For this reason, I recommend
against providing RSA authentication access to the host
that stores the private version of the key. Also, I
recommend against forwarding the agent to untrusted hosts
with dubious security.
Unfortunately, an untrusted host can easily compromise the
X server of a remote client, if that client forwarded his
X11 session to the untrusted host. At that point, an
attacker could easily gain access to the ssh-agent
environment of the remote user, could install an invisible
keystroke logger, or otherwise run amok.
Also extremely disturbing is the possibility that the X
display is running under the super-user's privilege.
Although all responsible documentation strongly
discourages running X Windows as super-user, many people
ignore these warnings. In this case, X11 forwarding may
result in full root compromise of the ssh client host.
ssh -g
-R8080:intranet.example.com:80 shell.example.net.
As a result, the publicly accessible listener socket,
shell.example.net:8080 tunnels directly to
intranet.example.com:80.
ssh
-L8080:intranet.example.com:80 bastion.example.com.
By utilizing the -g flag, this socket is
generally available to the public network.
Authentication keys that lack the protection of a passphrase can result in a ripple effect throughout your network, or even out into other people's networks. It is vitally important that private keys be protected by mode 700, at most. Root compromises on a host with keys will necessarily compromise any account configured to accept null-passphrase keys stored on the compromised host.
The flipside of this feature is that the superuser on a
remote host may exploit any private keys held by an agent.
Note, the superuser cannot compromise the private version
of the key, but can forward RSA authentication requests to
the user's agent, gaining accessing to whatever hosts
that user has access to. For this reason, I recommend
against providing RSA authentication access to the host
that stores the private version of the key. Also, I
recommend against forwarding the agent to untrusted hosts
with dubious security.
Unfortunately, an untrusted host can easily compromise the
X server of a remote client, if that client forwarded his
X11 session to the untrusted host. At that point, an
attacker could easily gain access to the ssh-agent
environment of the remote user, could install an invisible
keystroke logger, or otherwise run amok.
Also extremely disturbing is the possibility that the X
display is running under the super-user's privilege.
Although all responsible documentation strongly
discourages running X Windows as super-user, many people
ignore these warnings. In this case, X11 forwarding may
result in full root compromise of the ssh client host.
Unfortunately, an untrusted host can easily compromise the X server of a remote client, if that client forwarded his X11 session to the untrusted host. At that point, an attacker could easily gain access to the ssh-agent environment of the remote user, could install an invisible keystroke logger, or otherwise run amok.
Also extremely disturbing is the possibility that the X display is running under the super-user's privilege. Although all responsible documentation strongly discourages running X Windows as super-user, many people ignore these warnings. In this case, X11 forwarding may result in full root compromise of the ssh client host.