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
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
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.
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