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.
Related
I never used VPNs, I know what they are and how they work in general, but I never had to use one in practice; now I need to use it to connect to a machine in my university lab, my teacher provided the configuration file and the other needed files to set it up.
I installed the OpenVPN GUI with admin privileges, I imported the config file (".ovpn" file in my case) and launched (always as admin) the connection, which immediately works and I am assigned a new IP address. However, if I quickly check on "whatIsMyIP.com" or on Google, the IP is unchanged, it's still my original IP.
Now I also tried with other random VPNs downloaded from VPNBook, and they work, meaning that I can see that the IP changes as soon as I turn them on. I really cannot understand what I am doing wrong (my professor told me that he tried connecting through a VPN as well and it worked for him, so the problem must be on my client side)...
PLUS: when this problem of the unchanged IP is fixed, I am supposed to use ssh to connect to the remote machine. I was asked to generate a pair of public+private keys, passed the public to my teacher who added it on the machine and then connect through the command:
"ssh username#hostname"
Besides the fact that it does not work due to the VPN not changing the IP, I get the error "No address associated with hostname", so I understand it cannot resolve the given hostname, nonetheless my professor gave me only that: is it correct that I can ssh to the remote machine by only having the hostname or (as I believe) I also need the IP, which I can associate with the hostname and then connect?
I've created an instance of a server on EC2 based on an AMI generated from an existing server. All goes well during the create, and I specify the same key for the new server as the old. However, when I try to connect to the new server via putty, I get a "connection refused" message. Also, I'm unable to ping to the public address, although I selected the "default" group which allows ICMP. The server status is "running". Any ideas why I can't connect?
Note that an nmap probe gives this output:
PORT STATE SERVICE
22/tcp closed ssh
80/tcp closed http
2144/tcp closed unknown
10000/tcp closed snet-sensor-mgmt
I'm pretty sure this means that ssh isn't running, although the port is open. Any idea why it would be running on the system I did the AMI from, but not on the one the AMI was generated from? Shouldn't all the same services be starting?
It did turn out to be a security group/permissions issue. The default security group looks open, but actually shuts everything down, per this post:
https://serverfault.com/questions/245916/why-cant-i-ssh-or-ping-my-brand-new-amazon-ec2-instance
as you are taking the existing AMI you have to delete all the old entries from authenticated file except new entry.
because while the coping the AMI old entries are still present in new instance so once you will delete it you may able to login into the instance.
One Reason i found is entry in WLAN in current working network i.e. of my office. you may have restrictions.try contacting network admin.
alternatively you can try for adding entry to inbound rule of your current ip address.
I am using aws java sdk to launch EC2 instances (running Ubuntu 12.04) and run a distributed tool on them, the tool uses openMPI for message passing between the nodes and openMPI uses SSH to connect nodes with each other.
The problem is that the EC2 instances don't authenticate each other for SSH connections by default, this tutorial shows how to set up SSH by generating keys and adding them to nodes, However, when I tried to add the generated key to the slaves using the command
$ scp /home/mpiuser/.ssh/id_dsa.pub mpiuser#slave1:.ssh/authorized_keys
I still got permission denied. Also, after generating new keys, I was not able to log in using the ".pem" key that I got from amazon.
I am not experienced with SSH keys, but I would like to have some way of configuring each EC2 instance (when its firstly created) to authenticate the others, for example by coping a key into each of them. Is this possible and how It could be done?
P.S.: I can connect to each instance once it is launched and can execute any commands on them over SSH.
I found the solution, I added the amazon private key (.pem) in the image (AMI) that I use to create the EC2 instances and I changed the /etc/ssh/ssh_config file by adding a new identity file
IdentityFile /path/to/the/key/file
This made SSH recognize the .pem private key when it tries to connect to any other EC2 instance created with the same key.
I also changed StrictHostKeyChecking to no, which stopped the message "authenticity of host xxx can't be established" which requires users interaction to proceed with connecting to that host.
I get this error message when trying to connect with ssh.
Disconnected: No supported authentication methods available (server sent: publickey,gssapi-keyex,gssapi-with-mic)
I create a instances(cent os), generated my webserver.pem, puttygen imported that and output a ppk
I have seen that it may be a permissions issue with the ~/.ssh on the server but how can i change the permissions on the server without ssh access to the server? Is there another way to connect that i am not aware of? I am quite new to the amazon ec2 stuff.
I am on a windows system right now using putty.
My security groups were incorrect. I remade the instance with the correct security groups
The below steps worked for me.
Edit sshd_config file sudo vi /etc/ssh/sshd_config.
Search for PasswordAuthentication
If it is no, change it to yes. For me it was commented. If so, uncomment it.
Restart sshd service sudo systemctl restart sshd.service
Done.
These are the basic steps generally when working with a public cloud, trying to create a Virtual Machine and connect to it.
Create a Virtual Cloud Network/ Virtual Private Cloud
Create an Internet Gateway and ensure the Route Table for the VCN has the entry to route internet bound traffic (destination 0.0.0.0/0) to the internet gateway
Create a Virtual Machine (Linux in this case), ensure it has a public IP ( VM be created in public subnet ), download the key pair (for example was in PEM format)
Create a Security Group and ensure ingress rule from source : 0.0.0.0/0, protocol: TCP, destination port: 22
Associate the VM with the Security Group at VNIC level at the time of creating the VM or post creation.
From Oracle Cloud documentation -
Just having an internet gateway alone does not expose the instances in
the VCN's subnets directly to the internet. The following requirements
must also be met:
The internet gateway must be enabled (by default, the internet gateway
is enabled upon creation). The subnet must be public. The subnet
must have a route rule that directs traffic to the internet gateway.
The subnet must have security list rules that allow the traffic (and
each instance's firewall must allow the traffic). The instance must >
have a public IP address.
Now connecting to VM using putty, basically you are doing a :
ssh user#ip_address —i private_key
a. Use puttygen and load the private PEM key that you downloaded. Once successfully imported, save the private key (optionally with a passphrase) as PPK in your local machine ( for example "your_pvt_key_name.ppk" )
b. Use putty to connect to the VM's public IP. Ensure in putty when connecting to the VM that private key is provided for authentication. In the section Connection->SSH->Auth, browse for the "your_pvt_key_name.ppk" and then go back to the Session and "Open" the VM. If the VM is on public subnet with correct route table entry, you should see the login screen. In case the VM is not available on internet, it wont connect !
c. Once you see the login screen most important and which is the probable cause of the above error, login with correct user name, such as "ec2-user" in AWS or "opc" in OCI. Using an incorrect user name results in this error.
No supported authentication methods available (server sent: publickey,gssapi-keyex,gssapi-with-mic)
I was going to do rsync, but rsync over SSH needs to have the private key on the second EC2 instance. I'm concerned about copying my private SSH key to the server. That can't be safe, right?
Is there another possibility, e.g. somehow getting authentication via my computer? If it's only a little auth check at the beginning of each sync, I don't mind that.
Or can I securely sync files between EC2 instances without the private key?
Thanks for your input,
MrB
You needn't use your EC2 keys to setup SSH between the two EC2 instances. Look at this guide - http://ask-leo.com/how_can_i_automate_an_sftp_transfer_between_two_servers.html .
Simple outline of the process is, lets say you want to transfer files from Server1 to Server2. You basically create a new key for your user on Server1 (note this is different from the key you downloaded to access your EC2 instance - Server1 in this case). Then load up the public part in Server2's authorized_keys and you should be able to setup SSH.
If the user that the rsync process is going to run under is not your user, then you will have to setup SSH keys for the user that the process will run under.
HTH
Just create a snapshot of the volume you have your modified files contained and attach it your outdated instance after detaching the outdated volume.