One way you could get a static IP is by renting a VPS somewhere. Then you can connect to the VPS using SSH or VPN, and from the VPS to the server with SSH.
One may notice that in this setup the VPS is being used in a way, that is similar to a bastion host or a jump server. However it does not nearly match the security standards you would expect from a bastion host.
In particular communication between bastion host and server is expected to go over a private and secure network. But the communication between VPS and server would go over the public internet.
So you can improve security by ditching the VPS and setting up a real bastion host in the same data center as the target server.
If at this point you were to decide that for extra security, the bastion host will only allow connections from white-listed IPs, you have completed a full cycle.
If you for some reason were to go through this cycle over and over again, you'd end up adding layers of bastion hosts. But layers of bastion hosts don't add security. Having to go through one bastion host could be a good idea, having to go through two is just stupid.
Obviously if you do go through this entire cycle, you are doing something wrong. I can see two possibilities for where the mistake would be, which of the two is the mistake depends on your security policy:
- Limiting access to the bastion host to a white-list is stupid, because the bastion host itself is supposed to be the one host kept secure enough, that you don't need that kind of protection.
- Trying to access the bastion host from a machine with no static IP address is simply an attempt at bypassing the security policy, and it should not be done. Instead one should get to the white-listed location first, and then start doing maintenance.
How to secure and use a bastion host
If we assume both bastion host and server are accessed using the SSH protocol, then a command to connect to the server could look like this:
ssh -o ProxyCommand='ssh -W %h:%p username@bastion' username@server
In this command it is important that the SSH connection to the server comes directly from the client. The bastion is just used for transport, and even if the bastion should be compromised, you still have a second line of defense in the use of SSH to the server.
In order to have this layer of security, you must:
- Never forward an ssh agent to the bastion host
- Never ssh to the server from a shell on the bastion host
- Always use the
ProxyCommand
option on the ssh command connecting to the server.
In order to keep the bastion host as secure as possible, the following should be done:
- Ensure the bastion has no listening services other than
sshd
.
- Configure
sshd
to only accept authentication using public key, and nothing else.
- Always keep kernel and
sshd
on the bastion host updated with security updates.
- Uninstall all software from the bastion host, which is not strictly needed.
You can run sshd
on a non-standard port. This will keep most port scanners away. This servers just one purpose, it significantly reduces the number of failed login attempts you will see in your logs. It doesn't really add any security though, because the vast majority of those finding your server through port scanning are either targeting weak passwords (which won't work on a server that only accept key based authentication) or known security vulnerabilities (which you of course patch before an attack has had time to prepare an attack on the specific vulnerability). If you are facing a targeted attack, then the attacker will find your server regardless of port number.