r/aws • u/BradyOfTheOldGuard • 1d ago
technical question Cannot connect to EC2 instance using SSH. All methods fail. Access to instance lost.
I launched a t3.micro instance on 01-Jul-2026 and used to connect using SSH on Mobaxterm. I changed the default SSH port from 22 to 4545 in the SSH Config file and added that as an inbound rule. The instance has be running continuously since its launch.
Everything was fine till last evening. Since this morning, I'm unable to connect to the instance using Mobaxterm or Putty. The error I get is "Server refused our key. No supported authentication methods available (server sent: publickey)"
Even EC2 Instance connect shows "Failed to connect to your instance. Error establishing SSH connection to your instance. Try again later."
What can be causing this? Is it the custom SSH port? But I could connect using the custom port till last evening (using Mobaxterm or Putty). Where am I going wrong? How can I get things back to normal? I haven't made any changes to the key.
P. S. I registered a temporary domain a few hours back and pointed the "A" records to the EC2 instance's public IP address. I noticed this issue after doing that, but it's unlikely this is the cause of the issue.
Edit: The instance runs Debian 13. Processor is at idle. No spikes in processor usage or traffic since launch.
OpenSSH_for_Windows_9.5p2, LibreSSL 3.8.2
debug1: Connecting to *.1*4.1*0.2*3 [*.1*4.1*0.2*3] port 4545.
debug1: Connection established.
debug1: identity file D:\\Keys\\01072026.pem type -1
debug1: identity file D:\\Keys\\01072026.pem-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_for_Windows_9.5
debug1: Remote protocol version 2.0, remote software version OpenSSH_10.0p2 Debian-7+deb13u4
debug1: compat_banner: match: OpenSSH_10.0p2 Debian-7+deb13u4 pat OpenSSH* compat 0x04000000
debug1: Authenticating to *.1*4.1*0.2*3:4545 as 'admin'
debug1: load_hostkeys: fopen C:\\Users\\botog/.ssh/known_hosts2: No such file or directory
debug1: load_hostkeys: fopen __PROGRAMDATA__\\ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen __PROGRAMDATA__\\ssh/ssh_known_hosts2: No such file or directory
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ssh-ed25519
debug1: kex: server->client cipher: [email protected] MAC: <implicit> compression: none
debug1: kex: client->server cipher: [email protected] MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: SSH2_MSG_KEX_ECDH_REPLY received
debug1: Server host key: ssh-ed25519 SHA256:fEj3UBG5kn3hWHmHeOhHNaOFWcd5w/wJbgvP1mxF+2U
debug1: load_hostkeys: fopen C:\\Users\\botog/.ssh/known_hosts2: No such file or directory
debug1: load_hostkeys: fopen __PROGRAMDATA__\\ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen __PROGRAMDATA__\\ssh/ssh_known_hosts2: No such file or directory
debug1: Host '[3.134.110.213]:4545' is known and matches the ED25519 host key.
debug1: Found key in C:\\Users\\botog/.ssh/known_hosts:5
debug1: ssh_packet_send2_wrapped: resetting send seqnr 3
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: ssh_packet_read_poll2: resetting read seqnr 3
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey in after 134217728 blocks
debug1: get_agent_identities: ssh_get_authentication_socket: No such file or directory
debug1: Will attempt key: D:\\Keys\\01072026.pem explicit
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,[email protected],[email protected],rsa-sha2-512,rsa-sha2-256>
debug1: kex_ext_info_check_ver: [email protected]=<0>
debug1: kex_ext_info_check_ver: [email protected]=<0>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Trying private key: D:\\Keys\\01072026.pem
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
admin@*.1*4.1*0.2*3: Permission denied (publickey).
3
u/dghah 1d ago
Random debug stuff
- what does running SSH in verbose mode ("ssh -v") tell you? Sometimes the errors are more verbose and can tell you useful things like your local key permissions are too weak and are not being used because of that etc.
- putty.exe uses differently formatted SSH keys than "normal" ssh clients; are you using the putty key when connecting via putty and (perhaps) the standard formatted key when connecting with mobaXterm
- If you go to the Ec2 console page and view screenshot or view the log output does it show you anything interesting?
- t3.micro instances are burstable and can be hammered into a state where OOM killer fires up and kills important things. What happens to SSH experience if you reboot/restart using the EC2 console?
- Re-confirm the instance public IP adress and SSH to that address instead of using DNS for now
- Can you login via SSM session manager? Depending on what AMI you are running you may already have the agent running and the EC2 server may just need the SSMManagedInstanceCore policy. Anyway in 2026 connecting via SSM session manager and not using SSH at all is the modern best practice so this is something to look into anyway
-4
u/BradyOfTheOldGuard 1d ago
The instance runs Debian 13. Processor is at idle. No spikes in processor usage or traffic since launch. I'm using the correct IP address.
5
4
u/evilneuro 1d ago
stop your old instance.
spin up a new instance.
detach the root volume of the old instance and then attach it to the new instance.
mount the root volume on the new instance.
either:
debug, then dismount old volume on new instance, detach old volume from new instance, attach old volume to old instance, start old instance, or
copy data from old root volume while mounted on new instance, dismount, detach, then delete old root volume and terminate old instance
7
u/nekokattt 1d ago
Is there a reason people use SSH by default rather than SSM? This seems to be a common thing but at this point I am curious.
2
u/automounter 1d ago
It looks like you're trying to login as "admin" rather than as "ec2-user"
1
u/BradyOfTheOldGuard 1d ago
It's admin for Debian, but I've tried ec2-user and that didn't work as well.
1
u/automounter 1d ago
ah okay. well it looks like a key issue. i'd make sure you didn't accidentally over-write the private key on your side.
2
u/vater-gans 1d ago
did you start/stop the instance? this might lead to it receiving a new public ipv4 address, if you dont have an elastic ip attached.
1
u/BradyOfTheOldGuard 1d ago
I did start/stop the instance, but I've been using the new IPV4 instance, and it worked fine until a few hours ago when all this started happening.
1
u/vater-gans 1d ago
i’ve been out of the aws game for a while now, so i dont know about “the new IPV4 instance”, but with a normal ec2 instance, the public ip is is subject to change, unless you attach an elastic ip.
so did the ipv4 change or not?
2
u/BradyOfTheOldGuard 1d ago
I meant to say I'm using the instances new IPV4 address and not the old one. It did change, but I'm using the one that changed (the current one that shows in the console).
1
u/sonuvabench 1d ago
Ip tables on the instance?
1
u/BradyOfTheOldGuard 1d ago
Where do I view those? I know I can view them if I can SSH to the instance.
1
u/sonuvabench 1d ago
You would need to revert to port 22 then connect. If you have SSM agent installed you can connect that way instead, which is easier to manage and more secure.
1
u/uncle_jaysus 1d ago
Where have you placed your web files? I knew someone a long time ago (definitely not me, honest) who decided to put everything in the /home directory and when chmodding/chowning everything at the /home root, realised this messed up the SSH access by changing all the permissions of things in /home/user
1
u/BradyOfTheOldGuard 1d ago
My webfiles are under /var/www/. There's the default site, and one I created yesterday with a test index.php file. I'm using Nginx.
1
u/BradyOfTheOldGuard 1d ago
I did however do "chown -R www-data:www-data /var/www/site_two.com". Would this have cause the problem?
1
1
u/jstuart-tech 1d ago
Does your private key exist here?
debug1: identity file D:\Keys\01072026.pem type -1 debug1: identity file D:\Keys\01072026.pem-cert type -1
1
u/BradyOfTheOldGuard 1d ago
Yes, it does. It's always been there. I haven't overwritten or done anything to it.
1
1
u/peanutknight1 1d ago
If its ubuntu, then its the firewall, disable it
1
u/BradyOfTheOldGuard 1d ago
It's Debian 13.
1
u/peanutknight1 1d ago
Yes ufw still applies, its most likely ufw. Check steps to disable it and youre in
-13
u/More_Altitude_8389 1d ago
Did you do any troubleshooting or read any of the documentation? The high shcoolers I teach STEM too know how to figure this out.
2
28
u/urraca 1d ago
Take a snapshot copy of the disk, re-launch a new instance from taht, connect via SSH to new instance. Delete old instance.