-15

I have an applet which is available on the Internet which talks to an internal server via an SSH tunnel. The correct SSH credentials have to be available to the applet. It isn't very convenient to compile them into the applet; providing them as applet parameters in the HTML leaks them to the Internet; and having the applet download them from the applet host server ditto but less obviously. My question is, is there another way I haven't thought of whereby only the applet can get hold of the SSH credentials? I can probably get the applet to use the same session ID as the browser, in which case I can at least restrict it to authenticated users ... But I'd really like a more secure solution with no leaks.

Server stack has Tomcat, JSF, and Facelets. Apache server and FTP are also available.

EDIT: I should clarify that the internal service I am tunneling to is itself pretty safe apart from DoS, it's more the security of the inner host that I'm concerned with, and also not becoming a public tunnel to anywhere. The SSH PermitOpen config element is a lot of help there.

user207421
  • 305,947
  • 44
  • 307
  • 483

5 Answers5

5

If the client's machine has to log in to your server, then the client will be able to figure out what credentials it's using. There's no way to get around that; if someone wants to, they can just sniff their own machine's internet traffic and find it that way.

If you absolutely must use this ssh tunnel logging in from the client end, I'd recommend using public key authentication and generating a key on the host, then passing the public half to the server via an API that temporarily adds access for that key.

Amber
  • 507,862
  • 82
  • 626
  • 550
1

Not possible. There is no way to distinguish between a Java applet running on the user's computer and a tool crafted by the user running on that same computer -- their HTTP requests and SSH traffic will "smell the same", from your perspective. Your best bet is to figure out some way to expose the necessary ports on your internal server through your firewall, rather than allowing the user to punch the necessary holes themselves.

  • Thanks but that would be just as bad, actually worse. It's what's inside that I need to protect, not just the tunnel to it. – user207421 Aug 27 '11 at 01:43
  • If that's the case, then you're doubly sunk -- you're trying to expose a service to users (e.g, the Internet as a whole) that you don't trust enough to give access to. What is this service? You'll probably need to proxy access to it in some way or another; what'll be appropriate will depend on what it is. –  Aug 27 '11 at 03:17
  • It's more that I don't want to expose other things that the tunnel could reach. The service itself is pretty safe other than to DoS but I don't want to open up the entire inner host, and of course I don't want the SSH itself used as an arbitrary tunnel to anywhere. I can probably control most of that satisfactorily via the PermitOpen configuration element of SSH. Just looking for better security basically but I take the point that my client and an attacker aren't really distinguishable. – user207421 Aug 27 '11 at 07:15
  • Right, that's why I'm recommending that you punch a hole just for the service (e.g, host/port) that you need to, not just cut the firewall wide open, or that you set up some sort of proxy to effectively act as a tunnel just for this one service. –  Aug 27 '11 at 08:47
  • Well I'm using SSH rather than just punching the firewall wide open so as to get some security, right? I'm looking for *more* security, not less. I can set up *SSH* to be the proxy for this one service. I'd just like to nail it down a little more. Your suggestions are going in the wrong direction. – user207421 Aug 27 '11 at 09:56
0

You want to publish an applet which has the permission to connect to a SSH server. But you do not want to publish the credentials. This makes no sense, because having the permission to connect to a SSH server and having the credentials to connect to a SSH server is equivalent. There is nothing more you can do with the credentials but connecting to the SSH server. And this is the permission the applet should have.

ceving
  • 21,900
  • 13
  • 104
  • 178
0

There's a problem with defining goals here.

There are two possible cases: 1) you need to execute some batch (sequence of commands) on the SSH server without the user knowing this 2) you need to let the user interact with the server in a limited manner.

In first case you can send a batch to your HTTP server and let the HTTP server connect to SSH server.

In second case you are providing SSH access to the user via your applet, and this is no different from providing the user access via his favorite SSH client. So you would need to provide each user different SSH credentials (and pass them to the applet) and that's all - it would be user's job to guard credentials, while you can add some security measures such as restricting IP access.

Finally I should note that custom SSH server with limited capabilities would possibly be a solution as well.

Eugene Mayevski 'Callback
  • 45,135
  • 8
  • 71
  • 121
-1

I'm thinking that your best course is to create some sort of a proxy outside your firewall, with a simple unencrypted TCP connection, then establish a connection from the secured server to the applet, via the proxy, with the SSH connection tunneled through the open connection.

parsifal
  • 1,507
  • 8
  • 7
  • 1
    How does that answer the question? or add any security? – user207421 Aug 27 '11 at 13:48
  • Because it shifts the secret key back to the server, which is the only place that you can control it. You'll still need per-connection user-initiated authentication, but there's absolutely no way around that. – parsifal Aug 27 '11 at 15:35
  • 1
    So it just adds *another* layer of authentication? With another credentials problem? – user207421 Aug 27 '11 at 22:01
  • Perhaps I'm misunderstanding your concern. As I read your question, the issue is how to avoid putting credentials on the untrusted side of the connection. If that is not your concern, then my answer of course does not apply. – parsifal Aug 28 '11 at 13:56
  • But if client-side credentials are your concern, and you don't want to initiate a connection from server to client, then your options are limited. You could use password-based authentication, which would avoid storing anything on the client, but then your users would need an account on the server. Or you could use a one-time private key, but then you'd have the problem of maintaining (and expiring) authorized keys on the server. – parsifal Aug 28 '11 at 13:59
  • None of this answers the question. Client-side credentials *are* my concern: that's what the question is about. Your first suggestion either turns a partially secured SSH port into a completely unsecured TCP port, or else it just creates another credentials distribution problem like the one I am trying to solve. It's an applet so a connection from server to client is unlikely to be feasible. Your suggestion about password authentication also misses the point: I still have to distribute the credentials (the password) and I still have to do so securely. Again this is what the question is about. – user207421 Aug 29 '11 at 09:02
  • OK, so I did *not* misunderstand your question. You're looking for a magical way to keep credentials secure in an unsecured environment. Good luck with that. And once you get it through your head that it won't work, perhaps you'll actually think about some of the suggestions that I gave. – parsifal Aug 29 '11 at 10:55
  • I know there's a problem, hence the question. I have already stated what is wrong with each of your suggestions in turn. None of them improves the situation in the slightest: they all either reiterate the original problem or make it worse. – user207421 Aug 30 '11 at 10:35