如果您绝对必须使用此 ssh 隧道从客户端登录,我建议使用公钥身份验证并在主机上生成密钥,然后通过临时添加对该密钥的访问权限的 API 将公共部分传递到服务器。
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.
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.
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.
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.
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.
发布评论
评论(5)
如果客户端的计算机必须登录到您的服务器,那么客户端将能够找出它正在使用的凭据。没有办法解决这个问题;如果有人愿意,他们可以嗅探自己机器的互联网流量并以这种方式找到它。
如果您绝对必须使用此 ssh 隧道从客户端登录,我建议使用公钥身份验证并在主机上生成密钥,然后通过临时添加对该密钥的访问权限的 API 将公共部分传递到服务器。
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.
不可能。无法区分在用户计算机上运行的 Java 小程序和在同一台计算机上运行的用户制作的工具——从您的角度来看,它们的 HTTP 请求和 SSH 流量将“闻起来相同”。最好的选择是找出某种方法通过防火墙公开内部服务器上的必要端口,而不是允许用户自己打出必要的漏洞。
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.
这里定义目标有一个问题。
有两种可能的情况:
1)您需要在 SSH 服务器上执行一些批处理(命令序列),而用户不知道这一点
2)你需要让用户以有限的方式与服务器交互。
在第一种情况下,您可以将批处理发送到 HTTP 服务器,并让 HTTP 服务器连接到 SSH 服务器。
在第二种情况下,您通过小程序向用户提供 SSH 访问权限,这与通过用户最喜欢的 SSH 客户端提供用户访问权限没有什么不同。因此,您需要为每个用户提供不同的 SSH 凭据(并将它们传递给小程序),仅此而已 - 保护凭据将是用户的工作,同时您可以添加一些安全措施,例如限制 IP 访问。
最后我应该指出,功能有限的自定义 SSH 服务器也可能是一个解决方案。
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.
您想要发布一个有权连接 SSH 服务器的小程序。但您不想发布凭据。这是没有意义的,因为拥有连接到 SSH 服务器的权限和拥有连接到 SSH 服务器的凭据是等效的。除了连接到 SSH 服务器之外,您无法对凭据执行任何其他操作。而这就是小程序应该拥有的权限。
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.
我认为最好的做法是在防火墙外创建某种代理,使用简单的未加密的 TCP 连接,然后通过代理建立从安全服务器到小程序的连接,通过开放连接建立隧道的 SSH 连接。
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.