a few days ago I rebooted my Oracle Instance. Since then, I am not able to connect to it with SSH. I can't even ping it.
I then thought about connecting over the Cloud Shell, but there I am asked the username, which is the default "ubuntu", and also a password. But I have never set a password.
Has anyone any idea how I can access my instance?
I had the same problem after installing the firewalld.service. I rebooted the instance and then i was locked out!
I solved it by following this guide. I attached the boot volume to a second instance, mounted it, I removed the firewalld.service from the mounted boot volume, reattached it to my original instance and then i was able to access the server. Hope it will help with your problem.
Related
I have a website that is running in Oracle Cloud, the website now is down and I tried to access using SSH in Putty but it cannot be accessed I only see the terminal screen.
What should I do?
Could you please check if the instance is running or not. If the instance is running please check for the ingress/egress firewall rules at security list/NSG/OS firewall for connectivity to the instance. Make sure you are not connected to any VPN or any corporate network. Once you are able to connect to the instance check for the status of the service. It should be Active.
Could you please confirm, were you able to connect to the instance before? Since when you are facing this issue?
For your reference: connecting to your instance.
I'm trying to see if there's anything I can do to re-gain access to my vm instance via SSH. I had access before, I was creating an ssh tunnel to another server and realized I used the wrong one. I killed ssh via 'pkill sshd' and figured I would be able to regain access after a minute however now I'm unable to at all. I just get connection refused, error 255. Is there any way to send a command to the vm instance to have it restart sshd?
Thanks!
Try using the serial console. Alternately, try rebooting the VM, there's a chance SSH will come up without an error if you give it another shot.
While trying to solve another issue with connection problems to our servers, I thought to solve the problem by setting the MaxConnections and MaxStartups to my sshd.conf
When restarting ssh everything seemed fine, but this morning I found out that our Jenkins server didn't connect to any of the dev servers. So I tried logging into the system, finding out that I cannot log in to any of our dev servers anymore.
Looks like I made a F##$up in the sshd.conf and created a lockout for all the dev servers.
When trying to login I get an "port 22: Connection refused" error.
Is there any other way to get into the systems without having to connect every disk to another server to adjust the sshd.conf??
There are several options available for recovery in this situation:
Use the interactive serial console. This requires advanced preparation.
Add a startup script to fix the file, and then reboot to trigger the script.
Shutdown the instance, attach the disk to a recovery instance, use the recovery instance to mount the disk and fix the file, then detatch the disk and recreate the instance using the fixed disk. (you can also do this from a snapshot for added safety).
I'm trying to clone an EC2 instance so that I can test some things. I created an AMI and launched an instance and it seems to be running ok. However, I cannot connect to it with ssh or putty.
My live instance, which I'm making the copy of, has various users who can all log in happily with their private key. But they cannot log in with the exact same credentials to the cloned instance. I just get:
Disconnected: No supported authentication methods available (server sent: publickey)
Is there more to do than to just change the IP address from the live instance to the cloned instance?
I also cannot connect to the ec2-user login, using the private key I created during launch. One slight quirk of my live server is that I had to change the AuthorizedKeysFile setting in /etc/ssh/sshd_config in order to deal with some SFTP problems I was having. Is this likely to have messed up the connection for a cloned server? Surely all the settings are identical?
The answer was to do with the AuthorizedKeysFile setting after all. I undid the edit I made in /etc/ssh/sshd_config, took another snapshot, made another AMI, launched another instance and all was well. I didn't even need to restart the sshd service, so this didn't mess up my configuration on my live server.
I'm not entirely sure why this caused a problem, but the lesson here is that EC2 needs the AuthorizedKeysFile to be set to the default location or I guess it doesn't know where to look for the public key.
I have a google compute engine VM, running ubuntu, and utilising Laravel Forge.
I seem to get blocked by the VM after accessing SSH a few times (2-4), even if I'm logging in correctly. Restarting the VM unblocks me.
I first noticed the issue as I was having trouble logging into SSH, after a few attempts it would become unreachable. My website hosted on it also wouldn't resolve. After restarting the vm, I could try log into ssh again and my website works. This happened a couple time before I figured out how to correctly log in with SSH.
Next, trying to log in to the database with HeidiSQL, which uses plink, I log in fine. But it seems to keep reconnecting via SSH every time I do something, and after 2-4 of these reconnects, I get the same problem with the VM being unreachable by SSH and my website hosted on it being down.
Using SQLyog, which seems to maintain the one SSH connection, rather than constantly reconnecting like HeidiSQL, I have no problems.
When my website is down, I use those "down for everyone or just me" websites to see if it is down, and apparently it's just down for me, so I must be getting blocked.
So I guess my questions are:
1. Is this normal?
2. Can I unblock myself without restarting the VM?
3. Can I make blocking occur in a less strict way?
4. Why does HeidiSQL keep reconnecting via SSH rather than maintaining the one connection like SQLyog seems to?
You have encountered sshguard, which is enabled by default on the GCE Ubuntu images (at least on the 14.10 image, where I encountered it myself). There is a whitelist file at /etc/sshguard/whitelist.
The sshguard default configuration on my VM has a "dangerousness" threshold of 40. Most "attacks" that sshguard detects incur dangerousness of 10, so getting blocked after 4 reconnects sounds about right.
The attack signatures are listed here: http://www.sshguard.net/docs/reference/attack-signatures/
I would bet that you are connecting from an IP that has an invalid reverse DNS configuration (I was). Four connects like that and the default config blocks you for 20 minutes.