# Setting up a bastion server to debug Instana agent
---
Some context first
---
- installed Instana agents on SFCC instances weren't running.
- agents installed in SFJC instances were running fine.
- SFCC & SFJC have similar architecture.
---
# WHYYYYY????
- isn't it working for SFCC...
---
# Let's SSH into the instance
- and find out
---
# Oh but they're behind VPC
___
- which means you can't connect to it without doing something that isn't the best practice
- whitelisting your IP address to the instance SG temporarily
- **NOT forgetting** to remove it after
---
- we've been also talking about configuring a bastion host as a bridge to access the instances behind VPC (good practice) for some time now
---
- motivated to do this NOW as a solution for the long run
---
documented in [Rocketeers wiki](https://rocketeers.atlassian.net/wiki/spaces/GREENPRODUCT/pages/700743936/How+To+SSH+into+SFCC+instances+via+a+Bastion+server)
![](https://i.imgur.com/zbFyoXt.png)
---
Resources
- https://vaughanj10.github.io/creating-a-bastion-host-for-aws/
- https://aws.amazon.com/blogs/security/securely-connect-to-linux-instances-running-in-a-private-amazon-vpc/
---
# So why was the Instana agent not running for SFCC again?
---
```
function start_agent() {
...
if [ "$INIT" = "systemd" ]; then
...start agent
else
log_warn "Instana agent automatic enable/startup by this script is only supported for systemd"
log_warn "Utilize your distribution's init system methods to enable/start the agent"
fi
}
```
---
After figuring that out, we just needed to change the startup script to
```
service instana-agent start
```
---
Disclaimer - Instana did mentioned this in their documentation somewhere
![](https://i.imgur.com/KYhwJO0.png)
---
{"metaMigratedAt":"2023-06-15T14:31:20.329Z","metaMigratedFrom":"YAML","title":"Bastion server","breaks":"true","description":"View the slide with \"Slide Mode\".","contributors":"[{\"id\":\"1871c7e5-a757-46f4-a3d5-742faff24553\",\"add\":4007,\"del\":2105}]"}