Yes, this is a great switch. I also like the vendor's strong warnings against running agent forwarding in high-risk environments. I'm really happy to see these comments because many companies are rolling in ssh as a drop-in for telnet/ftp and have too little clue regarding the forwarding issues: both port and agent. Additionally, when you read articles, like the one I mention, that use port forwarding to access lower-risk zone devices from higher-risk zones, well, you pretty much know it's time to do a public service announcement. One user I know was approached for the support person for a turnkey system. Yup, could use ssh and wouldn't need a regular vpn account. I think the discussion needs to go from talking about admins using ssh to users getting talked into enabling unwise connectivity maybe... jt
Interesting analogy, admin who gives a blank root password. But in that case, the admin is very much in control. If a user on one of your managed devices builds an ssh tunnel to an external device s/he controls, the reverse connection means s/he has given access to your server from the internet. Additionally, depending on the port forwarding connections allowed in the client config, your server is the gateway into the rest of the organization for the attack. So at that point, people in security stop your life to have you explain why it is you allowed your server to be open from the Internet and then let it attack all other devices. No, it isn't fair admins get the worst treatment in an investigation many times.
It also isn't 'fair' that a userspace application can do so many things without any use of root authority. If a user tells you s/he wants to share that account via rsh, you laugh and won't start the daemon. If s/he shares out the account via vnc, especially with a password like 'password' that your normal filters would block, you might spot the open ports and shut it down with a warning. But put vnc in an ssh tunnel bound to localhost, well, how many of us are checking localhost connections? jt
Thanks for the post, and thanks for the great info on port knocking. I will review the SPA concept since good ideas are what keep the Internet alive. In this case, ssh port forwarding, we have a person who asks innocently enough for an outbound ssh tunnel, one to a server they control. Port-knocking offers no security against port forwarding allowing an open connection back into the intranet. So let's imagine this tunnel is done by an admin. A for effort, but if that tunnel into the organization doesn't meet remote access policies, it's a risk. Much, much worse are users who are coaxed into building a tunnel to a server so as to allow remote support. If the support vendor has a rogue employee, the employee with root/Admin (doing support, right?) can enable dynamic forwarding or static forwarding at the client software and set the client to launch auto-magically in the middle of the night. I'm not sure there's help either SPA or port-knocking can provide in these common ssh scenarios?
I hope the last line is back on track to discuss ssh. The issue with ssh, for me at least, is how much is 'userspace', right? Ask most UNIX sensei about people building tunnels, and they laugh because the user needs root for many networking functions. The client side abilities and linkage to a user-controlled external box is all it takes to puncture a hole in the perimeter--an unmonitorable one I might add. And if you ban outbound ssh at the firewall, well, that's no good. SSH can run on any TCP port the attacker configures. Allow outbound 80? How about 53 for dns? 25 from any internal host for mail operations open?
And now, what about internal users who are duped into building the outbound tunnel so as to enable support for a turnkey system? I admit you are very right. People who go with stupid configs deserve the worst. But the damage doesn't end with them, right? A successful intrusion on one platform soon ripples to others based on what passwords/credentials are harvested from the first.
You might try port forwarding and examine the traffic across your firewall logs. With my pix and IP Tables, the port forwarding traffic simply looks like return encrypted traffic. In the article, I describe how many people implementing ssh are 'mixing it up', using all the abilities in really bad ways. In fact, if you have a working ssh server on the internet, try to connect to it and build the port forwarding scheme I describe. If you can build the outgoing tunnel, the traffic from home will work, despite a firewall's normal restrictions against external-initiated traffic. An internal customer was approached by a support vendor for a turnkey system for just this kind of config. jt
SSH is a great tool, full of great abilities. Any tool with so many abilities is open to misunderstanding, misconfiguration, and misinterpretation. Ditto for Linux. if you felt my article condemns ssh, you're incorrect. jt
This is certainly one part of the ssh puzzle. And I'm glad to meet someone else who reads vendor documentation and follows it. That's not always followed. I see a lot of companies adopting ssh as an ftp/telnet replacement. Maybe a business partner only accepts ssh connections. Maybe there's a 'end plaintext' initiative. As many begin studying ssh, they gloss over port forwarding. They enable agent forwarding, and the users love it! If they see that warning, it's tough to understand; so some skip the warning. And that's the issue: how will your organization implement one of the world's best security AND connectivity tools out there? Write more--I like your reasoning. jt
I agree with a lot of this commentary. I can't believe how many root users want '.' in their path. Just as bad? 'su' or 'sudo su' . Add a little dash and get root-appropriate settings--don't inherit the PATH you have as a basic user. I agree that there are many things an intruder can do to a compromised system. That said, I think we should do as the SSH vendors recommend: DON'T use agent forwarding in a potentially high-risk environment. We don't need to add to a hacker's abilities by doing something that risky. I like ssh and think it's a great security AND connectivity tool. Job 1 is ensuring your network, server, etc architects understand all of ssh's abilities before enabling it wholesale. jt
Hmmm, fair summary. So how many know that ssh can act as both a nice, secure replacement for telnet/ftp/r* AND a traffic forwarding technology? As organizations go forward with their plaintext protocol replacement plans, folks assume ssh is an dropin. And it can be. So as your organization okays outbound ssh, at some point it must understand that decision enables private vpn connectivity into the organization. There are some great writers in this thread who know ssh security. Trouble is, that's not everyone. Those with some knowledge of port and agent forwarding create some awkward designs to get around those firewalls... So if folks step back and consider ssh's growing use, the articles advising you to use it as a private vpn, the way it can gateway access to normally closed off RFC 1918/3330 networks, etc; there's a lot of change going on and a lot of impacts to consider. jt.
There are a great many things you can do in addition to TCP Wrappers, but one step at a time I suppose. As you review the example configuration, proposed by another writer, TCP Wrappers wouldn't have done much. The server would have accepted traffic from the internal PC. Now remember, the server will return traffic back through the tunnel, so TCP wrappers isn't a factor for the PC. If the pc has an active firewall, the context is through the original 'outbound' tunnel, so the firewall calls it legit. and if the firewall can somehow inspect encrypted traffic, the user will allow it since he configured his pc to the be conduit from a DMZ host to the patching server, right? Get some Virtual PC, VMWare or Xen going to see this work in detail... Fascinating stuff. JT
No, not from experience. I just remembered that article. As I considered the implications of the design, the emphasis just seemed to suggest itself. I have seen a lot of silly shortcuts, though, done in the name of 'getting the job done' without 'getting paranoid for no good reason'. But never, ever ask an old consultant to talk old stories. The one place that had an NT4 member server on the Internet itself with full domain communications through the firewall back to the one internal domain... Yes, life is full of novel designs, eh? jt One day I relate the discussion with the consultant who swore rsh was secureable... Drrrrrrr!
Great response. As you read from other responses, some don't know about the risks of Agent forwarding. They either don't read the vendor's very strong warning against it or they don't understand the full impacts. So they enable it. And I agree with you; enabling it in a DMZ setting makes for very strong risks. And I'm amazed why people don't see the risk as clearly as you do. I _like_ agent forwarding in an intranet setting when I'm working as a basic user. I have my private key on a cdrom. I ssh to a gateway machine, and from there, I can access the other servers, one at a time. Do intranet hosts get hacked? Sure do. But maybe a little less than the DMZ hosts facing the Internet? It helps to have a gateway box with tight security and good logs and IDS... jt
SSH is one of the neatest tools in a security person's toolbelt. It is similar to sendmail in terms of complex configurations that have odd, unintended effects. In the one target scenario, Rogue Insider has the work pc connect to the RI-controlled server. Port forwarding rules are in place on the CLIENT software. So now, RInsider can initiate traffic from the controlled server, on the Internet, is to the SSH Client software. And that is the challenge, to see how CLIENT software, under the control of Rogue Insider, can enable internal access from a server on the Internet. Now, there are several articles on these setups, a great number more than when I was thinking through the vulnerability two years ago. Does your workplace have self-important users who will foolishly enable this 'private VPN' that doesn't need authentication to the company remote access machine? 8-) jt
You're not stupid by any means. There is a lot of ssh activity nowadays, and many organizations don't understand the problems they've created. The illustration regarding access to an intranet patching server is a great example of the convoluted designs many are proposing. A user group bought a turnkey system from a vendor. how will the vendor support this intranet host? The user is instructed to ssh to the vendor server and . . .
I appreciate your commonsense prohibitions. Now imagine an organization feels people should get outbound ssh to the internet to the degree they get ftp. Better security, right? Hmmmmmmmm, so if Rogue Insider gets connectivity to an ssh server s/he controls? That connection is now an afterhours direct path into the company intranet, and there's little one can do. In this case, your very excellent recommendations seem to apply a little less. This is the ssh challenge: to get all the experts knowledgeable on ALL of ssh's abilities. Get a plan on handling ssh to the dmz and keep folks from using port forwarding in unwise ways. For every ssh expert on this list who was very wise in pointing out the vendor's security statements, I think we can see there are quite a few who struggle with the topic. It's a very difficult topic. I'm glad you took the time to strongly support the solid principle that DMZ hosts need to be contained. Admins who break that rule with any tool jeopardize much. jt
As I review the comment, I find several are insightful and good. Others? People should not have a first beer before posting to slashdot. Here are the issues: 1) many are using ssh as an ftp/telnet drop-in replacement; 2) few understand port forwarding or how agent forwarding works and dismiss vendor recommendations in both their designs, and surprisingly, articles that are available; and 3) there are many articles on using ssh as a private vpn from home. These trends mean there must be greater awareness on SSH security and design. 4) support vendors are asking your organization's users to provide connectivity to their PC's via an outbound ssh tunnel. I'm glad readers like you have studied the risks and the vendor recommendations. Tschuess, JT
Did the article state the file is transmitted? No, not at all. I resisted going into great detail because many times too much detail has people misunderstanding and writing foolish comments. So I avoided the detail to ensure I wouldn't read people, who misunderstand a simple concept, write foolish comments. Or so I had hoped. jt
I like your summary... I think other points are this: consider banning agent forwarding in high-risk environments, as all the vendors and security experts recommend. Also, understand a lot of folks are using ssh as a drop-in replacement for ftp/telnet. Get a security team together (firewall, server, OS, etc) and discuss port forwarding issues well in advance of the implementation. A support vendor tried to talk an intranet user into PC support done with SSH at a place I know. Hmmmmm, how long before the vendor has a rogue support person building cron/AT jobs that connect out at 02:00am and have dynamic port forwarding enabled? To a firewall, that's a legit inside-to-outside connection... Thanks for taking the time to respond with great understanding and with professionalism, I might add.
jt
So let's consider a typical ssh configuration. The intranet machine has the admin's private key. S/he connects to the first DMZ machine. Now because agent forwarding is enabled, despite the vendor's strong recommendations, the admin goes to DMZ device c. The Intruder observes this and can misuse agent forwarding's abilities to hit other dmz machines. Why? In the same way box b proxies the authentication to dmz device c, the Intruder can hit other devices and box B will proxy that authentication. Difficult to understand? Sure is! So why don't people just do as the vendors recommend and not use it in high risk environments? Being difficult to understand means this risk is dismissed as irrelevent and admins take the easy route: use agent forwarding.
jt
The news is this: 1) organizations are using ssh as a wholesale tradeout of ftp/telnet; 2) support vendors want to use the tunnel to support your intranet PC; 3) there are many articles discussing how to use SSH as a 'private VPN'. At this point, organizations need to ensure all groups in charge of security have thought through the issues. I hope this explains how a common vulnerability is bigger news: it's growing and outside of ssh people like you and me, too many don't know this risk exists. jt
No, as you study ssh, you find the first box has the private key. In agent-forwarding, an intermediary machine will proxy the authentication from the first box to the 3rd and final box. IF someone has root on that intermediary box, without having your private key, without your password, etc, s/he can proxy the authentication from your first box to all other boxen for which you have an account and presence. Admittedly, this is very difficult to understand, but the vendors warn against agent-forwarding in strong language. There are great ssh book by Apress (my fav) and O'Reilly.
I hope this helps. If not, leave a comment at the informit site and I'll try a longer follow up.
jt
Thanks for your great post. I wouldn't be surprised if most who read it rush over it. You see, ssh's Rep is as a great drop-in for ftp/telnet/r*. Some Unix folks have little networking background (Ahhh, the scourge of DHCP!), so they gloss over the 'other stuff'. This is in the documentation and EVERY vendor is very frank and honest about the risks. But folks get so keyed into the agent forwarding benefits, they write it off.
As you review the internet literature on the topic, you'll see the configuration I discuss is commonly recommended for those who want a 'private vpn'. So spread the word about this risk--use small words though.
jt
No, not at all. When you consider the forwarding abilities of both the ssh client and server implementations, it is possible to build what looks to be an insider-initiated tunnel to the outside. Safe, right? Instead, the tunnel is used to force the traffic from the remote server back into the tunnel, and from there, throughout the intranet, including RFC 1918/3330 addresses normally unreachable from the Internet. Let me know if some kind of video file would help explain a very difficult topic in ssh.
Many organizations are swapping out telnet/ftp for ssh. That part's great. It's the uncontrollable forwarding abilities that seem the biggest challenge.
Slashdot Mirror
Yes, this is a great switch. I also like the vendor's strong warnings against running agent forwarding in high-risk environments. I'm really happy to see these comments because many companies are rolling in ssh as a drop-in for telnet/ftp and have too little clue regarding the forwarding issues: both port and agent. Additionally, when you read articles, like the one I mention, that use port forwarding to access lower-risk zone devices from higher-risk zones, well, you pretty much know it's time to do a public service announcement. One user I know was approached for the support person for a turnkey system. Yup, could use ssh and wouldn't need a regular vpn account. I think the discussion needs to go from talking about admins using ssh to users getting talked into enabling unwise connectivity maybe... jt
Interesting analogy, admin who gives a blank root password. But in that case, the admin is very much in control. If a user on one of your managed devices builds an ssh tunnel to an external device s/he controls, the reverse connection means s/he has given access to your server from the internet. Additionally, depending on the port forwarding connections allowed in the client config, your server is the gateway into the rest of the organization for the attack. So at that point, people in security stop your life to have you explain why it is you allowed your server to be open from the Internet and then let it attack all other devices. No, it isn't fair admins get the worst treatment in an investigation many times.
It also isn't 'fair' that a userspace application can do so many things without any use of root authority. If a user tells you s/he wants to share that account via rsh, you laugh and won't start the daemon. If s/he shares out the account via vnc, especially with a password like 'password' that your normal filters would block, you might spot the open ports and shut it down with a warning. But put vnc in an ssh tunnel bound to localhost, well, how many of us are checking localhost connections? jt
Thanks for the post, and thanks for the great info on port knocking. I will review the SPA concept since good ideas are what keep the Internet alive. In this case, ssh port forwarding, we have a person who asks innocently enough for an outbound ssh tunnel, one to a server they control. Port-knocking offers no security against port forwarding allowing an open connection back into the intranet. So let's imagine this tunnel is done by an admin. A for effort, but if that tunnel into the organization doesn't meet remote access policies, it's a risk. Much, much worse are users who are coaxed into building a tunnel to a server so as to allow remote support. If the support vendor has a rogue employee, the employee with root/Admin (doing support, right?) can enable dynamic forwarding or static forwarding at the client software and set the client to launch auto-magically in the middle of the night. I'm not sure there's help either SPA or port-knocking can provide in these common ssh scenarios?
I hope the last line is back on track to discuss ssh. The issue with ssh, for me at least, is how much is 'userspace', right? Ask most UNIX sensei about people building tunnels, and they laugh because the user needs root for many networking functions. The client side abilities and linkage to a user-controlled external box is all it takes to puncture a hole in the perimeter--an unmonitorable one I might add. And if you ban outbound ssh at the firewall, well, that's no good. SSH can run on any TCP port the attacker configures. Allow outbound 80? How about 53 for dns? 25 from any internal host for mail operations open? And now, what about internal users who are duped into building the outbound tunnel so as to enable support for a turnkey system? I admit you are very right. People who go with stupid configs deserve the worst. But the damage doesn't end with them, right? A successful intrusion on one platform soon ripples to others based on what passwords/credentials are harvested from the first.
You might try port forwarding and examine the traffic across your firewall logs. With my pix and IP Tables, the port forwarding traffic simply looks like return encrypted traffic. In the article, I describe how many people implementing ssh are 'mixing it up', using all the abilities in really bad ways. In fact, if you have a working ssh server on the internet, try to connect to it and build the port forwarding scheme I describe. If you can build the outgoing tunnel, the traffic from home will work, despite a firewall's normal restrictions against external-initiated traffic. An internal customer was approached by a support vendor for a turnkey system for just this kind of config. jt
Excellent! I'll reconstruct my test environment and make something good happen... jt
SSH is a great tool, full of great abilities. Any tool with so many abilities is open to misunderstanding, misconfiguration, and misinterpretation. Ditto for Linux. if you felt my article condemns ssh, you're incorrect. jt
This is certainly one part of the ssh puzzle. And I'm glad to meet someone else who reads vendor documentation and follows it. That's not always followed. I see a lot of companies adopting ssh as an ftp/telnet replacement. Maybe a business partner only accepts ssh connections. Maybe there's a 'end plaintext' initiative. As many begin studying ssh, they gloss over port forwarding. They enable agent forwarding, and the users love it! If they see that warning, it's tough to understand; so some skip the warning. And that's the issue: how will your organization implement one of the world's best security AND connectivity tools out there? Write more--I like your reasoning. jt
I agree with a lot of this commentary. I can't believe how many root users want '.' in their path. Just as bad? 'su' or 'sudo su' . Add a little dash and get root-appropriate settings--don't inherit the PATH you have as a basic user. I agree that there are many things an intruder can do to a compromised system. That said, I think we should do as the SSH vendors recommend: DON'T use agent forwarding in a potentially high-risk environment. We don't need to add to a hacker's abilities by doing something that risky. I like ssh and think it's a great security AND connectivity tool. Job 1 is ensuring your network, server, etc architects understand all of ssh's abilities before enabling it wholesale. jt
Hmmm, fair summary. So how many know that ssh can act as both a nice, secure replacement for telnet/ftp/r* AND a traffic forwarding technology? As organizations go forward with their plaintext protocol replacement plans, folks assume ssh is an dropin. And it can be. So as your organization okays outbound ssh, at some point it must understand that decision enables private vpn connectivity into the organization. There are some great writers in this thread who know ssh security. Trouble is, that's not everyone. Those with some knowledge of port and agent forwarding create some awkward designs to get around those firewalls... So if folks step back and consider ssh's growing use, the articles advising you to use it as a private vpn, the way it can gateway access to normally closed off RFC 1918/3330 networks, etc; there's a lot of change going on and a lot of impacts to consider. jt.
I look forward to reading your great security writings, Anonymous Coward. Please post the urls. jt
There are a great many things you can do in addition to TCP Wrappers, but one step at a time I suppose. As you review the example configuration, proposed by another writer, TCP Wrappers wouldn't have done much. The server would have accepted traffic from the internal PC. Now remember, the server will return traffic back through the tunnel, so TCP wrappers isn't a factor for the PC. If the pc has an active firewall, the context is through the original 'outbound' tunnel, so the firewall calls it legit. and if the firewall can somehow inspect encrypted traffic, the user will allow it since he configured his pc to the be conduit from a DMZ host to the patching server, right? Get some Virtual PC, VMWare or Xen going to see this work in detail... Fascinating stuff. JT
No, not from experience. I just remembered that article. As I considered the implications of the design, the emphasis just seemed to suggest itself. I have seen a lot of silly shortcuts, though, done in the name of 'getting the job done' without 'getting paranoid for no good reason'. But never, ever ask an old consultant to talk old stories. The one place that had an NT4 member server on the Internet itself with full domain communications through the firewall back to the one internal domain... Yes, life is full of novel designs, eh? jt One day I relate the discussion with the consultant who swore rsh was secureable... Drrrrrrr!
Great response. As you read from other responses, some don't know about the risks of Agent forwarding. They either don't read the vendor's very strong warning against it or they don't understand the full impacts. So they enable it. And I agree with you; enabling it in a DMZ setting makes for very strong risks. And I'm amazed why people don't see the risk as clearly as you do. I _like_ agent forwarding in an intranet setting when I'm working as a basic user. I have my private key on a cdrom. I ssh to a gateway machine, and from there, I can access the other servers, one at a time. Do intranet hosts get hacked? Sure do. But maybe a little less than the DMZ hosts facing the Internet? It helps to have a gateway box with tight security and good logs and IDS... jt
SSH is one of the neatest tools in a security person's toolbelt. It is similar to sendmail in terms of complex configurations that have odd, unintended effects. In the one target scenario, Rogue Insider has the work pc connect to the RI-controlled server. Port forwarding rules are in place on the CLIENT software. So now, RInsider can initiate traffic from the controlled server, on the Internet, is to the SSH Client software. And that is the challenge, to see how CLIENT software, under the control of Rogue Insider, can enable internal access from a server on the Internet. Now, there are several articles on these setups, a great number more than when I was thinking through the vulnerability two years ago. Does your workplace have self-important users who will foolishly enable this 'private VPN' that doesn't need authentication to the company remote access machine? 8-) jt
You're not stupid by any means. There is a lot of ssh activity nowadays, and many organizations don't understand the problems they've created. The illustration regarding access to an intranet patching server is a great example of the convoluted designs many are proposing. A user group bought a turnkey system from a vendor. how will the vendor support this intranet host? The user is instructed to ssh to the vendor server and . . .
I appreciate your commonsense prohibitions. Now imagine an organization feels people should get outbound ssh to the internet to the degree they get ftp. Better security, right? Hmmmmmmmm, so if Rogue Insider gets connectivity to an ssh server s/he controls? That connection is now an afterhours direct path into the company intranet, and there's little one can do. In this case, your very excellent recommendations seem to apply a little less. This is the ssh challenge: to get all the experts knowledgeable on ALL of ssh's abilities. Get a plan on handling ssh to the dmz and keep folks from using port forwarding in unwise ways. For every ssh expert on this list who was very wise in pointing out the vendor's security statements, I think we can see there are quite a few who struggle with the topic. It's a very difficult topic. I'm glad you took the time to strongly support the solid principle that DMZ hosts need to be contained. Admins who break that rule with any tool jeopardize much. jt
As I review the comment, I find several are insightful and good. Others? People should not have a first beer before posting to slashdot. Here are the issues: 1) many are using ssh as an ftp/telnet drop-in replacement; 2) few understand port forwarding or how agent forwarding works and dismiss vendor recommendations in both their designs, and surprisingly, articles that are available; and 3) there are many articles on using ssh as a private vpn from home. These trends mean there must be greater awareness on SSH security and design. 4) support vendors are asking your organization's users to provide connectivity to their PC's via an outbound ssh tunnel. I'm glad readers like you have studied the risks and the vendor recommendations. Tschuess, JT
Did the article state the file is transmitted? No, not at all. I resisted going into great detail because many times too much detail has people misunderstanding and writing foolish comments. So I avoided the detail to ensure I wouldn't read people, who misunderstand a simple concept, write foolish comments. Or so I had hoped. jt
Exactly. Great analogy as well. jt
I like your summary... I think other points are this: consider banning agent forwarding in high-risk environments, as all the vendors and security experts recommend. Also, understand a lot of folks are using ssh as a drop-in replacement for ftp/telnet. Get a security team together (firewall, server, OS, etc) and discuss port forwarding issues well in advance of the implementation. A support vendor tried to talk an intranet user into PC support done with SSH at a place I know. Hmmmmm, how long before the vendor has a rogue support person building cron/AT jobs that connect out at 02:00am and have dynamic port forwarding enabled? To a firewall, that's a legit inside-to-outside connection... Thanks for taking the time to respond with great understanding and with professionalism, I might add. jt
So let's consider a typical ssh configuration. The intranet machine has the admin's private key. S/he connects to the first DMZ machine. Now because agent forwarding is enabled, despite the vendor's strong recommendations, the admin goes to DMZ device c. The Intruder observes this and can misuse agent forwarding's abilities to hit other dmz machines. Why? In the same way box b proxies the authentication to dmz device c, the Intruder can hit other devices and box B will proxy that authentication. Difficult to understand? Sure is! So why don't people just do as the vendors recommend and not use it in high risk environments? Being difficult to understand means this risk is dismissed as irrelevent and admins take the easy route: use agent forwarding. jt
The news is this: 1) organizations are using ssh as a wholesale tradeout of ftp/telnet; 2) support vendors want to use the tunnel to support your intranet PC; 3) there are many articles discussing how to use SSH as a 'private VPN'. At this point, organizations need to ensure all groups in charge of security have thought through the issues. I hope this explains how a common vulnerability is bigger news: it's growing and outside of ssh people like you and me, too many don't know this risk exists. jt
No, as you study ssh, you find the first box has the private key. In agent-forwarding, an intermediary machine will proxy the authentication from the first box to the 3rd and final box. IF someone has root on that intermediary box, without having your private key, without your password, etc, s/he can proxy the authentication from your first box to all other boxen for which you have an account and presence. Admittedly, this is very difficult to understand, but the vendors warn against agent-forwarding in strong language. There are great ssh book by Apress (my fav) and O'Reilly. I hope this helps. If not, leave a comment at the informit site and I'll try a longer follow up. jt
Thanks for your great post. I wouldn't be surprised if most who read it rush over it. You see, ssh's Rep is as a great drop-in for ftp/telnet/r*. Some Unix folks have little networking background (Ahhh, the scourge of DHCP!), so they gloss over the 'other stuff'. This is in the documentation and EVERY vendor is very frank and honest about the risks. But folks get so keyed into the agent forwarding benefits, they write it off. As you review the internet literature on the topic, you'll see the configuration I discuss is commonly recommended for those who want a 'private vpn'. So spread the word about this risk--use small words though. jt
No, not at all. When you consider the forwarding abilities of both the ssh client and server implementations, it is possible to build what looks to be an insider-initiated tunnel to the outside. Safe, right? Instead, the tunnel is used to force the traffic from the remote server back into the tunnel, and from there, throughout the intranet, including RFC 1918/3330 addresses normally unreachable from the Internet. Let me know if some kind of video file would help explain a very difficult topic in ssh. Many organizations are swapping out telnet/ftp for ssh. That part's great. It's the uncontrollable forwarding abilities that seem the biggest challenge.