Monday, April 21, 2025

How to Connect (ssh) into a instance with the Powershell & Command Prompt

Search for Powershell on the local machine

Or

Winds + R

Then run powershell

Then ok

Verify whether ssh is available on powershell

ssh 

Connect to the instance From the command prompt.

Winds + R

Then run cmd  

Then ok

Verify if ssh is available in command prompt.

From the command prompt:

ssh -i .\devsecopspat.pem ubuntu@18.191.xxx.197

Back to powershell:

Navigate to the directory of the key.pem:

cd ~/Downloads

List content of directory to Verify that the key.pem(devsecopspat35.pem) is present in the directory.

Make sure that port 22 is open on the ec2 instance (twtech-db-server)


 Enter the ssh  command on the powershell terminal

ssh -i "devsecopspat35.pem" ubuntu@ec2-18-191-xxx-197.us-east-2.compute.amazonaws.com

Or:

ssh -i .\devsecopspat.pem ubuntu@18.191.xxx.197

How twtech changes security permmisions form basic to full pemissions  on key.pem via UI

Got the directory with the key.pem.

Right-click on the key and naviage to properties


Go to the security tab to grant permission.

Then advance


Make sure the  owner of the file is owner of the local machine

Make changes to the permission


Type file owner name: devsecopspat35

Ok to save changes.

Remove SYSTEM administration, it does not need to have access to the key.pem

Disable inheritance: Then, Remove all inherited permissions from this object

Add inherited permissions.

Select a principal


Check principal name:



Give devsecopspat35 full control over the key.pem (devsecopspat.pem)

From:

To:

Verify that user (devsecopspat35) has full control of key.pem and ok.

Verify that only devsecopspat35 is the only person granted full security permission:



How twtech tests  the key.pem configured (devsecopspat.pem) ... ssh into server again from PowerShell

ssh -i .\devsecopspat.pem ubuntu@18.191.xxx.197

Test that users can also login from the command prompt after permission configuration to key.pem:

ssh -i .\devsecopspat.pem ubuntu@18.191.xxx.197

How twtech Troubleshoots ssh issues.

A, Having Connection timeout.

Security group issue. Any timeout (not just for SSH) is related to security groups or a firewall. Make sure the security group  has port 22 opened from anywhere. 

B,  Still having connection timeout issue

If your security group is properly configured as above, and you still have connection timeout issues. Make sure the corporate firewall or a personal firewall is not blocking the connection.

C,  SSH does not work on Windows

·        If ssh command says: ssh command not found, twtech-user has to use Putty tool to connect to server.    

   D,  Permission denied (publickey,gssapi-keyex,gssapi-with-mic)

This means either two things:

·       Wrong security key

·       Not using a security key.

·       Configure and assign the correct key.

·        Wrong user. Redhat-users  is ec2-user  and Ubuntu-user is ubuntu .

·   Wrong ssh command Format: ssh -i  .\key.pem user@<public-ip>

E,  Nothing seem to work.  Also try EC2 Instance Connect

Session is connected in the browser and not a terminal.

F,  twtech-user was Able to connect to server the last few hours, but  the same server won’t connect now.

·    A stopped EC2 instance  exits the publicIPaddress.  Reconfigure with the new publicIPaddress, if an elasticIP was not initially assigned to the instance.

·     Check if there is proper configuration for putty, because a stopped instance would also release its public-IPaddress to aws and should only connect with the current PubIP-address.

G, Gomtime, ssh from Anywhere-IPv4 and Anywhere-IPv6 work together.

   H, Connection refusal

It means the instance is reachable, but no SSH utility is not running on the instance

·        restart the server ( stop & start)

Stop the server completely for APIs to reset.

Start the server again.

I, Reach out to other engineers for help as well... Team Collaboration is always essential in any enterprise work environment.
Slack
   Atlassian Jira
Microsoft Teams
J, Use stack overflow site to post the issue, because someone might have experienced that same issue already in their environment. 
https://stackoverflow.com/questions

K, Terminate the instance, If it doesn't still work and create a new one.  

Insights.

Never ever enter the aws access keys to an instance in cloud, for several critical reasons:

1. Security Risk: Keys Can Be Stolen

If access keys are stored in plain text (e.g., environment variables, config files, or scripts on an EC2 instance), anyone with access to that instance can steal them — including:

  • Malicious insiders
  • Attackers exploiting a vulnerability
  • Malware injected via insecure software

These keys could then be used outside your environment to wreak havoc.

 2. Hard to Track & Rotate

Manually entered access keys:

  • Are difficult to audit and manage.
  • Rotation becomes a nightmare — if keys get leaked or need changing, you have to hunt down every instance manually.
  • This violates the principle of least privilege and automation.

3. Better Alternatives Exist: Use IAM Roles

Make sure to Install aws cli utility and version verified.

sudo snap install aws-cli --classic

aws --version

The best practice is to assign IAM roles to your compute instances (e.g., EC2, Lambda, ECS). Benefits:

  • Temporary credentials are securely issued by the Instance Metadata Service (IMDS).
  • No manual handling of keys.
  • Automatic rotation and fine-grained permissions.

# bash

curl http://169.254.169.254/latest/meta-data/iam/security-credentials/

 4. Violates Compliance and Policy Standards

Manually entering keys often violates:

  • Company security policies
  • Industry compliance standards (like SOC2, ISO 27001, HIPAA)
  • AWS Well-Architected Framework guidelines

 5. Risk of Accidental Exposure

Keys entered on instances are often:

  • Committed to Git repos by mistake
  • Logged in shell history or debug logs
  • Left lying around in user profiles

Once exposed — it's game over for your AWS account.

 twtch-users Do This Instead

  • Use IAM roles with least privilege attached to your EC2/Lambda/ECS.
  • Use AWS Systems Manager Parameter Store or Secrets Manager for sensitive data.
  • For local dev, use AWS CLI with aws configure and scoped permissions.

No comments:

Post a Comment

Kubernetes Clusters | Upstream Vs Downstream.

  The terms "upstream" and "downstream" in the context of Kubernetes clusters often refer to the direction of code fl...