Mixing
Is ssh with public key authentication, no passwords secure enough?
I have a web server set up and would like to connect to it from outside using Tor.
The web server simply serves up a simple webpage that will act as an interface for a program running on the machine.
It is not meant to be accessible by anyone else.
If I set up another computer with SSH and set to log in using SSH keys to act as an SSH tunnel, is this secure enough from most attackers?
With the SSH tunnel and Tor in place, is there a reason to use SSL or is all this secure enough?
What attacks are still possible and how do I defend against them?
ssh
edited Jan 6 at 3:23
Brian McCutchon
1053
asked Jan 4 at 8:58
user942937user942937
143110
|
show 1 more comment
I have a web server set up and would like to connect to it from outside using Tor.
The web server simply serves up a simple webpage that will act as an interface for a program running on the machine.
It is not meant to be accessible by anyone else.
If I set up another computer with SSH and set to log in using SSH keys to act as an SSH tunnel, is this secure enough from most attackers?
With the SSH tunnel and Tor in place, is there a reason to use SSL or is all this secure enough?
What attacks are still possible and how do I defend against them?
ssh
edited Jan 6 at 3:23
Brian McCutchon
1053
asked Jan 4 at 8:58
user942937user942937
143110
9
To verify, you mean "ssh using key-based authentication" (or some such), and NOT "ssh without a password", right? If so, it would be worth editing the title to match. I won't do so without having verified your intent, though (since to me, that subtle wording change carries a significant difference in intent and risk).
– Ethan Kaminski
Jan 4 at 12:31
3
Actually, scratch that, I didn't quite read far enough (read it too quickly). Further question, for clarification: you've got an externally-accessible webpage, right? Or are you making the HTTP request on localhost (and/or another LAN address)? That's also going to be a relevant detail, moreso than the SSH itself.
– Ethan Kaminski
Jan 4 at 12:34
Yup. Two machines: one with the externally-accessible webpage and another used for ssh-tunneling. Unless there's a way to have them both on just one machine.
– user942937
Jan 4 at 12:38
That would be FAR safer to set up that way, yes. Let me type up an answer about that, since the current answer only seems to cover the SSH/Tor side of things, without detailing the risks of having an admin-y panel served by a webserver open to the whole internet.
– Ethan Kaminski
Jan 4 at 12:42
If that automated login is only for port forwarding you can use a user which does not allow shell access. While key based authentication is very strong the key on the client side is the weakness, so limiting reach can additionally mitigate risks.
– eckes
Jan 4 at 15:34
|
show 1 more comment
I have a web server set up and would like to connect to it from outside using Tor.
The web server simply serves up a simple webpage that will act as an interface for a program running on the machine.
It is not meant to be accessible by anyone else.
If I set up another computer with SSH and set to log in using SSH keys to act as an SSH tunnel, is this secure enough from most attackers?
With the SSH tunnel and Tor in place, is there a reason to use SSL or is all this secure enough?
What attacks are still possible and how do I defend against them?
ssh
edited Jan 6 at 3:23
Brian McCutchon
1053
asked Jan 4 at 8:58
user942937user942937
143110
I have a web server set up and would like to connect to it from outside using Tor.
The web server simply serves up a simple webpage that will act as an interface for a program running on the machine.
It is not meant to be accessible by anyone else.
If I set up another computer with SSH and set to log in using SSH keys to act as an SSH tunnel, is this secure enough from most attackers?
With the SSH tunnel and Tor in place, is there a reason to use SSL or is all this secure enough?
What attacks are still possible and how do I defend against them?
ssh
ssh
edited Jan 6 at 3:23
Brian McCutchon
1053
asked Jan 4 at 8:58
user942937user942937
143110
edited Jan 6 at 3:23
Brian McCutchon
1053
asked Jan 4 at 8:58
user942937user942937
143110
edited Jan 6 at 3:23
Brian McCutchon
1053
edited Jan 6 at 3:23
Brian McCutchon
1053
edited Jan 6 at 3:23
Brian McCutchon
1053
1053
asked Jan 4 at 8:58
user942937user942937
143110
asked Jan 4 at 8:58
user942937user942937
143110
asked Jan 4 at 8:58
user942937user942937
143110
143110
9
To verify, you mean "ssh using key-based authentication" (or some such), and NOT "ssh without a password", right? If so, it would be worth editing the title to match. I won't do so without having verified your intent, though (since to me, that subtle wording change carries a significant difference in intent and risk).
– Ethan Kaminski
Jan 4 at 12:31
3
Actually, scratch that, I didn't quite read far enough (read it too quickly). Further question, for clarification: you've got an externally-accessible webpage, right? Or are you making the HTTP request on localhost (and/or another LAN address)? That's also going to be a relevant detail, moreso than the SSH itself.
– Ethan Kaminski
Jan 4 at 12:34
Yup. Two machines: one with the externally-accessible webpage and another used for ssh-tunneling. Unless there's a way to have them both on just one machine.
– user942937
Jan 4 at 12:38
That would be FAR safer to set up that way, yes. Let me type up an answer about that, since the current answer only seems to cover the SSH/Tor side of things, without detailing the risks of having an admin-y panel served by a webserver open to the whole internet.
– Ethan Kaminski
Jan 4 at 12:42
If that automated login is only for port forwarding you can use a user which does not allow shell access. While key based authentication is very strong the key on the client side is the weakness, so limiting reach can additionally mitigate risks.
– eckes
Jan 4 at 15:34
|
show 1 more comment
9
To verify, you mean "ssh using key-based authentication" (or some such), and NOT "ssh without a password", right? If so, it would be worth editing the title to match. I won't do so without having verified your intent, though (since to me, that subtle wording change carries a significant difference in intent and risk).
– Ethan Kaminski
Jan 4 at 12:31
3
Actually, scratch that, I didn't quite read far enough (read it too quickly). Further question, for clarification: you've got an externally-accessible webpage, right? Or are you making the HTTP request on localhost (and/or another LAN address)? That's also going to be a relevant detail, moreso than the SSH itself.
– Ethan Kaminski
Jan 4 at 12:34
Yup. Two machines: one with the externally-accessible webpage and another used for ssh-tunneling. Unless there's a way to have them both on just one machine.
– user942937
Jan 4 at 12:38
That would be FAR safer to set up that way, yes. Let me type up an answer about that, since the current answer only seems to cover the SSH/Tor side of things, without detailing the risks of having an admin-y panel served by a webserver open to the whole internet.
– Ethan Kaminski
Jan 4 at 12:42
If that automated login is only for port forwarding you can use a user which does not allow shell access. While key based authentication is very strong the key on the client side is the weakness, so limiting reach can additionally mitigate risks.
– eckes
Jan 4 at 15:34
9
9
To verify, you mean "ssh using key-based authentication" (or some such), and NOT "ssh without a password", right? If so, it would be worth editing the title to match. I won't do so without having verified your intent, though (since to me, that subtle wording change carries a significant difference in intent and risk).
– Ethan Kaminski
Jan 4 at 12:31
To verify, you mean "ssh using key-based authentication" (or some such), and NOT "ssh without a password", right? If so, it would be worth editing the title to match. I won't do so without having verified your intent, though (since to me, that subtle wording change carries a significant difference in intent and risk).
– Ethan Kaminski
Jan 4 at 12:31
3
3
Actually, scratch that, I didn't quite read far enough (read it too quickly). Further question, for clarification: you've got an externally-accessible webpage, right? Or are you making the HTTP request on localhost (and/or another LAN address)? That's also going to be a relevant detail, moreso than the SSH itself.
– Ethan Kaminski
Jan 4 at 12:34
Actually, scratch that, I didn't quite read far enough (read it too quickly). Further question, for clarification: you've got an externally-accessible webpage, right? Or are you making the HTTP request on localhost (and/or another LAN address)? That's also going to be a relevant detail, moreso than the SSH itself.
– Ethan Kaminski
Jan 4 at 12:34
Yup. Two machines: one with the externally-accessible webpage and another used for ssh-tunneling. Unless there's a way to have them both on just one machine.
– user942937
Jan 4 at 12:38
Yup. Two machines: one with the externally-accessible webpage and another used for ssh-tunneling. Unless there's a way to have them both on just one machine.
– user942937
Jan 4 at 12:38
That would be FAR safer to set up that way, yes. Let me type up an answer about that, since the current answer only seems to cover the SSH/Tor side of things, without detailing the risks of having an admin-y panel served by a webserver open to the whole internet.
– Ethan Kaminski
Jan 4 at 12:42
That would be FAR safer to set up that way, yes. Let me type up an answer about that, since the current answer only seems to cover the SSH/Tor side of things, without detailing the risks of having an admin-y panel served by a webserver open to the whole internet.
– Ethan Kaminski
Jan 4 at 12:42
If that automated login is only for port forwarding you can use a user which does not allow shell access. While key based authentication is very strong the key on the client side is the weakness, so limiting reach can additionally mitigate risks.
– eckes
Jan 4 at 15:34
If that automated login is only for port forwarding you can use a user which does not allow shell access. While key based authentication is very strong the key on the client side is the weakness, so limiting reach can additionally mitigate risks.
– eckes
Jan 4 at 15:34
|
show 1 more comment
3 Answers
3
active
oldest
votes
If you are using public key authentication for SSH, no one can log in to the server without having the corresponding private key. This is as secure, and usually more secure, than password authentication. The encryption OpenSSH provides is state of the art; there is no known way to break it. You can further improve security on the Tor side by using authorized hidden services. This will make the domain inaccessible to all but your client. Note that this only works with v2 hidden services, not the latest v3.
The only remaining attack would be a man-in-the-middle attack. You can copy over the host key from the server to your client, just like you copied a key to make public key authentication possible. This will completely mitigate man-in-the-middle attacks and the client will warn you if an attempt is detected.
See also What is the difference between authorized_keys and known_hosts file for SSH?
answered Jan 4 at 10:41
forestforest
34.3k16113118
Hi. Thanks for answering. I'm not sure if this is unrelated, but if I'm on DHCP, how can I find out my IP address to have the machine accessible through tor? Or is static IP the (only) way to go?
– user942937
Jan 4 at 11:35
@user942937 If you always are going to use tor to connect to it, setup a tor hidden service on the machine, this way it gets an union domain name you can use to connect to it from the outside (without requiring static ip's or port forwarding), and since the name always stays the same, you are protected in the way the answer describes when comparing the host keys)
– Ferrybig
Jan 4 at 13:39
5
It may be worth pointing out that if using public key authentication one should not forget to disable password authentication completely in order to reduce the attack surface.
– zakinster
Jan 4 at 14:37
"The only remaining attack would be a man-in-the-middle attack." this can also be mitigated with DNSSSHFPrecords and, maybe, if you are using certificates and not just keys with DANE and DNSTLSArecords. In both cases the zone needs to be DNSSEC enabled.
– Patrick Mevzek
Jan 4 at 19:45
@PatrickMevzek OP is using Tor onion domains, which do not use DNS.
– forest
Jan 4 at 21:01
|
show 1 more comment
The existing answer written by forest details the security of the SSH/Tor side of things (quite secure if set up correctly), so I won't rehash that here.
I notice that you're asking mainly about client-side security ("can someone interfere with my browser?"), but I would say that server-side security ("can someone use my website/program without permission?") is also a quite important consideration when setting up a web-based program management interface.
There is potentially a very large risk to having a sensitive webpage open to the whole internet, so you really DO need to use some sort of security measure on the webserver side - it could be a Tor authorized hidden service, as forest describes, or some other method of securing the site against random hackers.
Hypothetical scenario: suppose that you had a webserver running on HTTP (as it's not clear if you're using Tor for hidden services or as a form of proxy software). Let's say you've got /index.php on there with a link to /my_program_interface.php, and for "safety's" sake, let's also put that on port 8080, with no domain name, but other than that, you allow it to accept connections from anyone. Well, if anyone ever finds out that you've got a webserver there (and with IPv4, a full network scan is feasible, so your webserver could be discovered), all they'd have to do is to type http://[your_ip_here]/index.php into a normal off-the-shelf browser, and then they have exactly as much control over your program as you do.
In other words: don't forget that that server-side authorization checks are important, along with client-side privacy checks!
answered Jan 4 at 13:02
Ethan KaminskiEthan Kaminski
2,7861819
add a comment |
It depends what you mean by secure enough.
Security does not exist without a threat model, as time-travelling, mind-reading gods can defeat any system you make.
If this is a simple utility, then the chances of someone burning a 0day for ssh on your sever is minimal, since there are simply better targets, and it wouldn't be worth the time and effort.
However, if you plan on running a system to co-ordinate a giant criminal empire behind the site, you should expect that a large intellegence agency can track the tor traffic back to you box, either by using an attack on the Tor network, or by simple rubber-hose cryptography:
However, even if your system is theoretically secure enough, there is the human element: you can never be 100% sure that you have set it up correctly, and so it may be trivial to hack.
A very important rule for security is to expect that your system will be broken at some point. A large part of the design of a secure system is making sure that when it is broken, it doesn't cause too much damage. To that end, I would suggest something like a docker image, so that you can easily scrub it if it does get broken into.
If the actual cryptography behind ssh was broken, you should be more worried about collecting canned goods, as an economic collapse would occur that would make the Great Depression look like the Slightly Sad, as any secure web traffic could be decrypted with a simple MitM (passwords, server certificates, bank details, etc.), and massive botnets of hacked servers would assault any and all internet-facing servers, effectively killing the information age, and turning the internet into a battleground.
answered Jan 4 at 12:59
Cyclic3Cyclic3
1513
Shell shock didnt cause a new age great depression did it?
– user6858980
Jan 4 at 17:08
2
@user6858980 That's because shell shock only targeted one program, bash, which is rarely publicly reachable. Even if someone found a bug in apache or nginx that gave arbitrary code execution as root (the worst feasible case), the level of sandboxing on most big websites would keep it safe, and it would be patched. This is in stark contrast to the very concept of public-key encryption being wrong, which would be as unpatchable as1 + 1 = 2
– Cyclic3
Jan 4 at 18:18
Although you're absolutely correct that it would result in an economic collapse if an easy way to break all asymmetric cryptography were suddenly revealed, I think you are exaggerating the effects a bit. It would probably not send us into a new depression worse than the Great Depression, but it would certainly result in a major shift in the economy for a very long time.
– forest
Jan 5 at 1:36
Cryptography useful for protecting traffic from eavesdropping was effectively outlawed in France until some time in the mid-1990s. (IIRC, you could use it, but you had to have a license to do so, and violation of this requirement carried a stiff fine.) If cryptography breaks down today, it wouldn't exactly put us back in France in the first half of the 1990s since the world is different today than it was then, but I think it would be a stretch too to say that France in the first half of the 1990s was effectively a third world country economically.
– a CVn
Jan 5 at 13:34
@aCVn I agree, if cryptography was slowly removed from our lives, there would be little effect. However, the loss of the internet from the giant botnets would kill or maim all tech companies. I have difficulty naming a company that doesn't heavily rely on the internet. The world would recover, and yes, would return to a pre-internet state not dissimilar from 1990. Random things we take for granted, like SIM cards, OTA software updates, and the instant access to the giant amalgamated knowledge of mankind would be forever lost. Even though I am British, I don't believe France to be that bad.
– Cyclic3
Jan 5 at 21:48
|
show 4 more comments
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "162"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
noCode: true, onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsecurity.stackexchange.com%2fquestions%2f200792%2fis-ssh-with-public-key-authentication-no-passwords-secure-enough%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
If you are using public key authentication for SSH, no one can log in to the server without having the corresponding private key. This is as secure, and usually more secure, than password authentication. The encryption OpenSSH provides is state of the art; there is no known way to break it. You can further improve security on the Tor side by using authorized hidden services. This will make the domain inaccessible to all but your client. Note that this only works with v2 hidden services, not the latest v3.
The only remaining attack would be a man-in-the-middle attack. You can copy over the host key from the server to your client, just like you copied a key to make public key authentication possible. This will completely mitigate man-in-the-middle attacks and the client will warn you if an attempt is detected.
See also What is the difference between authorized_keys and known_hosts file for SSH?
answered Jan 4 at 10:41
forestforest
34.3k16113118
Hi. Thanks for answering. I'm not sure if this is unrelated, but if I'm on DHCP, how can I find out my IP address to have the machine accessible through tor? Or is static IP the (only) way to go?
– user942937
Jan 4 at 11:35
@user942937 If you always are going to use tor to connect to it, setup a tor hidden service on the machine, this way it gets an union domain name you can use to connect to it from the outside (without requiring static ip's or port forwarding), and since the name always stays the same, you are protected in the way the answer describes when comparing the host keys)
– Ferrybig
Jan 4 at 13:39
5
It may be worth pointing out that if using public key authentication one should not forget to disable password authentication completely in order to reduce the attack surface.
– zakinster
Jan 4 at 14:37
"The only remaining attack would be a man-in-the-middle attack." this can also be mitigated with DNSSSHFPrecords and, maybe, if you are using certificates and not just keys with DANE and DNSTLSArecords. In both cases the zone needs to be DNSSEC enabled.
– Patrick Mevzek
Jan 4 at 19:45
@PatrickMevzek OP is using Tor onion domains, which do not use DNS.
– forest
Jan 4 at 21:01
|
show 1 more comment
If you are using public key authentication for SSH, no one can log in to the server without having the corresponding private key. This is as secure, and usually more secure, than password authentication. The encryption OpenSSH provides is state of the art; there is no known way to break it. You can further improve security on the Tor side by using authorized hidden services. This will make the domain inaccessible to all but your client. Note that this only works with v2 hidden services, not the latest v3.
The only remaining attack would be a man-in-the-middle attack. You can copy over the host key from the server to your client, just like you copied a key to make public key authentication possible. This will completely mitigate man-in-the-middle attacks and the client will warn you if an attempt is detected.
See also What is the difference between authorized_keys and known_hosts file for SSH?
answered Jan 4 at 10:41
forestforest
34.3k16113118
Hi. Thanks for answering. I'm not sure if this is unrelated, but if I'm on DHCP, how can I find out my IP address to have the machine accessible through tor? Or is static IP the (only) way to go?
– user942937
Jan 4 at 11:35
@user942937 If you always are going to use tor to connect to it, setup a tor hidden service on the machine, this way it gets an union domain name you can use to connect to it from the outside (without requiring static ip's or port forwarding), and since the name always stays the same, you are protected in the way the answer describes when comparing the host keys)
– Ferrybig
Jan 4 at 13:39
5
It may be worth pointing out that if using public key authentication one should not forget to disable password authentication completely in order to reduce the attack surface.
– zakinster
Jan 4 at 14:37
"The only remaining attack would be a man-in-the-middle attack." this can also be mitigated with DNSSSHFPrecords and, maybe, if you are using certificates and not just keys with DANE and DNSTLSArecords. In both cases the zone needs to be DNSSEC enabled.
– Patrick Mevzek
Jan 4 at 19:45
@PatrickMevzek OP is using Tor onion domains, which do not use DNS.
– forest
Jan 4 at 21:01
|
show 1 more comment
If you are using public key authentication for SSH, no one can log in to the server without having the corresponding private key. This is as secure, and usually more secure, than password authentication. The encryption OpenSSH provides is state of the art; there is no known way to break it. You can further improve security on the Tor side by using authorized hidden services. This will make the domain inaccessible to all but your client. Note that this only works with v2 hidden services, not the latest v3.
The only remaining attack would be a man-in-the-middle attack. You can copy over the host key from the server to your client, just like you copied a key to make public key authentication possible. This will completely mitigate man-in-the-middle attacks and the client will warn you if an attempt is detected.
See also What is the difference between authorized_keys and known_hosts file for SSH?
answered Jan 4 at 10:41
forestforest
34.3k16113118
If you are using public key authentication for SSH, no one can log in to the server without having the corresponding private key. This is as secure, and usually more secure, than password authentication. The encryption OpenSSH provides is state of the art; there is no known way to break it. You can further improve security on the Tor side by using authorized hidden services. This will make the domain inaccessible to all but your client. Note that this only works with v2 hidden services, not the latest v3.
The only remaining attack would be a man-in-the-middle attack. You can copy over the host key from the server to your client, just like you copied a key to make public key authentication possible. This will completely mitigate man-in-the-middle attacks and the client will warn you if an attempt is detected.
See also What is the difference between authorized_keys and known_hosts file for SSH?
answered Jan 4 at 10:41
forestforest
34.3k16113118
edited Jan 4 at 11:02
answered Jan 4 at 10:41
forestforest
34.3k16113118
answered Jan 4 at 10:41
forestforest
34.3k16113118
answered Jan 4 at 10:41
forestforest
34.3k16113118
34.3k16113118
Hi. Thanks for answering. I'm not sure if this is unrelated, but if I'm on DHCP, how can I find out my IP address to have the machine accessible through tor? Or is static IP the (only) way to go?
– user942937
Jan 4 at 11:35
@user942937 If you always are going to use tor to connect to it, setup a tor hidden service on the machine, this way it gets an union domain name you can use to connect to it from the outside (without requiring static ip's or port forwarding), and since the name always stays the same, you are protected in the way the answer describes when comparing the host keys)
– Ferrybig
Jan 4 at 13:39
5
It may be worth pointing out that if using public key authentication one should not forget to disable password authentication completely in order to reduce the attack surface.
– zakinster
Jan 4 at 14:37
"The only remaining attack would be a man-in-the-middle attack." this can also be mitigated with DNSSSHFPrecords and, maybe, if you are using certificates and not just keys with DANE and DNSTLSArecords. In both cases the zone needs to be DNSSEC enabled.
– Patrick Mevzek
Jan 4 at 19:45
@PatrickMevzek OP is using Tor onion domains, which do not use DNS.
– forest
Jan 4 at 21:01
|
show 1 more comment
Hi. Thanks for answering. I'm not sure if this is unrelated, but if I'm on DHCP, how can I find out my IP address to have the machine accessible through tor? Or is static IP the (only) way to go?
– user942937
Jan 4 at 11:35
@user942937 If you always are going to use tor to connect to it, setup a tor hidden service on the machine, this way it gets an union domain name you can use to connect to it from the outside (without requiring static ip's or port forwarding), and since the name always stays the same, you are protected in the way the answer describes when comparing the host keys)
– Ferrybig
Jan 4 at 13:39
5
It may be worth pointing out that if using public key authentication one should not forget to disable password authentication completely in order to reduce the attack surface.
– zakinster
Jan 4 at 14:37
"The only remaining attack would be a man-in-the-middle attack." this can also be mitigated with DNSSSHFPrecords and, maybe, if you are using certificates and not just keys with DANE and DNSTLSArecords. In both cases the zone needs to be DNSSEC enabled.
– Patrick Mevzek
Jan 4 at 19:45
@PatrickMevzek OP is using Tor onion domains, which do not use DNS.
– forest
Jan 4 at 21:01
Hi. Thanks for answering. I'm not sure if this is unrelated, but if I'm on DHCP, how can I find out my IP address to have the machine accessible through tor? Or is static IP the (only) way to go?
– user942937
Jan 4 at 11:35
Hi. Thanks for answering. I'm not sure if this is unrelated, but if I'm on DHCP, how can I find out my IP address to have the machine accessible through tor? Or is static IP the (only) way to go?
– user942937
Jan 4 at 11:35
@user942937 If you always are going to use tor to connect to it, setup a tor hidden service on the machine, this way it gets an union domain name you can use to connect to it from the outside (without requiring static ip's or port forwarding), and since the name always stays the same, you are protected in the way the answer describes when comparing the host keys)
– Ferrybig
Jan 4 at 13:39
@user942937 If you always are going to use tor to connect to it, setup a tor hidden service on the machine, this way it gets an union domain name you can use to connect to it from the outside (without requiring static ip's or port forwarding), and since the name always stays the same, you are protected in the way the answer describes when comparing the host keys)
– Ferrybig
Jan 4 at 13:39
5
5
It may be worth pointing out that if using public key authentication one should not forget to disable password authentication completely in order to reduce the attack surface.
– zakinster
Jan 4 at 14:37
It may be worth pointing out that if using public key authentication one should not forget to disable password authentication completely in order to reduce the attack surface.
– zakinster
Jan 4 at 14:37
"The only remaining attack would be a man-in-the-middle attack." this can also be mitigated with DNS
SSHFP records and, maybe, if you are using certificates and not just keys with DANE and DNS TLSA records. In both cases the zone needs to be DNSSEC enabled.– Patrick Mevzek
Jan 4 at 19:45
"The only remaining attack would be a man-in-the-middle attack." this can also be mitigated with DNS
SSHFP records and, maybe, if you are using certificates and not just keys with DANE and DNS TLSA records. In both cases the zone needs to be DNSSEC enabled.– Patrick Mevzek
Jan 4 at 19:45
@PatrickMevzek OP is using Tor onion domains, which do not use DNS.
– forest
Jan 4 at 21:01
@PatrickMevzek OP is using Tor onion domains, which do not use DNS.
– forest
Jan 4 at 21:01
|
show 1 more comment
The existing answer written by forest details the security of the SSH/Tor side of things (quite secure if set up correctly), so I won't rehash that here.
I notice that you're asking mainly about client-side security ("can someone interfere with my browser?"), but I would say that server-side security ("can someone use my website/program without permission?") is also a quite important consideration when setting up a web-based program management interface.
There is potentially a very large risk to having a sensitive webpage open to the whole internet, so you really DO need to use some sort of security measure on the webserver side - it could be a Tor authorized hidden service, as forest describes, or some other method of securing the site against random hackers.
Hypothetical scenario: suppose that you had a webserver running on HTTP (as it's not clear if you're using Tor for hidden services or as a form of proxy software). Let's say you've got /index.php on there with a link to /my_program_interface.php, and for "safety's" sake, let's also put that on port 8080, with no domain name, but other than that, you allow it to accept connections from anyone. Well, if anyone ever finds out that you've got a webserver there (and with IPv4, a full network scan is feasible, so your webserver could be discovered), all they'd have to do is to type http://[your_ip_here]/index.php into a normal off-the-shelf browser, and then they have exactly as much control over your program as you do.
In other words: don't forget that that server-side authorization checks are important, along with client-side privacy checks!
answered Jan 4 at 13:02
Ethan KaminskiEthan Kaminski
2,7861819
add a comment |
The existing answer written by forest details the security of the SSH/Tor side of things (quite secure if set up correctly), so I won't rehash that here.
I notice that you're asking mainly about client-side security ("can someone interfere with my browser?"), but I would say that server-side security ("can someone use my website/program without permission?") is also a quite important consideration when setting up a web-based program management interface.
There is potentially a very large risk to having a sensitive webpage open to the whole internet, so you really DO need to use some sort of security measure on the webserver side - it could be a Tor authorized hidden service, as forest describes, or some other method of securing the site against random hackers.
Hypothetical scenario: suppose that you had a webserver running on HTTP (as it's not clear if you're using Tor for hidden services or as a form of proxy software). Let's say you've got /index.php on there with a link to /my_program_interface.php, and for "safety's" sake, let's also put that on port 8080, with no domain name, but other than that, you allow it to accept connections from anyone. Well, if anyone ever finds out that you've got a webserver there (and with IPv4, a full network scan is feasible, so your webserver could be discovered), all they'd have to do is to type http://[your_ip_here]/index.php into a normal off-the-shelf browser, and then they have exactly as much control over your program as you do.
In other words: don't forget that that server-side authorization checks are important, along with client-side privacy checks!
answered Jan 4 at 13:02
Ethan KaminskiEthan Kaminski
2,7861819
add a comment |
The existing answer written by forest details the security of the SSH/Tor side of things (quite secure if set up correctly), so I won't rehash that here.
I notice that you're asking mainly about client-side security ("can someone interfere with my browser?"), but I would say that server-side security ("can someone use my website/program without permission?") is also a quite important consideration when setting up a web-based program management interface.
There is potentially a very large risk to having a sensitive webpage open to the whole internet, so you really DO need to use some sort of security measure on the webserver side - it could be a Tor authorized hidden service, as forest describes, or some other method of securing the site against random hackers.
Hypothetical scenario: suppose that you had a webserver running on HTTP (as it's not clear if you're using Tor for hidden services or as a form of proxy software). Let's say you've got /index.php on there with a link to /my_program_interface.php, and for "safety's" sake, let's also put that on port 8080, with no domain name, but other than that, you allow it to accept connections from anyone. Well, if anyone ever finds out that you've got a webserver there (and with IPv4, a full network scan is feasible, so your webserver could be discovered), all they'd have to do is to type http://[your_ip_here]/index.php into a normal off-the-shelf browser, and then they have exactly as much control over your program as you do.
In other words: don't forget that that server-side authorization checks are important, along with client-side privacy checks!
answered Jan 4 at 13:02
Ethan KaminskiEthan Kaminski
2,7861819
The existing answer written by forest details the security of the SSH/Tor side of things (quite secure if set up correctly), so I won't rehash that here.
I notice that you're asking mainly about client-side security ("can someone interfere with my browser?"), but I would say that server-side security ("can someone use my website/program without permission?") is also a quite important consideration when setting up a web-based program management interface.
There is potentially a very large risk to having a sensitive webpage open to the whole internet, so you really DO need to use some sort of security measure on the webserver side - it could be a Tor authorized hidden service, as forest describes, or some other method of securing the site against random hackers.
Hypothetical scenario: suppose that you had a webserver running on HTTP (as it's not clear if you're using Tor for hidden services or as a form of proxy software). Let's say you've got /index.php on there with a link to /my_program_interface.php, and for "safety's" sake, let's also put that on port 8080, with no domain name, but other than that, you allow it to accept connections from anyone. Well, if anyone ever finds out that you've got a webserver there (and with IPv4, a full network scan is feasible, so your webserver could be discovered), all they'd have to do is to type http://[your_ip_here]/index.php into a normal off-the-shelf browser, and then they have exactly as much control over your program as you do.
In other words: don't forget that that server-side authorization checks are important, along with client-side privacy checks!
answered Jan 4 at 13:02
Ethan KaminskiEthan Kaminski
2,7861819
answered Jan 4 at 13:02
Ethan KaminskiEthan Kaminski
2,7861819
answered Jan 4 at 13:02
Ethan KaminskiEthan Kaminski
2,7861819
answered Jan 4 at 13:02
Ethan KaminskiEthan Kaminski
2,7861819
2,7861819
add a comment |
add a comment |
It depends what you mean by secure enough.
Security does not exist without a threat model, as time-travelling, mind-reading gods can defeat any system you make.
If this is a simple utility, then the chances of someone burning a 0day for ssh on your sever is minimal, since there are simply better targets, and it wouldn't be worth the time and effort.
However, if you plan on running a system to co-ordinate a giant criminal empire behind the site, you should expect that a large intellegence agency can track the tor traffic back to you box, either by using an attack on the Tor network, or by simple rubber-hose cryptography:
However, even if your system is theoretically secure enough, there is the human element: you can never be 100% sure that you have set it up correctly, and so it may be trivial to hack.
A very important rule for security is to expect that your system will be broken at some point. A large part of the design of a secure system is making sure that when it is broken, it doesn't cause too much damage. To that end, I would suggest something like a docker image, so that you can easily scrub it if it does get broken into.
If the actual cryptography behind ssh was broken, you should be more worried about collecting canned goods, as an economic collapse would occur that would make the Great Depression look like the Slightly Sad, as any secure web traffic could be decrypted with a simple MitM (passwords, server certificates, bank details, etc.), and massive botnets of hacked servers would assault any and all internet-facing servers, effectively killing the information age, and turning the internet into a battleground.
answered Jan 4 at 12:59
Cyclic3Cyclic3
1513
Shell shock didnt cause a new age great depression did it?
– user6858980
Jan 4 at 17:08
2
@user6858980 That's because shell shock only targeted one program, bash, which is rarely publicly reachable. Even if someone found a bug in apache or nginx that gave arbitrary code execution as root (the worst feasible case), the level of sandboxing on most big websites would keep it safe, and it would be patched. This is in stark contrast to the very concept of public-key encryption being wrong, which would be as unpatchable as1 + 1 = 2
– Cyclic3
Jan 4 at 18:18
Although you're absolutely correct that it would result in an economic collapse if an easy way to break all asymmetric cryptography were suddenly revealed, I think you are exaggerating the effects a bit. It would probably not send us into a new depression worse than the Great Depression, but it would certainly result in a major shift in the economy for a very long time.
– forest
Jan 5 at 1:36
Cryptography useful for protecting traffic from eavesdropping was effectively outlawed in France until some time in the mid-1990s. (IIRC, you could use it, but you had to have a license to do so, and violation of this requirement carried a stiff fine.) If cryptography breaks down today, it wouldn't exactly put us back in France in the first half of the 1990s since the world is different today than it was then, but I think it would be a stretch too to say that France in the first half of the 1990s was effectively a third world country economically.
– a CVn
Jan 5 at 13:34
@aCVn I agree, if cryptography was slowly removed from our lives, there would be little effect. However, the loss of the internet from the giant botnets would kill or maim all tech companies. I have difficulty naming a company that doesn't heavily rely on the internet. The world would recover, and yes, would return to a pre-internet state not dissimilar from 1990. Random things we take for granted, like SIM cards, OTA software updates, and the instant access to the giant amalgamated knowledge of mankind would be forever lost. Even though I am British, I don't believe France to be that bad.
– Cyclic3
Jan 5 at 21:48
|
show 4 more comments
It depends what you mean by secure enough.
Security does not exist without a threat model, as time-travelling, mind-reading gods can defeat any system you make.
If this is a simple utility, then the chances of someone burning a 0day for ssh on your sever is minimal, since there are simply better targets, and it wouldn't be worth the time and effort.
However, if you plan on running a system to co-ordinate a giant criminal empire behind the site, you should expect that a large intellegence agency can track the tor traffic back to you box, either by using an attack on the Tor network, or by simple rubber-hose cryptography:
However, even if your system is theoretically secure enough, there is the human element: you can never be 100% sure that you have set it up correctly, and so it may be trivial to hack.
A very important rule for security is to expect that your system will be broken at some point. A large part of the design of a secure system is making sure that when it is broken, it doesn't cause too much damage. To that end, I would suggest something like a docker image, so that you can easily scrub it if it does get broken into.
If the actual cryptography behind ssh was broken, you should be more worried about collecting canned goods, as an economic collapse would occur that would make the Great Depression look like the Slightly Sad, as any secure web traffic could be decrypted with a simple MitM (passwords, server certificates, bank details, etc.), and massive botnets of hacked servers would assault any and all internet-facing servers, effectively killing the information age, and turning the internet into a battleground.
answered Jan 4 at 12:59
Cyclic3Cyclic3
1513
Shell shock didnt cause a new age great depression did it?
– user6858980
Jan 4 at 17:08
2
@user6858980 That's because shell shock only targeted one program, bash, which is rarely publicly reachable. Even if someone found a bug in apache or nginx that gave arbitrary code execution as root (the worst feasible case), the level of sandboxing on most big websites would keep it safe, and it would be patched. This is in stark contrast to the very concept of public-key encryption being wrong, which would be as unpatchable as1 + 1 = 2
– Cyclic3
Jan 4 at 18:18
Although you're absolutely correct that it would result in an economic collapse if an easy way to break all asymmetric cryptography were suddenly revealed, I think you are exaggerating the effects a bit. It would probably not send us into a new depression worse than the Great Depression, but it would certainly result in a major shift in the economy for a very long time.
– forest
Jan 5 at 1:36
Cryptography useful for protecting traffic from eavesdropping was effectively outlawed in France until some time in the mid-1990s. (IIRC, you could use it, but you had to have a license to do so, and violation of this requirement carried a stiff fine.) If cryptography breaks down today, it wouldn't exactly put us back in France in the first half of the 1990s since the world is different today than it was then, but I think it would be a stretch too to say that France in the first half of the 1990s was effectively a third world country economically.
– a CVn
Jan 5 at 13:34
@aCVn I agree, if cryptography was slowly removed from our lives, there would be little effect. However, the loss of the internet from the giant botnets would kill or maim all tech companies. I have difficulty naming a company that doesn't heavily rely on the internet. The world would recover, and yes, would return to a pre-internet state not dissimilar from 1990. Random things we take for granted, like SIM cards, OTA software updates, and the instant access to the giant amalgamated knowledge of mankind would be forever lost. Even though I am British, I don't believe France to be that bad.
– Cyclic3
Jan 5 at 21:48
|
show 4 more comments
It depends what you mean by secure enough.
Security does not exist without a threat model, as time-travelling, mind-reading gods can defeat any system you make.
If this is a simple utility, then the chances of someone burning a 0day for ssh on your sever is minimal, since there are simply better targets, and it wouldn't be worth the time and effort.
However, if you plan on running a system to co-ordinate a giant criminal empire behind the site, you should expect that a large intellegence agency can track the tor traffic back to you box, either by using an attack on the Tor network, or by simple rubber-hose cryptography:
However, even if your system is theoretically secure enough, there is the human element: you can never be 100% sure that you have set it up correctly, and so it may be trivial to hack.
A very important rule for security is to expect that your system will be broken at some point. A large part of the design of a secure system is making sure that when it is broken, it doesn't cause too much damage. To that end, I would suggest something like a docker image, so that you can easily scrub it if it does get broken into.
If the actual cryptography behind ssh was broken, you should be more worried about collecting canned goods, as an economic collapse would occur that would make the Great Depression look like the Slightly Sad, as any secure web traffic could be decrypted with a simple MitM (passwords, server certificates, bank details, etc.), and massive botnets of hacked servers would assault any and all internet-facing servers, effectively killing the information age, and turning the internet into a battleground.
answered Jan 4 at 12:59
Cyclic3Cyclic3
1513
It depends what you mean by secure enough.
Security does not exist without a threat model, as time-travelling, mind-reading gods can defeat any system you make.
If this is a simple utility, then the chances of someone burning a 0day for ssh on your sever is minimal, since there are simply better targets, and it wouldn't be worth the time and effort.
However, if you plan on running a system to co-ordinate a giant criminal empire behind the site, you should expect that a large intellegence agency can track the tor traffic back to you box, either by using an attack on the Tor network, or by simple rubber-hose cryptography:
However, even if your system is theoretically secure enough, there is the human element: you can never be 100% sure that you have set it up correctly, and so it may be trivial to hack.
A very important rule for security is to expect that your system will be broken at some point. A large part of the design of a secure system is making sure that when it is broken, it doesn't cause too much damage. To that end, I would suggest something like a docker image, so that you can easily scrub it if it does get broken into.
If the actual cryptography behind ssh was broken, you should be more worried about collecting canned goods, as an economic collapse would occur that would make the Great Depression look like the Slightly Sad, as any secure web traffic could be decrypted with a simple MitM (passwords, server certificates, bank details, etc.), and massive botnets of hacked servers would assault any and all internet-facing servers, effectively killing the information age, and turning the internet into a battleground.
answered Jan 4 at 12:59
Cyclic3Cyclic3
1513
answered Jan 4 at 12:59
Cyclic3Cyclic3
1513
answered Jan 4 at 12:59
Cyclic3Cyclic3
1513
answered Jan 4 at 12:59
Cyclic3Cyclic3
1513
1513
Shell shock didnt cause a new age great depression did it?
– user6858980
Jan 4 at 17:08
2
@user6858980 That's because shell shock only targeted one program, bash, which is rarely publicly reachable. Even if someone found a bug in apache or nginx that gave arbitrary code execution as root (the worst feasible case), the level of sandboxing on most big websites would keep it safe, and it would be patched. This is in stark contrast to the very concept of public-key encryption being wrong, which would be as unpatchable as1 + 1 = 2
– Cyclic3
Jan 4 at 18:18
Although you're absolutely correct that it would result in an economic collapse if an easy way to break all asymmetric cryptography were suddenly revealed, I think you are exaggerating the effects a bit. It would probably not send us into a new depression worse than the Great Depression, but it would certainly result in a major shift in the economy for a very long time.
– forest
Jan 5 at 1:36
Cryptography useful for protecting traffic from eavesdropping was effectively outlawed in France until some time in the mid-1990s. (IIRC, you could use it, but you had to have a license to do so, and violation of this requirement carried a stiff fine.) If cryptography breaks down today, it wouldn't exactly put us back in France in the first half of the 1990s since the world is different today than it was then, but I think it would be a stretch too to say that France in the first half of the 1990s was effectively a third world country economically.
– a CVn
Jan 5 at 13:34
@aCVn I agree, if cryptography was slowly removed from our lives, there would be little effect. However, the loss of the internet from the giant botnets would kill or maim all tech companies. I have difficulty naming a company that doesn't heavily rely on the internet. The world would recover, and yes, would return to a pre-internet state not dissimilar from 1990. Random things we take for granted, like SIM cards, OTA software updates, and the instant access to the giant amalgamated knowledge of mankind would be forever lost. Even though I am British, I don't believe France to be that bad.
– Cyclic3
Jan 5 at 21:48
|
show 4 more comments
Shell shock didnt cause a new age great depression did it?
– user6858980
Jan 4 at 17:08
2
@user6858980 That's because shell shock only targeted one program, bash, which is rarely publicly reachable. Even if someone found a bug in apache or nginx that gave arbitrary code execution as root (the worst feasible case), the level of sandboxing on most big websites would keep it safe, and it would be patched. This is in stark contrast to the very concept of public-key encryption being wrong, which would be as unpatchable as1 + 1 = 2
– Cyclic3
Jan 4 at 18:18
Although you're absolutely correct that it would result in an economic collapse if an easy way to break all asymmetric cryptography were suddenly revealed, I think you are exaggerating the effects a bit. It would probably not send us into a new depression worse than the Great Depression, but it would certainly result in a major shift in the economy for a very long time.
– forest
Jan 5 at 1:36
Cryptography useful for protecting traffic from eavesdropping was effectively outlawed in France until some time in the mid-1990s. (IIRC, you could use it, but you had to have a license to do so, and violation of this requirement carried a stiff fine.) If cryptography breaks down today, it wouldn't exactly put us back in France in the first half of the 1990s since the world is different today than it was then, but I think it would be a stretch too to say that France in the first half of the 1990s was effectively a third world country economically.
– a CVn
Jan 5 at 13:34
@aCVn I agree, if cryptography was slowly removed from our lives, there would be little effect. However, the loss of the internet from the giant botnets would kill or maim all tech companies. I have difficulty naming a company that doesn't heavily rely on the internet. The world would recover, and yes, would return to a pre-internet state not dissimilar from 1990. Random things we take for granted, like SIM cards, OTA software updates, and the instant access to the giant amalgamated knowledge of mankind would be forever lost. Even though I am British, I don't believe France to be that bad.
– Cyclic3
Jan 5 at 21:48
Shell shock didnt cause a new age great depression did it?
– user6858980
Jan 4 at 17:08
Shell shock didnt cause a new age great depression did it?
– user6858980
Jan 4 at 17:08
2
2
@user6858980 That's because shell shock only targeted one program, bash, which is rarely publicly reachable. Even if someone found a bug in apache or nginx that gave arbitrary code execution as root (the worst feasible case), the level of sandboxing on most big websites would keep it safe, and it would be patched. This is in stark contrast to the very concept of public-key encryption being wrong, which would be as unpatchable as
1 + 1 = 2– Cyclic3
Jan 4 at 18:18
@user6858980 That's because shell shock only targeted one program, bash, which is rarely publicly reachable. Even if someone found a bug in apache or nginx that gave arbitrary code execution as root (the worst feasible case), the level of sandboxing on most big websites would keep it safe, and it would be patched. This is in stark contrast to the very concept of public-key encryption being wrong, which would be as unpatchable as
1 + 1 = 2– Cyclic3
Jan 4 at 18:18
Although you're absolutely correct that it would result in an economic collapse if an easy way to break all asymmetric cryptography were suddenly revealed, I think you are exaggerating the effects a bit. It would probably not send us into a new depression worse than the Great Depression, but it would certainly result in a major shift in the economy for a very long time.
– forest
Jan 5 at 1:36
Although you're absolutely correct that it would result in an economic collapse if an easy way to break all asymmetric cryptography were suddenly revealed, I think you are exaggerating the effects a bit. It would probably not send us into a new depression worse than the Great Depression, but it would certainly result in a major shift in the economy for a very long time.
– forest
Jan 5 at 1:36
Cryptography useful for protecting traffic from eavesdropping was effectively outlawed in France until some time in the mid-1990s. (IIRC, you could use it, but you had to have a license to do so, and violation of this requirement carried a stiff fine.) If cryptography breaks down today, it wouldn't exactly put us back in France in the first half of the 1990s since the world is different today than it was then, but I think it would be a stretch too to say that France in the first half of the 1990s was effectively a third world country economically.
– a CVn
Jan 5 at 13:34
Cryptography useful for protecting traffic from eavesdropping was effectively outlawed in France until some time in the mid-1990s. (IIRC, you could use it, but you had to have a license to do so, and violation of this requirement carried a stiff fine.) If cryptography breaks down today, it wouldn't exactly put us back in France in the first half of the 1990s since the world is different today than it was then, but I think it would be a stretch too to say that France in the first half of the 1990s was effectively a third world country economically.
– a CVn
Jan 5 at 13:34
@aCVn I agree, if cryptography was slowly removed from our lives, there would be little effect. However, the loss of the internet from the giant botnets would kill or maim all tech companies. I have difficulty naming a company that doesn't heavily rely on the internet. The world would recover, and yes, would return to a pre-internet state not dissimilar from 1990. Random things we take for granted, like SIM cards, OTA software updates, and the instant access to the giant amalgamated knowledge of mankind would be forever lost. Even though I am British, I don't believe France to be that bad.
– Cyclic3
Jan 5 at 21:48
@aCVn I agree, if cryptography was slowly removed from our lives, there would be little effect. However, the loss of the internet from the giant botnets would kill or maim all tech companies. I have difficulty naming a company that doesn't heavily rely on the internet. The world would recover, and yes, would return to a pre-internet state not dissimilar from 1990. Random things we take for granted, like SIM cards, OTA software updates, and the instant access to the giant amalgamated knowledge of mankind would be forever lost. Even though I am British, I don't believe France to be that bad.
– Cyclic3
Jan 5 at 21:48
|
show 4 more comments
Thanks for contributing an answer to Information Security Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsecurity.stackexchange.com%2fquestions%2f200792%2fis-ssh-with-public-key-authentication-no-passwords-secure-enough%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
9
To verify, you mean "ssh using key-based authentication" (or some such), and NOT "ssh without a password", right? If so, it would be worth editing the title to match. I won't do so without having verified your intent, though (since to me, that subtle wording change carries a significant difference in intent and risk).
– Ethan Kaminski
Jan 4 at 12:31
3
Actually, scratch that, I didn't quite read far enough (read it too quickly). Further question, for clarification: you've got an externally-accessible webpage, right? Or are you making the HTTP request on localhost (and/or another LAN address)? That's also going to be a relevant detail, moreso than the SSH itself.
– Ethan Kaminski
Jan 4 at 12:34
Yup. Two machines: one with the externally-accessible webpage and another used for ssh-tunneling. Unless there's a way to have them both on just one machine.
– user942937
Jan 4 at 12:38
That would be FAR safer to set up that way, yes. Let me type up an answer about that, since the current answer only seems to cover the SSH/Tor side of things, without detailing the risks of having an admin-y panel served by a webserver open to the whole internet.
– Ethan Kaminski
Jan 4 at 12:42
If that automated login is only for port forwarding you can use a user which does not allow shell access. While key based authentication is very strong the key on the client side is the weakness, so limiting reach can additionally mitigate risks.
– eckes
Jan 4 at 15:34