[indigodaddy]

Oracle has a generous free tier for OCI instances/VMs, and includes a public IP. You can use that as an ssh bastion/jumphost.

Or if don’t want to do business with Oracle, you can find VPS/VM providers who offer tiny instances for $10-12/yr or less. You don’t need much ram for a bastion. 128M ram would do the trick, and even 64M (you’d have to use a stripped down image/distro though).

There are even providers who offer instances for even less $ and only give you an ipv6 range + NAT IPv4 address with a small port range. This would also work perfectly fine as a bastion.

[dx034]

Just be careful with a bastion host that you have a fallback. If anything happens to the bastion host and you don't have access to that IP, your VPS is basically lost. If you use a bastion host, I'd at least have two.

[gkrishna]

This shouldn't be a big problem as you can use configuration management such Ansible to get around. In case of bastion loss you can simply create a new instance and run the script to recover your instances.

[aborsy]

The same question applies to oracle VPS: how to allow only few IPs?

A compromise of oracle VPS and attacking AWS VPS is same as attacking AWS VPS from internet. If oracle VPS is not compromised, neither will be AWS.

Don’t see the point in this case.

[dx034]

The advantage is that you only need to harden one instance. The others are safe as they're basically in an "internal" network (firewall blocks all other IPs). With that bastion host, you'd do anything to make it as secure as possible (fail2ban or the like, authkey, block countries you won't access from, etc). For small projects, it's also reasonable to check logs from one host, but not to do so for 10 hosts.

[aborsy]

Sorry I am missing your point. That makes sense if first VPS is serving multiple ssh servers; so you harden one instance. In this case, the person has only one instance. Instead of hardening oracle VPs, they could harden aws instance.

Bastion makes sense if it’s locked down more than destination. This doesn’t apply if there is only one destination and one public service (SSH).

I suggest using AWS AMS or putting it behind vpn.

[indigodaddy]

If his AWS instance is running internet facing applications and services, then it makes sense to have the AWS firewall lock down port 22 to a single IP or two (eg your bastions), and also have that AWS firewall only allow all access to those specific internet facing ports for any relevant applications. Yes you can and should also harden at the OS level. But it’s smart to utilize AWS’ security as well as much as possible on any instance that you need to be in production and available. You want to limit it’s exposure in any way you can.

So back to the bastion. You have the bastion open to all IPs for port 22 because you want to be able to connect to it from anywhere. Yes you also of course lock it down and use best practice sshd config measures. But you only have ssh running and you use keys with passphrase for your outbound ssh connections for increased security. You keep it updated.

Your bastion will not be as locked down as your AWS instance though because it won’t have that AWS security in front of it, but you’re not concerned that much about your bastion, because it only has ssh listening, and you’ve disabled root ssh and password login, you keep it regularly updated, and the only thing you ever do with it is ssh to it and then ssh again to your important endpoints using a key WITH a passphrase.

Your AWS instance is your primary concern and is the important thing that you care about the most here. So you put the most protection in front of that in front of key services. Like OP said, ssh to the AWS instance sort of becomes “internal” so to speak, as you can only come in from the bastion with a key and passphrase.

[aborsy]

Yes. Thank you for expanding my answer :)

Even better, no open port anywhere is actually needed.

[indigodaddy]

I’m definitely not following you..

[gkrishna]

I find this very useful. I will setup a bastion. Thank you

[indigodaddy]

I have a BuyVM.net 3.50/mo KVM slice that has been idling for maybe a year (yeah I know I need to get on it..), so I can transfer that to you if you want. BuyVM has been around forever and they are awesome, but are almost always sold out (just checked and they are).

If you want to reply with your contact details I can see if I can get that going and you can take over the vps if you want..

Other options for providers:

- netcup.eu (I use them.. they don’t have small instances but they are super great prices for the sizes they offer)

- Hetzner Cloud (never used but heard great things and their prices are very low)

- OVHCloud (I have dedi servers from Kimsufi and SoYouStart which have been great— OVH is the parent company)

- prgmr.com - these guys have been around since the very beginning of vps hosting. They wrote the book (quite literally) on Xen ( https://www.amazon.com/Book-Xen-Practical-System-Administrat... )

- low $ NAT VPS options:

https://clients.inceptionhosting.com/cart.php?gid=13

https://hosting.gullo.me/pricing

- free ipv6-only vps (or $1/mo to add an ipv4):

https://www.euserv.com/en/virtual-private-server/root-vserve...

- An informative resource: https://lowendbox.com/blog/free-vps-providers/

[indigodaddy]

On your ssh bastion make sure to at the very least:

- have minimal services running, preferably only ssh

- if you have other services running then use iptables or a firewall frontend to block all incoming ports except for the ones you specifically need/want open

- disable root ssh login

- disable password login (eg use ssh keys and preferably with a passphrase too)

- you can also use something like fail2ban or denyhosts but it’s not really necessary if you’ve also done all the above

- yum or apt update it frequently

- For your ssh connection from the bastion to your AWS instance or any other important ssh destinations from the bastion, use a key with a passphrase for increased security (on the off chance your bastion gets compromised)

- Don’t do anything else too important on your ssh bastion.. eg don’t have any important stuff or work laying around on it or other services/applications running. Just use it as a jumphost only.

[tmottabr]

is there any way to just tunnel the ssh traffic trough the bastion but let the ssh authentication be done from my computer instead?

that way i would not need to keep the keys in the bastion server at all.

[indigodaddy]

Yes, it’s fairly trivial with ProxyCommand or ProxyJump switch:

https://www.redhat.com/sysadmin/ssh-proxy-bastion-proxyjump