Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Overconfidence in SSH Protection

Zonk posted more than 8 years ago | from the don't-be-too-proud-of-this-technological-terror dept.

194

nitsudima writes to mention a post on the Informit site about the common misunderstandings surrounding SSH, and how well-intentioned admins may be creating holes in their own security by using it. From the article: "In UNIX, all things are files. To send network traffic, UNIX writes the traffic to the network device file. In this case, the connection to Box A (and that private key used for authentication) is a socket file. This file will shuttle the authentication traffic between Box A and Box P. So what's the risk? Maybe the hacker can't get a copy of the private key through the socket file, but something better (from his/her view) can be done. If the hacker has root on Box D, he or she can point a private copy of the agent forwarding software to that socket file and thereby point the authentication process to the administrator's credentials--the ones kept on the 'safe' intranet. What are the chances that the administrator has configured access to all the DMZ servers he controls?"

cancel ×

194 comments

Sorry! There are no comments related to the filter you selected.

overconfidence in first post!!111111 (-1, Troll)

Anonymous Coward | more than 8 years ago | (#15414777)

secure this!11

SSH sucks (-1, Flamebait)

Anonymous Coward | more than 8 years ago | (#15414778)

So does Linux.

Go vista!

wait (0)

Anonymous Coward | more than 8 years ago | (#15414856)

I run SSH on Vista... does that mean Vista sucks too?

Re:wait (0, Troll)

Anonymous Coward | more than 8 years ago | (#15415173)

I run SSH on Vista... does that mean Vista sucks too?

I run my cock across your mummy's face ... that means she sucks, too.

Huh? What? (4, Insightful)

XanC (644172) | more than 8 years ago | (#15414788)

I consider myself fairly competent as far as this kind of stuff goes, but I just couldn't follow that summary at all. Maybe it's just because it's so late. Can someone post a more sensible summary of an attack?

Re:Huh? What? (1)

jroyale (969238) | more than 8 years ago | (#15414829)

No summary for you. It is like this guy writes cliffhangers for television shows. Maybe next season he'll finish some of his thoughts.

Re:Huh? What? (4, Interesting)

limegreen (516173) | more than 8 years ago | (#15414849)

I think part of the article is trying to say that users can enable their own ssh tunnels to home, and thus if their home network is compromised there is an easy route into the office intranet.

Re:Huh? What? (3, Insightful)

Matey-O (518004) | more than 8 years ago | (#15415562)

I think part of the article is trying to say that users can enable their own ssh tunnels to home, and thus if their home network is compromised there is an easy route into the office intranet.
But how is this not the case for ANY connection from a home network to the office...VPN opens up the same issues too.

Re:Huh? What? (5, Informative)

Riku (740152) | more than 8 years ago | (#15414864)

Here's a summary for you:

User A on box foo:
foo> ssh-agent xterm
foo> ssh-add
  * enters their pass key *
User A can now ssh to any box that has their public key in box:$HOME/.ssh/authorized_keys

User B (evul hacker with root on box foo):
foo# SSH_AGENT_PID=XXXX; export SSH_AGENT_PID
foo# SSH_AUTH_SOCK=/tmp/ssh-YYYY/ZZZZ; export SSH_AUTH_SOCK
User B now can ssh to any box that User A can, as above.
(where XXXX, YYYY, and ZZZZ are determined by evul hacker)

Re:Huh? What? (4, Insightful)

Onan (25162) | more than 8 years ago | (#15414996)

User B (evul hacker with root on box foo):
foo# SSH_AGENT_PID=XXXX; export SSH_AGENT_PID
foo# SSH_AUTH_SOCK=/tmp/ssh-YYYY/ZZZZ; export SSH_AUTH_SOCK
Uh, this is hardly the only way that someone with root on the machine from which you're authenticating can obtain your credentials. Far more effective than this would be for them to simply take your private key file and grab your passphrase as you enter it; that would allow them to use these credentials forever in the future, rather than being limited to when you have an agent running on their machine.

So... how does this even remotely approach being news? Yes, if you type your passwords into a machine on which someone else has root, you have given those passwords to them! The horror! I had no idea!

The best thing I can say about this article summary is that it did not misrepresent the actual piece. The article itself was also muddled tripe, filled with semi-true and completely-irrelevant noise like "in unix, everything is a file..."

It appears that the author is just a firewall admin who's offended that ssh can be used to thwart his precious acls, and invested in giving the tool a bad name.

But easiness of avoiding acls is crucial ... (0)

Anonymous Coward | more than 8 years ago | (#15415194)

Overall I like the article for one strong point :

ssh allows EASILY circumvent a lot of security measures ...

Vulnerability requires users stupidity - like in the example here but man, can you honestly tell
you always had separate keys for each security zone ? You never used agent/X forwarding between zones ?

Re:Huh? What? (5, Informative)

Anonymous Coward | more than 8 years ago | (#15415260)

The article is about a common misconfiguration with regard to agent forwarding. The DMZ hosts aren't supposed to be safe, that's why they're in the DMZ and not in the intranet. The admin must assume that root on these machines is compromised. Consequently he doesn't store his private keys on any of the DMZ machines. But what many overlook, possibly because they don't use the feature, is agent forwarding. Once the admin has logged into a compromised DMZ host, access to his credentials is extended to the DMZ host by that ominous socket. The file itself never leaves the admin's computer, but if agent forwarding is enabled, root on the DMZ host can now point other hosts on the intranet to the authentication facility on the admin's computer. This misconfiguration enables the attacker to hop from the DMZ to the intranet. The correct way to avoid this is to disable agent forwarding (on the admin's computer, not just on the DMZ hosts, of course).

Re:Huh? What? (1)

swdunlop (103066) | more than 8 years ago | (#15415716)

"Once the admin has logged into a compromised DMZ host, access to his credentials is extended to the DMZ host by that ominous socket"

Only if he specifies -A on the command line -- authentication agent forwarding is disabled by default; any documentation referencing -A and agent forwarding also eplains, in the next paragraph, the peril in using -A with an untrusted host. (Duh)

Re:Huh? What? (2, Interesting)

ipso_facto (22710) | more than 8 years ago | (#15415086)

If someone gets root on one of your boxes, all bets are off as there's a very good chance that they'll get root on another one of them (by keylogging passwords, brute forcing the password on a sudo enabled account, passwordless ssh keys, hijacking a session etc etc)

Wash, rinse, repeat.

Before you know it your whole DMZ is rooted (in more than one sense).

In short:
- If you find a compromised box on your network, assume there's more than one and order pizza... you're in for a long night.
- Segregate your networks so if someone, say, gets at your DMZ there's no way to get into your internal or other production network i.e. no ssh or accessible services on your firewall machines on the DMZ interfaces.

i.e. It's not just an issue with ssh.

Worse than that! (0)

Anonymous Coward | more than 8 years ago | (#15415197)

User B (evul hacker with root on box foo):
foo# SSH_AGENT_PID=XXXX; export SSH_AGENT_PID
foo# SSH_AUTH_SOCK=/tmp/ssh-YYYY/ZZZZ; export SSH_AUTH_SOCK
User B now can ssh to any box that User A can, as above.
(where XXXX, YYYY, and ZZZZ are determined by evul hacker)

It's worse than this! In your example, the SSH user has the authentication agent running on foo, so it's possible for anyone with root on foo to reuse the agent to authenticate to other machines. However, it's also possible to use the agent on any other machine that the SSH user has connected to, provided that they have enabled agent forwarding.

That's the problem! The administrator thinks he is safe because he is only running the ssh agent on his desktop machine. But he's not read the documentation, or thought about the implications of using agent forwarding. When he has agent forwarding enabled, every machine he connects to gets access to the ssh agent on his own machine. And, effectively, access to his private key.

To be perfectly honest it bothers me to think that there are any Unix administrators who are not already aware of this well-known issue.

Re:Huh? What? (2, Informative)

ladadadada (454328) | more than 8 years ago | (#15414868)

It's not just you. I had to re-read it several times.

I think the main point (the one the article submitter picked up on) was that if an attacker can compromise your DMZ box (the most vulnerable box your company owns and hence the least trusted box your company owns) that has no private ssh keys stored on it and can't connect to any other trusted box but does have trusted boxes connecting to it, then he can use that to compromise further trusted boxes inside the organisation.

To put it another way, if you ssh to an attacker's machine using agent forwarding he can probably ssh back to yours.

Re:Huh? What? (0, Troll)

andy753421 (850820) | more than 8 years ago | (#15414918)

Maybe this randomly generated summary will help... at least it can't be much confusing :)

"SSH the wonder tool of the security set. I read one article about a vicious cycle! Want to know more? Comment on this article below. We'll skewer FTP and make a mockery of rsh. There are two types of port forwarding: * Local forwarding. Allows the client and the patching server, something normally verboten. The DMZ servers would route through the socket file, but something better (from his/her view) can be done. If the hacker can't get a copy of the agent forwarding risks. Depending on the local host adapter on any port the user chooses."

Re:Huh? What? (1)

Tiro (19535) | more than 8 years ago | (#15415030)

That's not funny. Some of us actually care about this story. You're just wasting time.

MitM (1)

tm2b (42473) | more than 8 years ago | (#15415097)

As far as I can tell, they're just describing an instance of the well-known problem of the man-in-the-middle attack.

This is not a vulnerability if you know the other key's hash/residue and compare it each session, as ssh can be configured to do.

Nothing to see here, move along.

Re:Huh? What? (1)

MT628496 (959515) | more than 8 years ago | (#15415699)

Wow, news flash: Misconfiguring ssh will result in a security hole! Who ever would have guessed?

All I need is root? (5, Insightful)

Anonymous Coward | more than 8 years ago | (#15414793)

So all I need to do is to get a root access to a Linux server and I can spy normal users there? Whoah, now this is what I call news.

Re:All I need is root? (2, Funny)

louzerr (97449) | more than 8 years ago | (#15415397)

... and your e-mail administrator can read your e-mail ... ... and your network administrator can see what web sites you're visiting ... ... and your ISP can watch your internet traffic ... ... and the NSA can listen to your phone ...

So, the real trick is just to live a life so borring none of these people will care to spy on you. Not all that hard, really. Considering you're on /. - you're probably doing okay.

Uh? (-1, Redundant)

Anonymous Coward | more than 8 years ago | (#15414794)

Okay... WHAT? I don't follow that summary at all.

Root (3, Insightful)

L0rdJedi (65690) | more than 8 years ago | (#15414800)

Yep, just gotta get root. Of course, at that point, you probably have more to worry about than someone redirecting your ssh session.

Re:Root (1)

lagerbottom (704499) | more than 8 years ago | (#15415386)

Whew, I was worried no one was going to say this as I was reading the comments.

erm.. (0)

Anonymous Coward | more than 8 years ago | (#15414801)

SSH port forwarding can cause trouble. Where is the new?

dont really understand the problem. (4, Insightful)

geoff lane (93738) | more than 8 years ago | (#15414803)

If you gain access to a system within the DMZ you've already broken in ... ssh has nothing to do with it.

Any sysadmin who configures sshd to allow direct access to a root account is incompetent and deserves to clean up the resulting mess when they are cracked.

So what should we worry about again?

OpenBSD? (2, Insightful)

jawtheshark (198669) | more than 8 years ago | (#15414816)

Any sysadmin who configures sshd to allow direct access to a root account is incompetent and deserves to clean up the resulting mess when they are cracked.

So you are calling the OpenBSD guys incompetent? After all, if you enable SSH in the default installation, you can SSH into that machine including as root.

Re:OpenBSD? (0)

Anonymous Coward | more than 8 years ago | (#15414886)

But it still requires the root password.
Granted, I disable rootly ssh access as the _first_ thing I do when I get my OpenBSD install going but in the mean time -- the hacker still needs my password to get rootly.

Re:OpenBSD? (0)

Anonymous Coward | more than 8 years ago | (#15414991)

So you are calling the OpenBSD guys incompetent? After all, if you enable SSH in the default installation, you can SSH into that machine including as root.

Incompetent? Not at all.

Overly confident in their (openssh) software? Yes.

In what software did you think the "only one remote hole in the default install" was in, anyway?

Re:OpenBSD? (1)

jawtheshark (198669) | more than 8 years ago | (#15415023)

In what software did you think the "only one remote hole in the default install" was in, anyway?

I think it was ssh, but frankly... One remote hole in 8 years... I would be confident in that software too!

Re:OpenBSD? (1, Interesting)

Anonymous Coward | more than 8 years ago | (#15415067)

That's because openssh is no longer 'on' in the default install, so any holes it might have are no longer exploitable out of the box. How many holes in the last 8 years after you turn on essential services? Heck, NT4 had no remotely exploitable holes when it got its gov certification, since it was for a stand-alone machine with no network connection that was tested.

Re:OpenBSD? (1)

jawtheshark (198669) | more than 8 years ago | (#15415153)

That's because openssh is no longer 'on' in the default install,

That's odd, because I installed 3.9 last wednesday and ssh was definately enabled on default install. You don't have to take my word for it, just head over to the Installation FAQ [openbsd.org] and see for yourself:

Start sshd(8) by default? [yes] y

If asking a question that defaults to "yes" isn't "default install", I don't know what it is.

Re:dont really understand the problem. (1)

nfarrell (127850) | more than 8 years ago | (#15414823)

Agreed. This article doesn't appear to say anything insightful. The biggest problem is only alluded to, and that's the monoculture one: if everyone uses SSH to supply encryption/authentication services, a single bug could allow an SSH-worm to achieve critical mass.

Re:dont really understand the problem. (3, Interesting)

FuryG3 (113706) | more than 8 years ago | (#15414848)

I agree completely. Remote root login is disabled by default, and system administrators should *not* enable it unless there is some damned good reason. Too often I have seen sysadmins simply enable root login, and twice now I've seen someone do key exchanges so that they can 'seemlessly' ssh as root between all of their servers.

Duh.

Re:dont really understand the problem. (1)

abertoll (460221) | more than 8 years ago | (#15414951)

Exactly. If you essentially have only one authentication to get into ALL your machines, then anything compromised includes your entire network.

It's interesting that this site is sponsored by Microsoft:
http://www.informit.com/ [informit.com]

Re:dont really understand the problem. (0)

Anonymous Coward | more than 8 years ago | (#15414978)

Didn't confirmed it, but I just knew, just knew while reading "MSN search" phrase when article's topic included the SSH acronym and there were no "Google" string out there.

Re:dont really understand the problem. (5, Insightful)

ladadadada (454328) | more than 8 years ago | (#15414953)

Not quite. If you have broken into the DMZ, that's all you have. Even mildly competent sysadmins know not to trust the DMZ and therefore you do not automatically have access to the rest of the network, nor do you have access to any confidential documents.

The exploit mentioned in the article doesn't rely on ssh being configured to connect directly to root. It relies on the attacker having gained root access on the box being ssh'd to by the sysadmin. Once the sysadmin has ssh'd to the comnpromised box (as any user) the attacker can then ssh to any other box the sysadmin has configured to use agent forwarding.

Two solutions to prevent this compromise of the rest of the network:
1) Don't allow the DMZ box to ssh anywhere; firewall it off. There should be no need to ssh FROM the DMZ box, only TO it.

2) Use a different public/private key pair for each box. That way, if you didn't firewall the DMZ off it would still fail on the key authentication. The drawback of this is a) the attacker can still ssh to your admin box which contains all of the private keys and b) you lose most of the advantage of agent forwarding; the ability to ssh through a chain of boxes without any but the first needing to store the private key.

I suppose the underlying message in the article is "You REALLY can't trust anything in a DMZ that may have been compromised. ssh is a tool that can be turned against you if one of your machines is compromised."

Re:dont really understand the problem. (2, Informative)

Athanasius (306480) | more than 8 years ago | (#15415187)

1) Don't allow the DMZ box to ssh anywhere; firewall it off. There should be no need to ssh FROM the DMZ box, only TO it.

Or better yet, don't allow the DMZ host to initiate *any* connection outbound from itself, if the services present on it don't need to do such, or failing that, disallow it initiating any connection that isn't out the internet-only-facing interface(s).

However, that's still not what the attack is exploiting, and wouldn't prevent the attack.

The 'attack' is taking an (I)Internal (S)erver, an (I)nternal (W)orkstation, and a (D)MZ host. Your firewall/ACLs are set such that IS can't receive, or will reject, any connection from D. However IS will accept connections from IW, and furthermore IW can ssh to D. So, the well-meaning admin of D, using IW, ssh's to D, setting up a tunnel to forward traffic on port Dx on D back to IW, port IWx, and also ssh's from IW to IS, forwarding IWx to a service on IS. Thus you can now connection to (D's) localhost:Dx and end up talking to the service on IS.

At no point is any connection initiated from D outside of itself, as the data is simply passing back through the ssh tunnel from IW to D, and then back further from IW to IS. And, no, you can't firewall D from talking to any but necessary ports on D, as we're assuming root compromise of D and thus all such bets are off.

Now, if someone has compromised D *and* can hijack this tunnel D IW IS they have access to IS.

Of course the real solution to the base problem is to have IS set up in some way to push data out to D, such that IW's user/D's admin doesn't have to play such silly and dangerous games in the first place. Any such 'administrator' setting up what has been described is incompetent.

Now one last thing. The general attack hinges on an attacker's agent Aa being able to make use of the unix domain socket of the administrator's agent, Da. I'm very certain that when I tried this kind of attack on myself way back in 1998 or sooner it plain wasn't possible. If it is now then the (Open, whatever)ssh code has taken a step backwards. Basically some check was done on the origin of the messages on the socket, and if they weren't as expected the request to use the keys in the agent was denied. I think it was along the lines of "is the requesting process a (sub(sub...))child of myself?", presumably by following parent process IDs back up until it finds itself or init. Yes, ok, if the agent spawned any child that spawned a service that was subsequently compromised and not put in a new session group you could probably pull off the attack, but that is unlikely (as any service daemonising itself will end up in a new session group).

Re:dont really understand the problem. (1)

makomk (752139) | more than 8 years ago | (#15415278)

Now one last thing. The general attack hinges on an attacker's agent Aa being able to make use of the unix domain socket of the administrator's agent, Da. I'm very certain that when I tried this kind of attack on myself way back in 1998 or sooner it plain wasn't possible. If it is now then the (Open, whatever)ssh code has taken a step backwards. Basically some check was done on the origin of the messages on the socket, and if they weren't as expected the request to use the keys in the agent was denied. I think it was along the lines of "is the requesting process a (sub(sub...))child of myself?", presumably by following parent process IDs back up until it finds itself or init. Yes, ok, if the agent spawned any child that spawned a service that was subsequently compromised and not put in a new session group you could probably pull off the attack, but that is unlikely (as any service daemonising itself will end up in a new session group).

If it uses SCM_CREDENTIALS passing the PID and UID down the socket, then although the kernel normally prevents you from lying about your UID/GID/PID, if you're root you can claim they're whatever you like (see unix(7)). Of course, this would require a modified version of ssh. I'm not sure about other similar methods of verifying credentials on Unix sockets, but I wouldn't be surprised if they were the same.

Re:dont really understand the problem. (2, Insightful)

ladadadada (454328) | more than 8 years ago | (#15415361)

After your description of the exploit attempt I had another, very careful read of the author's description and have come to the conclusion that we were both wrong. He is suggesting that other DMZ hosts would be compromised using the authentication credentials that should be safely behind the firewall. No internal boxes would be compromised.

From the article: (emphasis mine)
What are the chances that the administrator has configured access to all the DMZ servers he controls? Altering some environment variables allows the intruder to attempt to access other DMZ hosts with our administrator's private key. This can mean direct access as root or local administrator. And so this socket file becomes a door to many other systems in the DMZ.

The convoluted setup using the workstation and the patching server were irrelevant to the fact that there was an ssh-key connection to a compromised box which then used agent-forwarding to connect to and compromise other boxes in the DMZ.

As long as the DMZ is properly firewalled from the internal boxes it should be impossible to actively compromise them using a forwarded ssh key and hence you were completely correct in stating that your description of the attack was impossible. (I hope. If it were possible that would be... bad.

This would also mean that if the administrator had a different public-key/private-key pair for each box in the DMZ then the attacker could not agent-forward the ssh session to other boxes and would have to compromise each one manually. However, since most boxes in a DMZ are often configured identically with a load balancer in front of them, a flaw on one that allowed the inital compromise would likely be replicated to all the others and allow them to be compromised in the same way.

He also goes on to suggest that there might be a flaw in the administrator's patch loading scripts that allows execution of code on the patch-server but that is an entirely seperate issue and not concerned with ssh at all.

Re:dont really understand the problem. (1)

ladadadada (454328) | more than 8 years ago | (#15415451)

Some further thoughts on this:
Imagine a situation where three load balanced web servers with internet-facing interfaces and a database server which has no internet-facing interface. A compromise of one of the web servers would allow (with a captured user-agent) a compromise of the database server.

Obviously the statement from my last post is not entirely accurate.

This also highlights the need for an intrusion detection system on a seperate machine that is not able to be compromised (ie. does not accept connections from anywhere) and can warn you that machine x has been compromised and not to ssh to it as doing so may enable a compromise of further machines.

So... (1, Interesting)

Anonymous Coward | more than 8 years ago | (#15414805)

If I understand correctly, the author is talking about a complicated man-in-the-middle?

Isn't that why SSH displays that "Private key SO:ME:WE:IR:DL:ET:TE:RS belongs to IP 127.0.0.1" or whatever?

Re:So... (4, Informative)

Dan Ost (415913) | more than 8 years ago | (#15415427)

No, it's not really a man in the middle attack.
It's more of a credential hijacking scenario where
the attacker waits for you to authenticate with
the compromised machine, forward your credentials
to that machine, and then the attacker uses those
credentials to reach other machines that honor those
credentials.

This would be more like you signing in, walking
away from your computer, and someone else walkup up
to the computer and doing stuff as you except that
they get to act as you while you're still acting
as you.

Did that help?

Maybe I'm over-simplifying things (1)

agent dero (680753) | more than 8 years ago | (#15414807)

I'm not a security professional, but aren't they talking about man in the middle attacks? And then further down in the article, isn't he talking about generic problems with running old, unpatched software on open servers?

but honestly, is there anything a bit of courteous knocking on the right door [zeroflux.org] can't fix?

Re:Maybe I'm over-simplifying things (1)

fimbulvetr (598306) | more than 8 years ago | (#15414825)

Port knocking is security by obscurity. Sure it helps mitigate and reduce attack vectors, but it doesn't eliminate them. If you think port knocking is a solution to anything, you are sorely mistaken.

Re:Maybe I'm over-simplifying things (1)

michaelrash (715609) | more than 8 years ago | (#15415408)

True, port knocking is outdated technology for several reasons:

1) Difficult to solve the replay problem.
2) Extremely easy to bust knock sequences just by connecting to spurious ports.
3) Knocking sequences appear like a port scan to any intermediate IDS.
4) Cannot transfer a reasonable amount of data.

To name a few...

There is a better way that actually offers a real security benefit and solves all of the above problems; Single Packet Authorization (see http://www.cipherdyne.org/fwknop/ [cipherdyne.org] ). Here is a paper that describes all of the benefits of SPA over port knocking: http://www.cipherdyne.org/fwknop/docs/SPA.html [cipherdyne.org] ).

The Key is Not Transmitted (5, Insightful)

Wovel (964431) | more than 8 years ago | (#15414843)

The key is not transmitted or sent to the socket file. This person does not understand anything about private key authentication and should return all of his certifications, and please stop posting stories by them, it is embarassing.

Re:The Key is Not Transmitted (1)

ArbitraryConstant (763964) | more than 8 years ago | (#15415088)

"The key is not transmitted or sent to the socket file."

No, but it would be possible to get the person's key agent to authenticate you on one of their boxes. Of course, this shouldn't be news to anyone. From man ssh(1):
Agent forwarding should be enabled with caution. Users with the ability to bypass file permissions on the remote host (for the agent's Unix-domain socket) can access the local agent through the forwarded connection. An attacker cannot obtain key material from the agent, however they can perform operations on the keys that enable them to authenticate using the identities loaded into the agent.
I'm not sure what this 'box D' business is though. How does root on a box that they're not connected to help you get access to the socket for the key agent? A socket might be visible in the filesystem if they have root access to an NFS mount or something, but you're not going to have access to it as if it were the local machine, even if you're root. Sockets don't work that way. You need root on a box to which they're connected.

Re:The Key is Not Transmitted (3, Informative)

cortana (588495) | more than 8 years ago | (#15415342)

Perhaps the author of the article should have read the source of the text you quoted [openbsd.org] . The preceding paragraph:

ForwardAgent
Specifies whether the connection to the authentication agent (if any) will be forwarded to the remote machine. The argument must be "yes" or "no". The default is "no".

So the only people who will be caught out by this are those who:

  1. Blindly enable ForwardAgent without reading the security considerations mentioned in the manual.
  2. Set up ssh-agent without considering how it will expose their private key.

Configuring the agent to prompt the user to confirm any signing request can be as complicated as putting the private key on a smart card (which will make the reader prompt for a PIN whenever the card recieves a signing request) or it can be as simple as using the -c option when calling ssh-add; therefore this does not seem like a big deal to me.

Not a SSH problem? (3, Interesting)

andy753421 (850820) | more than 8 years ago | (#15414847)

Maybe I read the article wrong but it seems to me like a problem with someones design and not with SSH, a little like saying Unix is insecure because a unwitty sysadmin could try to make his life easier by using a blank root password.

Re:Not a SSH problem? (1)

joe 155 (937621) | more than 8 years ago | (#15415185)

one problem with SSH is that, at least on my Fedora Core laptop, it allows remote root logon by default... I don't really get why normal users would want this. it is possible to disable just by changing one of the files so that root login = no but i think it should be off by default. The article seems overly complicated so this might be totally unrelated, but i ddn't get it.

Hopefully, a better summary... (3, Informative)

perlionex (703104) | more than 8 years ago | (#15414853)

The submitter didn't summarise anything, he cut out a chunk which didn't make much sense on its own. It didn't help that the article was fairly long-winded. This is what I understand the author is trying to say:

Administrators use SSH to run scripts (from server A) to patch other servers (B, etc). These scripts are automated and make use of credentials stored in server A to gain access to the other servers (B, etc.).

If a hacker gains access to server A, he can then use the credentials to access the other servers.

As others have commented, this is kind of a "duh" moment. What's the next article?

Re:Hopefully, a better summary... (0, Troll)

grammar fascist (239789) | more than 8 years ago | (#15414889)

As others have commented, this is kind of a "duh" moment. What's the next article?

If you install and enable Apache, people can download arbitrary files from your web root directory! Also, driving cars requires gas, and plastic surgery made Paris Hilton uglier.

Shocking stuff.

Re:Hopefully, a better summary... (1)

ashridah (72567) | more than 8 years ago | (#15414948)

Let's not forget that openssh can very easily be setup to only allow a particular key to execute a particular command.

Of course, this only adds a layer of obfuscation and effort into an attacker's attack plan, but it's a fairly simple trick to vastly reduce the issues here.

ash

Re:Hopefully, a better summary... (4, Interesting)

flooey (695860) | more than 8 years ago | (#15414990)

Administrators use SSH to run scripts (from server A) to patch other servers (B, etc). These scripts are automated and make use of credentials stored in server A to gain access to the other servers (B, etc.).

If a hacker gains access to server A, he can then use the credentials to access the other servers.
Actually, it was a little more complicated. The scenario is actually that administrators use SSH to run scripts on server A to patch server A using patches from server B. The trick is, without having credentials stored on server A, a hacker who compromised server A could still trick his way into getting server B to allow him to log in if someone was logged into server A and had agent forwarding turned on.

It's not quite as straightforward of a duh moment (after all, server A on its own can't log into server B), it's basically just saying "when you log into a server and have agent forwarding turned on, you allow anyone with root access on that server to log into anywhere your agent can log into".

Re:Hopefully, a better summary... (1)

MSG (12810) | more than 8 years ago | (#15415430)

"when you log into a server and have agent forwarding turned on, you allow anyone with root access on that server to log into anywhere your agent can log into"

Right, which is why agent forwarding is disabled by default. The only point to this article may be to remind the few users who use an agent and turn forwarding on in their config files that they should use the '-A' flag, instead.

And this sort of thing doesn't matter (0)

Sycraft-fu (314770) | more than 8 years ago | (#15415032)

At least in most corperate settings. Why? Central user authentication. You have something like LDAP or AD or whatever that makes it so one login works everywhere. Right, so if someone roots a box, all they need to do is su to a user and change that user's password, which will be propagated back to the authentication server. They now have access to everything, or rather they can log in to any computer as that user.

Just kinda how it goes if you want to have easy management. The only real prevention for this kind of thing is to compartmentalize everything. Each system has different passwords and such. Ok that might work if you have like 3 systems, but if you have 500, forget about it. Best you can do is compartmentalise the real critical stuff.

That's what we do. The somewhat critical stuff is on LDAP, but has no sudo and the root password is different from the normal one and also only allows logins from computer support accounts. The really critical stuff is not on LDAP at all. Works fine, but still using the "root one box, change someone's password" trick you get access to a ton of systems. Just goes with the territory. Good incentive for us to keep our patches up and firewall clamped down.

Next article (0)

Anonymous Coward | more than 8 years ago | (#15415091)

Will concentrate on the design flaws of TCP and UDP protocols; because obviously firewall NAT piercing is a security hazard (if you assume a FW equals security) and certainly those protocols are to be blamed (for making it so easy).

Btw I think the submitted part gives the right impression; imo the article doesn't contain much (valid) information, at least not in coherent form.

Basic Stuff (5, Informative)

sodell (161952) | more than 8 years ago | (#15414860)

The article illustrated one very convoluted way to break your DMZ security, but failed to make the simple statement: don't trust anyone, not even root, on your DMZ hosts. Allow SSH logins into the DMZ, and allow the DMZ to pull files from private network patching servers, such as apt repositories, but don't allow anyone to SSH from the DMZ to the intranet. Assume the DMZ is cracked wide open and keystroke logging. No one is going to get past the DMZ by watching you type 'apt-get install squid' but they will by watching you type 'ssh root@creditcarddb.int' and then the root password.

Anyone who tunnels from the DMZ to a trusted host which can execute commands on a sensitive server can't see the forest for the trees. You've learned how to use SSH and tunnel, but you're lacking some basic common sense.

Also, I don't see what good a socket catching the authentication will do ... you can packet sniff the authentication process all day long and you won't get someone's private key.

That whole article seemed a bit of voodoo itself. Many incongruous statements, like "If the hacker has root on Box D, he or she can point a private copy of the agent forwarding software to that socket file and thereby point the authentication process to the administrator's credentials--the ones kept on the "safe" intranet."

What does that mean, exactly? You direct the authentication process to a socket file and point the process to the admin's credentials? If the socket is on the DMZ host, and the credentials are on the private network host, how can you point the authentication process to those credentials?

Maybe I'm stupid, but the article didn't seem to make a lot of sense.

Re:Basic Stuff (3, Informative)

flooey (695860) | more than 8 years ago | (#15415008)

What does that mean, exactly? You direct the authentication process to a socket file and point the process to the admin's credentials? If the socket is on the DMZ host, and the credentials are on the private network host, how can you point the authentication process to those credentials?

When the admin logs into the DMZ host with agent forwarding turned on, SSH will create a socket to interact with the agent on the admin's machine. Since the wily hacker has root on the DMZ machine, he can write to and read from that socket with no problem, and thus can ask the agent to authenticate to anywhere that the agent is willing to authenticate to (what he actually would do is just set environment variables for SSH that say "I'm using agent forwarding, my agent is located at {admin's agent forwarding socket}").

ssh is not god (1)

DrSkwid (118965) | more than 8 years ago | (#15414875)

It might be good but it's not god.

When ssh is your inter machine security model, you know something *must* be wrong.

Re:ssh is not god (1)

kestasjk (933987) | more than 8 years ago | (#15415020)

When you make a nonsense comment like "When ssh is your inter machine security model, you know something *must* be wrong.", you know something must be wrong.

Re:ssh is not god (0)

Anonymous Coward | more than 8 years ago | (#15415089)

lolroflsox!

lol (0)

Anonymous Coward | more than 8 years ago | (#15414883)

I use SSH, I use it for tunelling VNC connections to remote sites for support.

Can't remember which way round it is, it's too early to be doing any serious thinking... but I believe you need both the private and public key at each end to do two way communication i.e. initiate an outbound connection from either host.

So on the DMZ machine you remove the key used to initiate an SSH connection and just leave the key used to check the incoming connections, voila, one way communication...

At least I think that's how it works in principle, certainly works in practice as that's how I've configured and tested it, like I say, too damn early to be thinking about this...

Anyway, on my config it's forced to use key exchange, you can't just login as normal so yeh the attacker can compromise a DMZ server but he cant get back into my central server, anyway, to compromise one of the DMZ servers he would need to be able to gain access to the physical machine as for security reasons all my remote machines are locked down as well, they just route the VNC traffic at the remote site.

Could a hacker get into one of my remote SSH boxes using a first day SSH exploit, errr very doubtful, they only allow incoming SSH connections from specific IP's, controlled by netfilter, not SSH.

Do I think SSH is secure ?, damn right I do...

Clever SSH setups (1)

Cee (22717) | more than 8 years ago | (#15414893)

Basically the article states that with too clever setups of SSH, you're likely just to fool yourself. I agree in one way, since it's true that SSH allows very complex configurations. On the other way, who trusts _any_ daemon that you can talk to from any host on the internet? I certainly don't. The article doesn't really mention the one thing I worry about SSH, a security hole in the server software itself. That's why I use iptables for a first defence.

Interesting read though, made me aware of some security issues I never thought about (probably since I just use SSH for direct host-to-host communication). But really, a more hard to understand article is hard to write. Took me a couple of reads to even grasp how the attacks work.

Wow, this is one brave man! (-1, Offtopic)

ArsenneLupin (766289) | more than 8 years ago | (#15414910)

Wow! Just wow! [cnn.com]

If this fella uttered similar statements in the US about the prez, I'm sure the Secret Service would come knocking within the next 5 minutes!

Re:Wow, this is one brave man! (0)

Anonymous Coward | more than 8 years ago | (#15415244)


If this fella uttered similar statements in the US about the prez, I'm sure the Secret Service would come knocking within the next 5 minutes!

thats the difference between real free speech and the pseudo attempt in the US

Re:Wow, this is one brave man! (0)

Anonymous Coward | more than 8 years ago | (#15415739)

This is the sort of thing George Galloway says, although I sort of agree with him. (Is that a tank I see driving towards my house?)

AgentForwarding AS AN OPTIONAL FEATURE (3, Informative)

meridian (16189) | more than 8 years ago | (#15414945)

YES Thats correct you can use AgentForwarding.... If you are stupid enough to use agent forwarding to a host you don't trust or you would consider insecure ITS YOUR OWN STUPID FAULT IF YOU GET HACKED. Now for the evil h4x0rz to use agent forwarding on the host you connect to to hack the machine you are coming in from requires quite a number of things to be done on your stupid behalf that sure wouldnt be enabled by default and you would almost need to set them up purposefully. The only real danger with agent forwarding to an insucure host is that evil h4x0rz on that host can use your forwarded authentication agent to connect to boxes that are set up to both allow connections using that ssh-key AND allow tcp connections from any box that the evil h4x0rz have access to. Aside from that it is only as insecure as establishing a telnet session to the box and having some buffer overflow occur back to the client due to poor code on the client side. I am sure not about to stop using ssh for some "simpler" protocol like telnet but I will sure keep disabling AgentForwarding and any kind of portforwarding the hosts I dont trust and I ASSUME EVERYONE ELSE WILL CONTINUE TO DO THAT AS WELL. Otherwise you might as well start posting your root passwords to slashdot which may or may not matter if you have locked your systems down correctly in the first place.

Re:AgentForwarding AS AN OPTIONAL FEATURE (4, Informative)

meridian (16189) | more than 8 years ago | (#15414964)

Actually...
Rather than assume anyone^H^H^H^H^H^Heveryone on slashdot has any brains when it comes to Securing SSH let me give you some tips I/Other people have

Restricted ssh shell for scp/sftp http://sublimation.org/scponly/ [sublimation.org]
Patch to lock out IPs brute forcing passwords http://ethernet.org/~brian/src/timelox/ [ethernet.org]

Can add restrictions to authorized_keys file
from="hostipaddress",command="/usr/local/sbin/ssh_ command_allow_rsync",no-port-forwarding,no-X11-for warding,no-agent-forwarding,no-pty ssh-rsa AA...= backup_key

Securing sshd in /etc/ssh/sshd_config
        Protocol 2
        PermitRootLogin without-password
        PasswordAuthentication no
        ChallengeResponseAuthentication no
        ClientAliveInterval 60
        ClientAliveCountMax 30

The first line says to stop using the old, lower security ssh protocol-1.

The second line is a hedge that says never allow root logins using the unix password -- always use some other authentication.

The third line says don't allow skey authentication. It is a good idea to turn this off if you aren't using skey at this time. (Skey implements a series of non-reusable, one-time passwords. If you were using it you would know.)

The fourth and fifth lines simply make sure that any connection to a client that doesn't respond at least once each half hour gets closed. After editing the sshd file, restart sshd or reboot for the changes to take effect.

31-12-2004: new rate-limiting feature in -current. This would block hosts that exceed 10 connections per 60 seconds.
    pass in on $ext_if proto tcp to $ext_if port ssh flags S/SA \
                keep state (max-src-conn-rate 10/60, overload )
    block in on $ext_if proto tcp from to $ext_if port ssh

Also my previous post to do with limiting user connections to SSH during the scarey SSH port scanning days of not so long ago...
http://it.slashdot.org/comments.pl?sid=156058&cid= 13084357 [slashdot.org]

Repeated here for your convenience:
Ways around SSH Brute forcing (Score:1)
by meridian (16189) on 11:06 AM July 17th, 2005 (#13084357)
(http://www.thief.net/)
There are esentially three ways to fix this problem.
The first is to patch sshd which is probably the least preferable way as you would need to continually keep patching with each upgrade. But this seems effective allowing you to exec a system command such as iptables.
http://ethernet.org/~brian/src/timelox/ [ethernet.org] [ethernet.org]

The second is to use iptables to limit connection attempts from an IP address. One problem with this is people who use scp alot may quickly rack up that connection limit.
Here is a recent example from the iptables mailing list
iptables -A INPUT -p tcp --dport 22 -s ! $My_Home_Firewall_IP -m state --state NEW -m recent --name SSH --set --rsource -j SSH_BF
iptables -A SSH_BF -m recent ! --rcheck --seconds 60 --hitcount 3 --name SSH --rsource -j RETURN
iptables -A SSH_BF -j LOG --log-prefix "SSH Brute Force Attempt: "
iptables -A SSH_BF -p tcp -j DROP

The best in my opinion is a pam module found at http://www.kernel.org/pub/linux/libs/pam/modules.h [kernel.org] tml [kernel.org] called pam_abl
This does not have the problem of the IPTables method that may mistake multiple fast scps etc as an attack attempt, and will not require coninutal repatching of the kernel such as the timelox patches.

brute force password attack (1)

Monx (742514) | more than 8 years ago | (#15415622)

I block brute force password attacks on my home system by having a process monitor the sshd logs so that if a host fails to authenticate five times, its IP is added to my firewall's deny list. The attacker then gets to see his future connections time out. I do this rather than reject the connection outright to slow the attacker down. It's fun to think of the attacking system hanging on a partially open socket until it times out. Simply rejecting the connection would be too kind.

Could this setup be used for a joejob? Yeah, particularly since two hosts behind the same NAT system look the same to me. The risk is low though and doesn't matter since I have physical access to the box and nobody else does.

There is a reason.... (5, Informative)

Anonymous Coward | more than 8 years ago | (#15414982)

Why the developers of ssh have an option to forbid agent forwarding. Isn't it off by default? I cite from "man ssh":

>>>
                          Agent forwarding should be enabled with caution. Users with the
                          ability to bypass file permissions on the remote host (for the
                          agent's Unix-domain socket) can access the local agent through
                          the forwarded connection. An attacker cannot obtain key material
                          from the agent, however they can perform operations on the keys
                          that enable them to authenticate using the identities loaded into
                          the agent.

So wha is slashdot running an article about something where there is an explicit one-paragraph long waring in the man page of program at the option in question.

Yes, no doutbt there are a lot of idiots around, who without understanding,do things which require semantics which leads to a security leak (there is abolutely no way if you want to initiate authenticatication from processes on a machine to avoid root to do the same - as log as you are not asked on the agent's side each time before authentication;

Re:There is a reason.... (1, Interesting)

Anonymous Coward | more than 8 years ago | (#15415243)

Agree 100%. To anyone who has read the SSH documentation, this is old news. However, judging from the number of posters in this thread who seem confused about the nature of the attack, I guess that most people either (a) don't read manuals, or (b) never considered how 'ssh-agent' performs its magic. Now. at least, they know.

Re:There is a reason.... (1)

Antique Geekmeister (740220) | more than 8 years ago | (#15415454)

Oh, it's worse. It's like Simson Garfinkel's "UNIX Security" book: he waves his hands at some complex vulnerability without making it clear, and ignores the real risks. For SSH, the real risk is idiots who refuse to use ssh-agent and keep copies of their private key, unencrypted, on insecure machines. Worse, people keep unencrypted private keys on poorly managed NFS shares so that any shmuck who plugs into a local network with a laptop can look in "/home" and get all the SSH keys.

Even more fun, many sites running NIS or gateway servers still fail to enable "shadow passwords", which means that any random user can look at the encrypted password list and run Alec Moffett's old "crack" program against them, and get roughly one-in-ten of all passwords decrypted. (Yes, MD5 passwords help, but a lot of people still don't use that.)

Re:RTFM (1)

rdebath (884132) | more than 8 years ago | (#15415681)

Love it

Oy! Slashdot you need to RTFM!

This has nothing to do with ssh per se (0)

Anonymous Coward | more than 8 years ago | (#15414986)

This has everything to do with using tunnels to circumvent network security zones. In this case, if the box you are tunneling through is compromised, this can easily lead to the unauthorized access of the box you are tunneling to.

Re:This has nothing to do with ssh per se (1)

Athanasius (306480) | more than 8 years ago | (#15415198)

Indeed, or even more precisely, the entire thing is about incompetent systems administrators.

If your DMZ box needs access to patches then sort out the patch server *pushing* them out. Or at the very least grab them on your workstation from the patch server, then push them to the DMZ host from there. Under no circumstances do this double-tunnelling tricks to allow the DMZ host *any* direct access to the internal patch server, even if it's to a single port, for a single daemon, that you think is coded correctly and thus secure.

Never understood why they invented the SSH-AGENT (2, Insightful)

wtarreau (324106) | more than 8 years ago | (#15414989)

Personnaly, I never understood how talented SSH developers came to the conclusion that they needed to invent such a crappy thing : ssh-agent. And I've seen people use it, the same people who put their private keys on USB sticks to ensure that nobody will steal them, but who are not afraid of collegues having root access on their machine ...

ssh-agent is a solution to grant any process on the system full access to a means of authenticating through your private key. No comment ! There's nothing difficult in typing
a passphrase each time you connect to a remote site !

--
willy
high performance free load balancing solution - http://w.ods.org/haproxy/ [ods.org]

Re:Never understood why they invented the SSH-AGEN (1)

Onan (25162) | more than 8 years ago | (#15415013)

ssh-agent is a solution to grant any process on the system full access to a means of authenticating through your private key.
Any process on the system running as you or as root, you mean.

Re:Never understood why they invented the SSH-AGEN (1)

yukonbob (410399) | more than 8 years ago | (#15415069)

mod parent up...

grand parent either hasn't had multiple terminals open to a half dozen (or more) remote clients, or is completely fine with typing a secure passphrase every single time (s)he wants a terminal... if any host is rooted, nothing's guaranteed after that... perhaps a binary has been been swapped out, or if you're running X11 forwarding, you're putting your own X server at risk, but I don't see what that's got to do with ssh... just don't put more faith in it than it deserves... running ssh isn't a cure for pop-ups, viruses, trojans, or erectile disfunction...

-yb

Re:Never understood why they invented the SSH-AGEN (0)

Anonymous Coward | more than 8 years ago | (#15415076)

ssh-agent is a solution to grant any process on the system full access to a means of authenticating through
your private key. No comment !


That's (a) true, but (b) not what the article is about. You are on box A, running ssh-agent. You ssh to box B. If someone on box *B* has root, they could theoretically use the socket file on box B to then ssh to any other boxes C,D,E... on which you have enabled key authentication, but only while you are still ssh'd in from A to B. There's a warning about it in the ssh man page.

There's nothing difficult in typing a passphrase each time you connect to a remote site !


If you have to do automated stuff, using the agent is still better than keeping a private key on box B, especially if you need a degree of automation that would entail having a null passphrase on that key.

Re:Never understood why they invented the SSH-AGEN (1)

netjae (977406) | more than 8 years ago | (#15415178)

ssh-agent is inevitable.
Suppose you frequently use a program that communicates over ssh connections, e.g. cvs, rsync, svn, or darcs. You wouldn't want to type your key's passpharse each time you run the program. Of course you never want to leave your key's passphrase null. Therefore, you need ssh-agent.

Because it's useful? (1, Informative)

Anonymous Coward | more than 8 years ago | (#15415213)

ssh-agent is a godsend. My passphrase is > 50 characters in length - yours should be, too - and I don't want to type it more than once per login session. If you often use SSH, and have RTFM, you will be able to use ssh-agent properly, and it will save you a lot of time.

ssh-agent is a solution to grant any process on the system full access to a means of authenticating through your private key.

Any process? Presumably this is only if you have deliberately made the socket files world-readable?

The alternatives to ssh-agent are password authentication and host-based authentication. I'm sure I don't need to remind you about the security issues with those!

Re:Never understood why they invented the SSH-AGEN (1)

irtza (893217) | more than 8 years ago | (#15415345)

something like a use-agent is useful for clustering. Programs restricted to user X on the DMZ machine can use the user-agent to launch programs on other machines in their network. Does this undermine the security of the local network? Sure. Does this mean its unnecessary? No. The question really is whether you are willing to let the other machines be compromised. If a machine on the internal network needs special protection (ie it holds customer credit card info) then it most likely doesn't need to be part of the cluster and can be set apart.

Are there alternatives to user-agent for building distributed software? Of course, but they also add a huge security hole for the same reason.

At the end of the day, you could prob just consider the cluster one machine and assume all to be compromised along w/ the DMZ... I just wanted to defend the existence of agents in ssh.

Re:Never understood why they invented the SSH-AGEN (1)

maxume (22995) | more than 8 years ago | (#15415461)

I doubt they came to the conclusion to invent ssh-agent. I imagine they released it to prevent other even more broken systems from being used. By providing a tool that is as good as it can be, no one creates an even crappier version of the same thing, i.e. one that stores the unencrypted key to disk or something.

Solution available (0)

Anonymous Coward | more than 8 years ago | (#15414997)

Wow, we're lucky that there's already a fix for this attack. It's called Rockwell Automation's Retro Encabulator.
watch the google video [google.com]

Wrong (0)

Anonymous Coward | more than 8 years ago | (#15415016)

In UNIX, all things are files


No, in UNIX, most things are files. In Plan9, all things are files.

And I feel safe here since I don't use unix, I use GNU, and GNU is NOT UNIX!

mind the ends... (1)

yukonbob (410399) | more than 8 years ago | (#15415045)

/me thinks this article is saying "the tunnel may be encrypted, but mind the ends"...

which isn't news to anybody who's in the know about security or ssh... ssh isn't going to butter your bread, or do anything outside of securing end-to-end transmissions... I can't see anything new being introduced here...

wtf (0)

Anonymous Coward | more than 8 years ago | (#15415074)

In UNIX, all things are files. To send network traffic, UNIX writes the traffic to the network device file.

That's plain wrong to begin with. I stopped reading there.

another article from... (1)

Octavian59 (168771) | more than 8 years ago | (#15415114)

Zooooooooonk!

Trust: same problem as always (1)

ishmalius (153450) | more than 8 years ago | (#15415146)

In the end, you must trust the entity on the other end of the wire. This is true whether you are talking about Unix sockets, telegraphy, semaphore, or the one-time pads rolled up in Che Guevara's cigar box.

The idea of looking at the memory on the ass-end of an SSH connection is stupid. It's one of the ends, where the other trusted party lives. For all you know, your buddy prints your secrets onto nice vellum paper and gives it to the enemy. No electronics can save you if you can't trust the other guy.

They haven't heard of ssh-add -c? (5, Informative)

biftek (145375) | more than 8 years ago | (#15415399)

A few versions ago OpenSSH added a -c "Require confirmation to sign using identities" to ssh-add to take care of this. Or using something like SSHKeychain on OS X so it'll ask for confirmation for multi-hop auth, but not for connections direct from your trusted machine.

Bullet proof is hard to come by (2, Insightful)

HangingChad (677530) | more than 8 years ago | (#15415406)

Short of unplugging the machine and locking it in a vault. SSH may not be perfect but it's pretty darn good. And if getting your credentials depends on someone else have administrator rights on one of your nodes, that's not exactly a fatal flaw unless your security demands are extremely high.

Anyone with the time and resources is going to find a way into your network. Many times security does not have to be bullet proof. Don't have to be faster than the bear, just faster than the large majority of other networks. Unless there's something really compelling on your system, they're likely to pick an easier target.

I use my home network as an example. I have one copy of XP on my system. What I consider the weak link in the security chain. It's on a NAT'd segment, I don't surf the internet with it and anything sensitive is on a TrueCrypt partition that I only mount when needed. Hardly bullet proof but not bad for Windows.

2004 article mentions this (3, Informative)

TomAnthony (927466) | more than 8 years ago | (#15415418)

I've never needed to use ssh-agent, and during reading this I thought I'd read up on it a bit. So I google it and found an article [securityfocus.com] , written in 2004, that had this to say:
So the bad news is that your agent keys are usable by the root user. The good news, however, is that they are only usable while the agent is running -- root could use your agent to authenticate to your accounts on other systems, but it doesn't provide direct access to the keys themselves. This means that the keys can't be taken off the machine and used from other locations indefinitely.

Is there any way to keep root from using your agent, even though it can subvert unix file permissions? Yes, you can. If you supply the -c option when you import your keys into the agent, then the agent will not allow them to be used without confirmation. When someone attempts to use your agent to authenticate to a server, the ssh-agent will run the ssh-askpass program. This program will pop up on your X11 desktop and ask for confirmation before proceding to use the key.

At this point you're probably going to realize that we're still fighting a losing battle. The local root account can access your X11 desktop, all your processes, you name it. If you can't trust the root user, you're in trouble.

However this will prevent root on machines to which you've forwarded the agent from accessing your agent.

Summary to the Summary (3, Informative)

Zygamorph (917923) | more than 8 years ago | (#15415556)

Don't use SSH to poke a hole in the firewall separating your DMZ from the intranet.

Any *good* sysadmin should know this (1)

Cicero382 (913621) | more than 8 years ago | (#15415577)

It's hardly news.

Just to state my position:

1. I am a UNIX sysadmin.* I'm paranoid. My worst fear is "Am I paranoid enough?"
2. The only really secure system is one that's been turned off, buried in concrete 100 meters deep, surrounded by 1,000 armed guards... and a minefield. Even then, I wouldn't be sure.

Anyone who believes in some magical security of some software deserves everything they get. Get real! Security (even for *NIX systems) is a dynamic thing. If you're tasked with securing a M$ system - you have my sympathies, but at least you know that one.

* - OK - for those who know me, yeah, yeah - I'm really a biochemist.

Sigh... (-1, Offtopic)

Evro (18923) | more than 8 years ago | (#15415679)

I guess I should start blocking Zonk again...

Home/Office network compromisation in 4 steps (1)

griffjon (14945) | more than 8 years ago | (#15415731)

1: Enable an SSH tunnel
2: L33t Hax0r finds tunnel
3: L33t Hax0r GETS ROOT
4: Profit.

Both steps 2 and 3 in this reductive version seem pretty dubious. If you tunnel in to work, then sure, you're trusting the work network and machine not to be full of malevolent people, but even still, they have to get root on your box. You didn't tunnel in from root, now, did you?

lost a patch server before? (1)

RenoRelife (884299) | more than 8 years ago | (#15415756)

So the DMZ box gets patches and can kick off commands against the patching server itself. The patching server for the entire company. The one safe source for binaries for all servers and client PCs. That one.
Almost sounds as if he's speaking from past experience
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>