I just created an instance in oracle cloud and I managed to connect to it by ssh but when completing the connection it asks me for a password and a user that I do not know, I have not set this protection at any time.
The default username for all compute instances is "opc", which is mentioned in the documentation. During instance creation you must either download the generated SSH private key or provide self-generated keys for upload to the new instance. If you don't download the private key from Oracle or upload your own public key, then there won't be any way to connect to the instance using SSH. There is no password option. This is stated explicitly in the "Add SSH Keys" section of the "Create Compute Instance" screen when creating the instance.
OCI Documentation: https://docs.oracle.com/en-us/iaas/Content/Compute/Tasks/launchinginstance.htm
You cannot provide a public key or save the key pair that is generated
by Oracle Cloud Infrastructure after the instance is created.
The following link describes various methods of creating SSH key pairs for use if you choose to create your own rather than download the ones provided by Oracle.
https://docs.oracle.com/en/learn/generate_ssh_keys/index.html#introduction
I am trying to connection to a MySQL server on Host X through machine Y over SSH.
The same setup (but older version of MySQL workbench) works on my another box (CentOS 6.3).
However, the same setup doesn't work on my CentOS 6.5.
I tried to use the SSH key for authentication between my box and machine Y over SSH, and it works when I ssh from my box to machine Y.
However, MySQL workbench gave me the following error:
ERROR Could not establish SSH connection: Bad authentication type (allowed_types=['publickey', 'gssapi-with-mic']).
Some people suggested that I set AllowTcpForwarding to yes in /etc/ssh/sshd_config, which I did, restarted the service and rebooted my machine.
But I still got the same error.
Any idea?
It seems like for some reason the .ssh/id_dsa key isn't picked up when MySQL workbench attemtps to connect.
Thanks in advance.
You need to ensure that your private key is in openssh format. With puttygen you can export as Openssh. This worked for me.
Converting it to OpenSSH solves the issue. Just do the following:
Open Putty Key Generator.
Load the private key by going to File - > Private Key from the location you saved the private key file in - you should see your key loaded in Putty.
Now go to conversations and export to Openssh - save the file in a safe location.
Go to Workbench and under SSH key file point it to the new Openssh file instead of the old private key file. this should solve your problem.
I've just come across this again recently. If you use a password protected private key and you just upgraded to macOS Sierra you probably need to re-add your private key to your keychain again.
ssh-add -K ~/.ssh/id_rsa
This instantly fixed the problem for me.
On Mac OS, do the following as this is the only thing work for me -:
Step 1
brew install putty
Step 2
puttygen id_rsa -O private-openssh -o id_rsa.pem
Step 3 - In MySQL workbench
SSH Key File: /Users/local/.ssh/id_rsa.pem
I had the same problem on macos with both Navicat and MySQL Workbench. Thanks to Jonathan on this article
figure my issue out. Macos users first need to install puttygen and then convert ppk format into pem by means of Jonathan said in his tutorial and then TADA! everything works like a charm!
for linux and generally for workbench it must to be in pkcs8 format intead of rfc...
so export in OpenSSH format but in pkcs8
For me, it worked using a .pem extension key.
As I only had the ppk key, I had to transform the .ppk into .gem.
To transform it, I used eating in the ubuntu terminal:
$ puttygen key.ppk -O private-openssh -o key.pem
For Linux users using ssh-keygen:
As per the other answers you need to use openssh format.
ssh-keygen -o -b 4096
That gives me a new keypair RSA type 4096 bits in openssh format. It's the -o that's key here (no pun intended).
Obviously this generates a new key so is only useful if you can upload the new public key to the server. Don't forget to back up your old keys first incase you use them elsewhere.
AFAIK ssh-keygen doesn't have the ability to convert an existing key.
Why Oracle have dropped support for the ubiquitous PEM format is beyond me.
I spent 3-4 days to figure out and tried many different solution but none of them worked for me except following.
I was on Windows and using XAMPP to run MySQL and localhost. I stopped both services on my machine and then tried to connect SSL connection using Workbench and its connected.
I try to create an app in Openshift but alwas get the following error during the process:
**Cloning into 'firstapp'...
The authenticity of host 'firstapp-**.rhcloud.com (***)' can't b
e established.
RSA key fingerprint is **********************.**
I used rhc setup to create the ssh keys and they were succesfully transfered into my Openshift account. Did I miss something or did something wrong?
When I create an app, this is the relevant snippet I get:
Cloning into 'tsunade23'...
The authenticity of host 'tsunade23-*.rhcloud.com (a.b.c.d)' can't be established.
RSA key fingerprint is *:*:::::*:*.
No matching host key fingerprint found in DNS.
Are you sure you want to continue connecting (yes/no)?
So, are you seeing the last 2 lines from my snippet when you create the app? If yes, just type 'yes' and you should be good to go.
Let me know if this isn't the case.
After creating the instance, I can login using gcutil or ssh. I tried copy/paste from the ssh link listed at the bottom of the instance and get the same error message.
The permission denied error probably indicates that SSH private key authentication has failed. Assuming that you're using an image derived from the Debian or Centos images recommended by gcutil, it's likely one of the following:
You don't have any ssh keys loaded into your ssh keychain, and you haven't specified a private ssh key with the -i option.
None of your ssh keys match the entries in .ssh/authorized_keys for the account you're attempting to log in to.
You're attempting to log into an account that doesn't exist on the machine, or attempting to log in as root. (The default images disable direct root login – most ssh brute-force attacks are against root or other well-known accounts with weak passwords.)
How to determine what accounts and keys are on the instance:
There's a script that runs every minute on the standard Compute Engine Centos and Debian images which fetches the 'sshKeys' metadata entry from the metadata server, and creates accounts (with sudoers access) as necessary. This script expects entries of the form "account:\n" in the sshKeys metadata, and can put several entries into authorized_keys for a single account. (or create multiple accounts if desired)
In recent versions of the image, this script sends its output to the serial port via syslog, as well as to the local logs on the machine. You can read the last 1MB of serial port output via gcutil getserialportoutput, which can be handy when the machine isn't responding via SSH.
How gcutil ssh works:
gcutil ssh does the following:
Looks for a key in $HOME/.ssh/google_compute_engine, and calls ssh-keygen to create one if not present.
Checks the current contents of the project metadata entry for sshKeys for an entry that looks like ${USER}:$(cat $HOME/.ssh/google_compute_engine.pub)
If no such entry exists, adds that entry to the project metadata, and waits for up to 5 minutes for the metadata change to propagate and for the script inside the VM to notice the new entry and create the new account.
Once the new entry is in place, (or immediately, if the user:key was already present) gcutil ssh invokes ssh with a few command-line arguments to connect to the VM.
A few ways this could break down, and what you might be able to do to fix them:
If you've removed or modified the scripts that read sshKeys, the console and command line tool won't realize that modifying sshKeys doesn't work, and a lot of the automatic magic above can get broken.
If you're trying to use raw ssh, it may not find your .ssh/google_compute_engine key. You can fix this by using gcutil ssh, or by copying your ssh public key (ends in .pub) and adding to the sshKeys entry for the project or instance in the console. (You'll also need to put in a username, probably the same as your local-machine account name.)
If you've never used gcutil ssh, you probably don't have a .ssh/google_compute_engine.pub file. You can either use ssh-keygen to create a new SSH public/private keypair and add it to sshKeys, as above, or use gcutil ssh to create them and manage sshKeys.
If you're mostly using the console, it's possible that the account name in the sshKeys entry doesn't match your local username, you may need to supply the -l argument to SSH.
Ensure that the permissions on your home directory and on the home directory of the user on the host you're connecting to are set to 700 ( owning user rwx only to prevent others seeing the .ssh subdirectory ).
Then ensure that the ~/.ssh directory is also 700 ( user rwx ) and that the authorized_keys is 600 ( user rw ) .
Private keys in your ~/.ssh directory should be 600 or 400 ( user rw or user r )
I was facing this issue for long time. Finally it was issue of ssh-add. Git ssh credentials were not taken into consideration.
Check following command might work for you:
ssh-add
I had the same problem and for some reason The sshKeys was not syncing up with my user on the instance.
I created another user by adding --ssh_user=anotheruser to gcutil command.
The gcutil looked like this
gcutil --service_version="v1" --project="project" --ssh_user=anotheruser ssh --zone="us-central1-a" "inst1"
I just experienced a similar message [ mine was "Permission denied (publickey)"] after connecting to a compute engine VM which I just created. After reading this post, I decided to try it again.
That time it worked. So i see 3 possible reasons for it working the second time,
connecting the second time resolves the problem (after the ssh key was created the first time), or
perhaps trying to connect to a compute engine immediately after it was created could also cause a problem which resolves itself after a while, or
merely reading this post resolves the problem
I suspect the last is unlikely :)
I found this error while connecting ec2 instance with ssh.
and it comes if i write wrong user name.
eg. for ubuntu I need to use ubuntu as user name
and for others I need to use ec2-user.
You haven't accepted an answer, so here's what worked for me in PuTTY:
Without allowing username changes, i got this question's subject as error on the gateway machine.
You need to follow this instructions
https://cloud.google.com/compute/docs/instances/connecting-to-instance#generatesshkeypair
If get "Permission denied (publickey)." with the follow command
ssh -i ~/.ssh/my-ssh-key [USERNAME]#[IP_ADDRESS]
you need to modify the /etc/ssh/sshd_config file and add the line
AllowUsers [USERNAME]
Then restart the ssh service with
service ssh restart
if you get the message "Could not load host key: /etc/ssh/ssh_host_ed25519_key" execute:
ssh-keygen -A
and finally restart the ssh service again.
service ssh restart
I followed everything from here:
https://cloud.google.com/compute/docs/instances/connecting-to-instance#generatesshkeypair
But still there was an error and SSH keys in my instance metadata wasn't getting recognized.
Solution: Check if your ssh key has any new-line. When I copied my public key using cat, it added into-lines into the key, thus breaking the key. Had to manually check any line-breaks and correct it.
The trick here is to use the -C (comment) parameter to specify your GCE userid. It looks like Google introduced this change last in 2018.
If the Google user who owns the GCE instance is myname#gmail.com (which you will use as your login userid), then generate the key pair with (for example)
ssh-keygen -b521 -t ecdsa -C myname -f mykeypair
When you paste mykeypair.pub into the instance's public key list, you should see "myname" appear as the userid of the key.
Setting this up will let you use ssh, scp, etc from your command line.
Add ssh public key to Google cloud
cat ~/.ssh/id_rsa.pub
go and click your VM instances
edit VM instances
add ssh public key(from id_rsa.pub) in SSH keys area
ssh login from Git bash on your computer
ssh -i ~/.ssh/id_rsa tiennt#x.y.z.120
I have a BB (BitBucket) account for work and a BB account for my self and want to be able to access them both from one PC using TortoiseHg with SSH.
When you add the two keys to Pageant and then try to push to a repo that uses one of the accounts Pageant will pass the first SSH to BB and if it's a BB account SSH BB will accept it log the user in with the account related to that SSH key.
Now if that first SSH key is for the account that has access to the repo that's fine BUT IF that first SSH key was for the other account you will get an authorisation error.
There seems no way to pass the correct key to BB using TortoiseHg at all. And therefore I am constantly swapping SSH out of Pageant which clearly isn't ideal and I might as well drop SSH and use passwords. :(
Does anyone know of a way to get TortoiseHg to pass the correct SSH for that account?
As I was writing this question I happened to come across a solution! Now the reason I hadn't come across it before is it was for Git not Mecurial so I think that it's still worth posting this question and this solution to allow others in the same boat to easily find the solution. :)
The solution was from here: https://answers.atlassian.com/questions/150285/only-the-top-listed-private-key-in-pageant-is-used-offered-by-git-sourcetree-tortoisegit
Here is the important part:
One way to resolve this is to perform the same configuration in PuTTY
too to disambiguate what key to send (and therefore which user to
authenticate as).
Start PuTTY (download it from putty.org if you don't have it)
Type 'bitbucket.org' in the host name field
Go to Connection > SSH > Auth in the tree
Specify the key to use for the BB user
Go back to 'Session' in the tree
Type an alias name underneath 'Saved Sessions' (e.g. bb-user1) and Save
Repeat 2-6 for each BB user and save as a different session name
Then in your remote URLs, replace 'bitbucket.org' with the session
name (e.g. bb-user1) to disambiguate what SSH key to send first. This
is identical to using IdentityFile in OpenSSH.