To access a bastion server via PuTTY, we need the public IP, private key, and username. In the case of a private instance, we do not have a public IP, so the process is different. I have a private instance named amazon_server, which has a private IP for local connections (e.g., connecting to the bastion server). I also have a private key in PEM format with the .key extension stored on my local machine, and a default username, which is opc. Let’s proceed step by step to log in.

Step 1 - Importing Key

I need to import the private key inside my bastion server, the private key which is required must have .pem extension, the file permission must have restrictive access (allow only read access to only user) othewise OpenSSH will reject the key.

1. I am the admin of this OCI tenancy so I prefer to store my keys inside my /root directory for that I need to switch to root user and create /keys directory inside /root directory

2. Create a file private_key.pem inside /keys directory and write all contents of actual private key inside this file using vi

3. Change file permission to read only for user, and group and others not have access to this file

Step 2 - Check Login Permission

Before trying to login first I need to check the Security List for Private Subnet which should allow incoming SSH remote login request sent using TCP protocol on Port 22 of amazon_server from bastion_server-01.

In OCI, I have allowed incoming SSH remote login requests sent using the TCP protocol on Port 22 of amazon_server from bastion_server-01. We can also check using telnet 10.0.1.52 22.

Step 3 - Run Log In Command

Next, I will run the following command to log in:

ssh -i <private-key-path> <default-user>@<private-instance-private-ip>

ssh: SSH Program

-i: Identity Flag

<private-key-path>: Identity File Path

<default-user>: Remote Username

<private-instance-private-ip>: Target IP

We know that SSH is a much more secure version of Telnet. In the above snapshot, the prompt we see is SSH’s defense mechanism against Man‑in‑the‑Middle attacks. It indicates that this machine has never connected to the server with the private IP 10.0.1.52 before, so it has no saved record of its identity. When connecting for the first time, every SSH server generates a unique fingerprint, which is essentially a SHA‑256 cryptographic hash that defines the server’s public identity. Next time this prompt does not appear, since the fingerprint has already been saved and verified, let's test this:

This time, when I log in again, I do not get any prompt that I received earlier.