Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I am trying to figure out what happens when I do a port forward using OpenSSH (ssh -L <local_port>:<remote_host_2> -fN <remote_host_1>), and how it compares to simply ssh'ing to a remote host.
More specifically, I wonder if remote_host_1 is compromised, can it sniff the traffic
that I am sending to remote_host_2? From the manfile of ssh, it seems that the answer to this question is positive and thus the chain (if, e.g., I am trying to telnet to remote_host_2 via remote_host_1) looks like this:
local_host --[secure]--> remote_host_1 --[open]--> remote_host_2 .
However, what happens if I ssh to the remote_host_2 via the aforementioned port forward (ssh <local_host> -p <local_port>)? Is it correct, that even if the remote_host_1 is compromised, there is no danger? In other words, is the following true in that case:
local_host --[double encryption]--> remote_host_1 --> [single encryption] --> remote_host_2 .
Finally, is it correct that the second situation is still different from ssh'ing to remote_host_1 and ssh'ing to remote_host_2 from it, in the sense that if remote_host_1 is compromised, it can log everything?
Thank you very much!
Your data is encrypted between the client and SSH. From SSH to the target port it is plaintext of course, or rather it is exactly what you are sending over the tunnel to the target application. Only the tunnel part is encrypted.
In short, all the questions should be answered 'yes'.
A reference that answers all my questions is the chapter 11 of "SSH, The Secure Shell" by Daniel J. Barrett & Richard Silverman. An excerpt with all the relevant info can be found here.
I again thank Simon and EJP for their answers.
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 7 months ago.
Improve this question
I created a public SSH key on my local computer and added it to my github account.
Now I want to connect to my server (online) via terminal, in order to clone my git project to the server of my provider.
In an online tutorial to connect they suggest:
ssh root#< IP-ADDRESS OF THE SERVERS>
But in my server settings I can online find the following data:
SSH-Hostname,SSH-Username,SSH-Port,SSH Fingerprint
Is it possible to connect also with Hostname and Username? Because I cannot find the ip address of my provider.
Thank you
This isn't really on topic here (stackoverflow), but I'll put in a quick answer anyway: ssh makes a network connection to an ssh server, therefore ssh needs a network address for the server. This need not be an IP address, except for one other issue, which is that the ssh protocol is defined as a TCP protocol and TCP runs over IP (v4 or v6).
That said, almost all networking systems have a mechanism for translating a host name to a set of addresses (some of which may be IP addresses; others might be XNS or IPX or some such: see What is Address Family?). So you just need user#host, and something—OS and/or library dependent—will look up the proper IP address. You can leave off the user# part in some cases.
If (this is a pretty big "if") your system can't translate the host name to an IP address, or does it incorrectly, then you can resort to a raw IP address. This bypasses the translation step. If you don't trust your translation software, you can do this intentionally.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 1 year ago.
Improve this question
I have a Raspberry Pi behind an LTE-router to connect to the internet. The LTE router prevent the Pi to get assigned a static IP, so I created a service that builds a reverse ssh tunnel with auto-ssh to my private Server to be able to access my pi remotely. The problem is now, if someone gets the SD card of the Pi, he can read the private key from the file system and has access to my server.
Is there any way to protect my server from access through the ssh connection with this key while keep the abillity to build a reverse tunnel wihtout password?
The server is hosted by strato, which is managed by Plesk, so every domain has its own vhost file system in /var/www/vhost/domain.de. Would it be possible to isolate this space for the ssh access with exact this key on the Pi, so the Client can only see whats inside this folder? Or ist there any other solution for my problem?
Create a new (tunnel) key on the raspberry, only to build the reverse tunnel to your strato server.
On your strato server add the public key into .ssh/authorized_keys, but add in front
command=/bin/false ssh-rsa ....
To connect you have to add -N to ssh this will build a tunnel but doesn't try to open a shell.
Now it's unimportant if that key get lost, as it can only build a reverse tunnel, but can not open a shell.
You can even use that key for all raspi's to build individual reverse tunnels.
Obviously, you add on your raspi in .ssh/authorized_keys only your user key, not the tunnel key
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 1 year ago.
Improve this question
I'm working with Fedora33 and I have a problem with a ssh host connection (i'm just trying to remove it)
I have a pop up from Openssh that ask me for the host password
host.name password:
But i have not the password asked, i just want to remove that connection.
I tried to remove the host key like that
ssh-keygen -R 'ett.nacre-solutions.com'
but now i have an other pop up that i can't remove with this message :
The authenticity of host host.name can't be established.
ECDSA key fingerprint is SHA256:(random.caracters).
Are you sure you want to continue connecting (yes/no/[fingerprint])?
How can i really remove that automatic connection ? (The pop appears approximately every 5min)
Try this:
cat .ssh/known_hosts
Find the IP of 'ett.nacre-solutions.com' (if 'ett.nacre-solutions.com' was the last remote you connected to, the last IP in known_hosts belongs to it).
ssh-keygen -R <IP>
I suspect that you can't remove it because you're passing the web page instead of the IP.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 2 years ago.
Improve this question
I have a remote host ( a VPS ) that I connect to with SSH and it works fine. But sometimes I need to establish VPN connection on it.
By establishing the VPN connection, my ssh breaks and doesn't respond anymore and further tries to connect to it fails with the error:
ssh: connect to host 192.168.1.105 port 22: No route to host
How can I configure VPN or SSH in order to solve this conflict?
As I searched for this problem I saw configurations with iproutes and rules that resolved the problem.But I, myself, found an easy solution by changing the SSH config on client side of tht SSH connection.
There are some configurations on ssh that is reachable through this link.
After going through the link I found out you can create or change a config file ( ~/.ssh/conf )
nano ~/.ssh/conf
And changing it to:
Host *
ServerAliveInterval 300
ServerAliveCountMax 2
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 9 years ago.
Improve this question
I think this should be standard for everybody to do anyway, but maybe I'm missing something.
I want to block access to my site through every port/method/protocol except a select few methods:
This includes blocking use of the IP address rather than the domain name. So visits to 123.55.123.66 and ssh://123.55.123.66 will always fail.
Also, blocking all FTP access
These only will be allowed:
(1) http://domain.com
(2) https://domain.com
(3) ssh://ssh-access.domain.com
So SSH is only available at this subdomain, so people can't hit SSH from the IP or the same domain that is publicly available.
Also, http://ssh-access.domain.com would fail.
No access to FTP, Telnet anything.
Is this a good idea?
Because I can't even think of all the different ports/protcols available, I think it's best to block all except the above listed (rather than block all FTP, SSH etc.).
Also, if anyone has any pointers as to how I would code this, that would be great. I'm guessing it's best to do it in Apache (or Ubuntu).
You cannot "visit" ssh://123.55.123.66 in the proper sense (i.e. with a web browser) and, although some file browsers offer this extension, Apache is not involved in the connection (instead, the SSH daemon is). Moreover, SSH daemon has no notion of "(sub)domain".
That said, you can configure SSH daemon to listen only on the "remote access" IP address (bind it to that address).
For the website, you can adapt the appropriate Mod-Security rules to deny access to people/bots trying to access the website by IP address, rather than by web address.