I am using rhc cli tool for OpenShift projects. I have encountered a problem with default rhc ssh key.
On any ssh related action (setup, app-create, etc..) rhc creates ~/.ssh/id_rsa key if it does not exist. I do not like that behaviour, and I would like it to use something like ~/.ssh/OpenShift-SSH-Keys/my_id_rsa.
Because during rhc setup, it did not ask me from which location I wanted to load the keys. Thus I also looked in ~/.openshift/express.conf and I only saw the configurations for ssl; not ssh.
So I found on the internet this following configuration line to add to ~/.openshift/express.conf:
ssh_key_file='~/.ssh/OpenShift-SSH-Keys/my_id_rsa'
I added it and also modified my ~/.ssh/config file:
# Openshift *.rhcloud.com ssh-key config
Host *.rhcloud.com
IdentityFile ~/.ssh/OpenShift-SSH-Keys/my_id_rsa
IdentitiesOnly yes
VerifyHostKeyDNS yes
StrictHostKeyChecking no
PasswordAuthentication no
UserKnownHostsFile ~/.ssh/known_hosts
To finish I setup my account like that:
rhc setup --config ~/.openshift/express.conf -l myusername#gmail.com
Output of this command line:
OpenShift Client Tools (RHC) Setup Wizard
This wizard will help you upload your SSH keys, set your application namespace, and check that other programs like Git are
properly installed.
If you have your own OpenShift server, you can specify it now. Just hit enter to use the server for OpenShift Online:
openshift.redhat.com.
Enter the server hostname: |openshift.redhat.com|
You can add more servers later using 'rhc server'.
Using myusername#gmail.com to login to openshift.redhat.com
RSA 1024 bit CA certificates are loaded due to old openssl compatibility
Password: ************************
OpenShift can create and store a token on disk which allows to you to access the server without using your password. The
key is stored in your home directory and should be kept secret. You can delete the key at any time by running 'rhc
logout'.
Generate a token now? (yes|no) yes
Generating an authorization token for this client ... RSA 1024 bit CA certificates are loaded due to old openssl compatibility
lasts 29 days
Saving configuration to /Users/theuser/.openshift/express.conf ... done
No SSH keys were found. We will generate a pair of keys for you.
Created: /Users/theuser/.ssh/id_rsa.pub
Your public SSH key must be uploaded to the OpenShift server to access code. Upload now? (yes|no) no
You can upload your public SSH key at a later time using the 'rhc sshkey' command
Checking for git ... found git version 2.5.0
Checking common problems .. done
Checking for a domain ... mydomainz1955
Checking for applications ... found 1
myapp http://myapp-mydomainz1955.rhcloud.com/
You are using 2 of 3 total gears
The following gear sizes are available to you: small
Your client tools are now configured.
As you can see in the output of the command line: No SSH keys were found. We will generate a pair of keys for you., although I specified in the ~/.openshift/express.conf that I already had ssh keys generated, rhc setup did not take them in consideration or did not find them.
So according to you guys, is it possible to somehow specify a different location for ssh keys loading during rhc setup?
Note: I know how to add additional ssh key, but I would like to stop rhc creating/using ~/.ssh/id_rsa
As far as I see you just want rhc to not use your default ssh key. So here is how you create a separate key and configure rhc to use it instead of the default one.
Key points are that:
you select no to generating and uploading ssh key during rhc
setup
you add your key separately with rhc sshkey add
you configure ssh to use the different key for that domain as you
list in your original example
Does this cover your concerns?
[crackit#koTapaH ~]$ mkdir /home/crackit/my_key_location
[crackit#koTapaH ~]$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/crackit/.ssh/id_rsa): /home/crackit/my_key_location/key.rsa
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/crackit/my_key_location/key.rsa.
Your public key has been saved in /home/crackit/my_key_location/key.rsa.pub.
The key fingerprint is:
c5:20:15:fb:17:96:86:8f:88:28:18:17:2a:b8:eb:51 crackit#koTapaH
The key's randomart image is:
+--[ RSA 2048]----+
| . ..+. |
|.. . . + . . |
|= . . + = |
|.= . . + = . |
|o .E. . S o o |
| ... . |
|.. |
|. . |
| . |
+-----------------+
[crackit#koTapaH ~]$ rhc setup
OpenShift Client Tools (RHC) Setup Wizard
This wizard will help you upload your SSH keys, set your application namespace,
and check that other programs like Git are properly installed.
If you have your own OpenShift server, you can specify it now. Just hit enter to
use the server for OpenShift Online: openshift.redhat.com.
Enter the server hostname: |openshift.redhat.com|
You can add more servers later using 'rhc server'.
Login to openshift.redhat.com:
Login to openshift.redhat.com: asdfgg#example.com
Password: *************
OpenShift can create and store a token on disk which allows to you to access the
server without using your password. The key is stored in your home directory and
should be kept secret. You can delete the key at any time by running 'rhc
logout'.
Generate a token now? (yes|no) yes
Generating an authorization token for this client ... lasts about 1 month
Saving configuration to /home/crackit/.openshift/express.conf ... done
No SSH keys were found. We will generate a pair of keys for you.
Created: /home/crackit/.ssh/id_rsa.pub
Your public SSH key must be uploaded to the OpenShift server to access code.
Upload now? (yes|no)
no
You can upload your public SSH key at a later time using the 'rhc sshkey'
command
Checking for git ... found git version 2.1.0
Checking common problems .. done
Checking for a domain ... foobar
Checking for applications ... found 2
jenkins http://jenkins-foobar.rhcloud.com/
tmp http://tmp-foobar.rhcloud.com/
You are using 2 of 3 total gears
The following gear sizes are available to you: small, medium
Your client tools are now configured.
[crackit#koTapaH ~]$ rhc sshkey add mykey my_key_location/key.rsa.pub
RESULT:
SSH key my_key_location/key.rsa.pub has been added as 'mykey'
[crackit#koTapaH ~]$ vi .ssh/config
<.. do your modifications here ..>
[crackit#koTapaH ~]$ rhc ssh tmp
Connecting to 550000a0e0b8cdca4c000040#tmp-foobar.rhcloud.com ...
*********************************************************************
You are accessing a service that is for use only by authorized users.
If you do not have authorization, discontinue use at once.
Any use of the services is subject to the applicable terms of the
agreement which can be found at:
https://www.openshift.com/legal
*********************************************************************
Welcome to OpenShift shell
This shell will assist you in managing OpenShift applications.
!!! IMPORTANT !!! IMPORTANT !!! IMPORTANT !!!
Shell access is quite powerful and it is possible for you to
accidentally damage your application. Proceed with care!
If worse comes to worst, destroy your application with "rhc app delete"
and recreate it
!!! IMPORTANT !!! IMPORTANT !!! IMPORTANT !!!
Type "help" for more info.
[tmp-foobar.rhcloud.com 550000a0e0b8cdca4c000040]\> exit
exit
Connection to tmp-foobar.rhcloud.com closed.
[crackit#koTapaH ~]$
Update: I didn't notice keys are generated. But I am sure that the generated keys during rhc setup are not actually used. First because the keys from default location are never added to openshift. And you can see a quick proof below. Another way to see is rhc sshkeys list.
Another thing is that if you already have keys in default location, then no keys are generated (in which case you still select no to not upload them). But it is actually a minor bug IMO in rhc that ssh keys are generated without asking the user. It might be a very rare use case - you don't have default key and you want to use a key from non-standard location (this is not your use case where you have a key in standard location, just don't want to use it) but still IMO one shouldn't generate something user did not request. So here's how I show you that only my desired custom key is used:
[crackit#koTapaH ~]$ rm -rf .ssh/id_rsa*
[crackit#koTapaH ~]$ rhc ssh tmp
Connecting to 550000a0e0b8cdca4c000040#tmp-foobar.rhcloud.com ...
<...>
Type "help" for more info.
[tmp-foobar.rhcloud.com 550000a0e0b8cdca4c000040]\> exit
exit
Connection to tmp-foobar.rhcloud.com closed.
[crackit#koTapaH ~]$ ls .ssh/
config known_hosts
[crackit#koTapaH ~]$
Update 2 Of course token cannot help you with ssh:
[crackit#koTapaH ~]$ rm -rf my_key_location
[crackit#koTapaH ~]$ rhc ssh tmp
Connecting to 550000a0e0b8cdca4c000040#tmp-foobar.rhcloud.com ...
no such identity: /home/crackit/my_key_location/key.rsa: No such file or directory
Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
SSH key is used for ssh. Token is used for API requests. These are different use cases. rhc uses the ssh executable underneath so using a custom key means to edit ~/.ssh/config to set your default key to another location or set different keys for different hosts. This is not handled well by rhc setup. But once you have your key set, you don't have to run rhc setup anymore.
Related
After following instructions both online and in a couple of books, I am unsure of why this is happening. I have a feeling there is a missing setting, but here is the setup:
I am attempting to use the command:
ansible all -u $USER -m ping -vvvv
Obviously using the -vvvv for debugging, but not much output aside from the fact it says it's attempting to connect. I get the following error:
S4 | FAILED => FAILED: Authentication failed.
S4 stands for switch 4, a Cisco switch I am attempting to automate configuration and show commands on. I know 100% the password I set in the host_vars file is correct, as it works when I use it from a standard SSH client.
Here are my non-default config settings in the ansible.cfg file:
[defaults]
transport=paramiko
hostfile = ./myhosts
host_key_checking=False
timeout = 5
My myhosts file:
[cisco-switches]
S4
And my host_vars file for S4:
ansible_ssh_host: 192.168.1.12
ansible_ssh_pass: password
My current version is 1.9.1, running on a Centos VM. I do have an ACL applied on the management interface of the switch, but it allows remote connections from this particular IP.
Please advise.
Since you are using ansible to automate commands in a Cisco switch, I guess you want to perform the SSH connection to the switch without been prompted for password or been requested to press [Y/N] to confirm the connection.
To do that I recommend to configure the Cisco IOS SSH Server on the switch to perform RSA-Based user authentication.
First of all you need to generate RSA key pair on your Linux box:
ssh-keygen -t rsa -b 1024
Note: You can use 2048 instead 1024 but consider that some IOS versions will accept maximum 254 characters for ssh public key.
At switch side:
conf t
ip ssh pubkey-chain
username test
key-string
Copy the entire public key as appears in the cat id_rsa.pub
including the ssh-rsa and username#hostname.
Please note that some IOS versions will accept
maximum 254 characters.
You can paste multiple lines.
exit
exit
If you need that 'test' user can execute privileged IOS commands:
username test privilege 15 secret _TEXT_CLEAR_PASSWORD_
Then, test your connection from your Linux box in order to add the switch to known_hosts file. This will only happen one time for each switch/host not found in the known_hosts file:
ssh test#10.0.0.1
The authenticity of host '10.0.0.1 (10.0.0.1)' can't be established.
RSA key fingerprint is xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:d6:4b:d1:67.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '10.0.0.1' (RSA) to the list of known hosts.
ciscoswitch#
ciscoswitch#exit
Finally test the connection using ansible over SSH and raw module, for example:
ansible inventory -m raw -a "show env all" -u test
I hope you find it useful.
I'm having a problem; git returns this alert:
The authenticity of host 'bitbucket.org (104.192.143.2)' can't be established.
RSA key fingerprint is SHA256:zzXQOXSRBEiUtuE8AikJYKwbHaxvSc0ojez9YXaGp1
Are you sure you want to continue connecting (yes/no)?
When I choose yes, it returns this:
Warning: Permanently added 'bitbucket.org,104.192.143.2' (RSA) to the list of known hosts.
ssh_packet_read: Connection closed
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
What is the problem?
Where must I add the RSA number? Please, I'm desperate. :(
The authenticity of host 'bitbucket.org (104.192.143.2)' can't be established. RSA key fingerprint is SHA256:zzXQOXSRBEiUtuE8AikJYKwbHaxvSc0ojez9YXaGp1 Are you sure you want to continue connecting (yes/no)?
This is normal and it's safe to say yes. ssh is being overly paranoid by asking you to confirm it. You can turn it off by setting StrictHostKeyChecking to no in your ssh config.
Remembering the public key of each server you connect to is a security feature of ssh to protect you from a man-in-the-middle attack. It goes something like this:
The first time you ssh to a host its public key (that's all that SHA256:zzXQ... stuff) is remembered, usually in ~/.ssh/known_hosts.
Every time thereafter ssh will check that the same host is still using the same key. This authenticates that bitbucket.org is still the same server you were talking to the first time.
If the keys don't match it could mean one of two things. First is that the server admin reinstalled their ssh server and forgot to keep the same key. This is common for small sites, but unlikely for something like bitbucket.org.
The second possibility is that the ssh server has been hijacked. It doesn't matter how. One common way is for a rogue DNS server to return their own malicious IP address instead of the real address for bitbucket.org. Common enough on public wifi connections.
As for why it won't connect after confirming, it's right there in the error message.
$ git clone git#bitbucket.org:RobeJablonski/sda-robert.git
Cloning into 'sda-robert'...
conq: repository access denied.
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
The repository exists, that can be verified, so you don't have access rights (neither do I). Bitbucket determines who you are using your ssh key. This means you're not logging in with the right key. It has to be the same key as is associated with your account on BitBucket.
You can find your BitBucket ssh keys in your Bitbucket settings under https://bitbucket.org/account/user//ssh-keys/. Then you have to check if ssh is using that key. You can check what it's using using ssh -v git#bitbucket.org. It will spew out a lot of stuff but you're looking for the last instance of debug1: Offering RSA public key: /Users/blah/.ssh/blah.
Once you find that, check if /Users/blah/.ssh/blah.pub matches what BitBucket thinks your ssh key is. If they don't match, then you'll have to find the matching key and configure ssh to use that key for bitbucket.org.
If you've lost the key, you should change your ssh key on bitbucket.org.
Make sure you have followed below steps in your application server:
Have you created public key:
cd ~/.ssh/
To generate keygeneration:
ssh-keygen
Copy public key value (NOT PRIVATE KEY)
cat ~/.ssh/id_rsa.pub
Install git :
sudo apt install git
ATLASSIAN SETUP :
SETTINGS -> Access keys -> Add key
https://bitbucket.org/compassitesinc/your-repository/admin/access-keys/
Make sure your email address added to the User group (with admin permission)
SETTINGS -> User and group access
Add your email address with admin access
Inside your application root directory clone your repository.
cd /var/www/html/
git clone git#bitbucket.org:organization_name/repo_application.git repo_application
You need to create an SSH key on the machine you wish to connect to GitHub or Bitbucket, then add that key to your online account. You can do this by following this:
https://confluence.atlassian.com/bitbucket/set-up-ssh-for-git-728138079.html
The target server is a relatively clean install of Ubuntu 14.04. I generated a new ssh key using ssh-keygen and added it to my server using ssh-copy-id. I also checked that the public key was in the ~/.ssh/authorized_keys file on the server.
Even still, I am prompted for a password every time I try to ssh into the server.
I noticed something weird however. After I log into my first session using my password, the next concurrent sessions don't ask for a password. They seem to be using the ssh key properly. I've noticed this behaviour on two different clients (Mint OSX).
Are you sure your SSH key isn't protected by a password? Try the following:
How do I remove the passphrase for the SSH key without having to create a new key?
If that's not the case, it may just be that ssh is having trouble locating your private key. Try using the -i flag to explicitly point out its location.
ssh -i /path/to/private_key username#yourhost.com
Thank you Samuel Jun for the link to help.ubuntu.com - SSH Public Key Login Troubleshooting !
Just a little caveat:
If you copy your authorized keys file outside your encrypted home directory please make sure your root install is encrypted as well (imho Ubuntu still allows for unencrypted root install coupled with encryption of the home directory).
Otherwise this defeats the whole purpose of using encryption in the first place ;)
If this is happening to you on Windows (I'm on Windows 10)
Try running the program that you're trying to connect via ssh to the server as administrator.
For me I was using powershell with scoop to install a couple of things so that I could ssh straight from it. Anyway... I ran PowerShell as admin and tried connecting again and it didn't ask for my password.
For LinuxSE
Check the SE context with
% ls -dZ ~user/.ssh
Must contain unconfined_u:object_r:ssh_home_t:s0
If not, that was the problem , as root run
# for i in ~user/.ssh ~user/.ssh/*
do
semanage fcontext -a -t ssh_home_t $i
done
# restorecon -v -R ~user/.ssh
It looks like it's related to encryption on your home directory and therefore the authorized_keys file cannot be read.
https://unix.stackexchange.com/a/238570
Make sure your ssh public key was copied to the remote host in the right format. If you open the key file to edit it should read 1 line.
Basically, just do ssh-copy-id username#remote. It will take care of the rest.
I have problem with accessing SSH to Openshift.
I still can push code to Openshift via Git. But when trying to SSH to Openshift, the server denied with error "no supported authentication methods available (server sent: public key, gssapi-keyex, gssapi-with-mic". I'm using Windows 7.
Do you know what's the problem and how to solve it?
This answer is for Windows users.
Who used puttygen.exe to generate your RSA keys.
And you added the PUBLIC key to your Openshift account, via the web console.
And you can PUTTY in OK, but not SSH from GIT-BASH (or cannot git clone via SSH).
One common reason is the key generated by puttygen.exe, is a PUTTY specific file.
You can convert this to OPENSSH format, from within the puttygen.exe program.
(Menu > Conversions > Export OpenSSH Key)
Save it to a new file, in the same directory as your original PUTTY generated PUBLIC/PRIVATE key pair.
Reference this OPENSSH key from your ~/.ssh/config file.
See step 4 here, if you dont have this config file.
https://confluence.atlassian.com/display/BITBUCKET/Set+up+SSH+for+Git
Test by opening GIT-BASH, and trying your specific "ssh user#yourhost.rhcloud.com" (without the quotes, and where user and your host are specific to your account). If that works, you should be good to go...
Short version:
remove the leading "ssh " from the ssh url provided by the OpenShift web console.
I was frustrated when this happened to me. I tried all things mentioned above. At last I gave up in windows 7 and opened my Ubuntu virtual machine. Then I noticed the leading "ssh " in the url.
I'm also using Windows 7 and I had the same problem.
I created ssh keys with rhc tool and then public key for putty (id_rsa.ppk). Their permissions (GIT Bash, "ls -l" command) were 700 (but I couldn't connect):
-rwx------+ 1 User123 None 1706 Mar 4 19:46 id_rsa
-rwx------+ 1 User123 None 1464 Mar 4 19:52 id_rsa.ppk
-rwx------+ 1 User123 None 394 Mar 4 19:46 id_rsa.pub
So I changed the permission (with chmod command) to 755:
-rwxr-xr-x+ 1 User123 None 1706 Mar 4 19:46 id_rsa
-rwxr-xr-x+ 1 User123 None 1464 Mar 4 19:52 id_rsa.ppk
-rwxr-xr-x+ 1 User123 None 394 Mar 4 19:46 id_rsa.pub
And then both git-bash and ssh from putty started working. I know that these are not the most secure permissions, but for me it's enough. It may also help to run git/putty as administrator, but I didn't try that.
You may want to reach look into what the OpenShift forums provided on no supported authentication methods available (server sent: public key, gssapi-keyex, gssapi-with-mic. The Red Hat Customer Portal also has a good article on this error, however you will need a Silver plan to see this article.
Typically, on linux this error is caused because the key you are using does not have the right permissions. In short your .ssh/id_rsa key's permissions are too lax (they should be 600).
Note that other people have seen similar issues related to this error with OpenShift so permissions may not be the root cause of your particular issue.
go to preference in eclipse and in ssh key menu, click KEY MANAGEMENT and ther is a rsa key tab click that and copy your public key and click the button save as private key... then go to your open shift application and paste your public key and work on it... i hope it working
Reference
TOOLS
We will need two tools to work with :
PuTTY
PuTTYgen
METHOD
Step 1: Generate a brand-new SSH-2 RSA key.
Step 2: Add the generated key in the host (for ex. in settings >> keys on Openshift) that requires the authentication.
Step 3: Export this key from PuTTYgen Conversions >> Export OpenSSH Key and save it on your file-system
Step 4: Add/Edit your ~/.ssh/config file
// ~/.ssh/config
Host HOST_NAME // for example - https://my-domain.rhcloud.com
Port PORT_NUMBER // ideally 22
IdentityFile PATH/TO/FILE/CREATED/IN/STEP/3 // the path to where the key was exported
Example Configuration of ~/.ssh/config
Host cool-websites.rhcloud.com
Port 22
IdentityFile C:/Users/cool_dude/Desktop/rhcloud
Good Luck.
You need to create keys in Puttygen - https://the.earth.li/~sgtatham/putty/latest/x86/puttygen.exe. Format - SSH-2 RSA.
This keys have correct format. It works.
This answer is for Linux users. If you have the same problem, disabling GSSAPI may help.
Edit your ~/.ssh/config (user) or /etc/ssh/ssh_config (system-wide) file to set GSSAPIAuthentication no.
Source: Speed up SSH logon by disabling GSSAPIAuthentication
Connecting the SSH servers can sometimes be delayed when the client
and server try to sort out if they should be using GSSAPI to
authenticate.
When i ssh to a machine, sometime i get this error warning and it prompts to say "yes" or "no". This cause some trouble when running from scripts that automatically ssh to other machines.
Warning Message:
The authenticity of host '<host>' can't be established.
ECDSA key fingerprint is SHA256:TER0dEslggzS/BROmiE/s70WqcYy6bk52fs+MLTIptM.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'pc' (ECDSA) to the list of known hosts.
Is there a way to automatically say "yes" or ignore this?
Depending on your ssh client, you can set the StrictHostKeyChecking option to no on the command line, and/or send the key to a null known_hosts file. You can also set these options in your config file, either for all hosts or for a given set of IP addresses or host names.
ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no
EDIT
As #IanDunn notes, there are security risks to doing this. If the resource you're connecting to has been spoofed by an attacker, they could potentially replay the destination server's challenge back to you, fooling you into thinking that you're connecting to the remote resource while in fact they are connecting to that resource with your credentials. You should carefully consider whether that's an appropriate risk to take on before altering your connection mechanism to skip HostKeyChecking.
Reference.
Old question that deserves a better answer.
You can prevent interactive prompt without disabling StrictHostKeyChecking (which is insecure).
Incorporate the following logic into your script:
if [ -z "$(ssh-keygen -F $IP)" ]; then
ssh-keyscan -H $IP >> ~/.ssh/known_hosts
fi
It checks if public key of the server is in known_hosts. If not, it requests public key from the server and adds it to known_hosts.
In this way you are exposed to Man-In-The-Middle attack only once, which may be mitigated by:
ensuring that the script connects first time over a secure channel
inspecting logs or known_hosts to check fingerprints manually (to be done only once)
To disable (or control disabling), add the following lines to the beginning of /etc/ssh/ssh_config...
Host 192.168.0.*
StrictHostKeyChecking=no
UserKnownHostsFile=/dev/null
Options:
The Host subnet can be * to allow unrestricted access to all IPs.
Edit /etc/ssh/ssh_config for global configuration or ~/.ssh/config for user-specific configuration.
See http://linuxcommando.blogspot.com/2008/10/how-to-disable-ssh-host-key-checking.html
Similar question on superuser.com - see https://superuser.com/a/628801/55163
Make sure ~/.ssh/known_hosts is writable. That fixed it for me.
The best way to go about this is to use 'BatchMode' in addition to 'StrictHostKeyChecking'. This way, your script will accept a new hostname and write it to the known_hosts file, but won't require yes/no intervention.
ssh -o BatchMode=yes -o StrictHostKeyChecking=no user#server.example.com "uptime"
This warning is issued due the security features, do not disable this feature.
It's just displayed once.
If it still appears after second connection, the problem is probably in writing to the known_hosts file.
In this case you'll also get the following message:
Failed to add the host to the list of known hosts
You may fix it by changing owner of changing the permissions of the file to be writable by your user.
sudo chown -v $USER ~/.ssh/known_hosts
Edit your config file normally located at '~/.ssh/config', and at the beggining of the file, add the below lines
Host *
User your_login_user
StrictHostKeyChecking no
IdentityFile ~/my_path/id_rsa.pub
User set to your_login_user says that this settings belongs to your_login_user
StrictHostKeyChecking set to no will avoid the prompt
IdentityFile is path to RSA key
This works for me and my scripts, good luck to you.
Ideally, you should create a self-managed certificate authority. Start with generating a key pair:
ssh-keygen -f cert_signer
Then sign each server's public host key:
ssh-keygen -s cert_signer -I cert_signer -h -n www.example.com -V +52w /etc/ssh/ssh_host_rsa_key.pub
This generates a signed public host key:
/etc/ssh/ssh_host_rsa_key-cert.pub
In /etc/ssh/sshd_config, point the HostCertificate to this file:
HostCertificate /etc/ssh/ssh_host_rsa_key-cert.pub
Restart the sshd service:
service sshd restart
Then on the SSH client, add the following to ~/.ssh/known_hosts:
#cert-authority *.example.com ssh-rsa AAAAB3Nz...cYwy+1Y2u/
The above contains:
#cert-authority
The domain *.example.com
The full contents of the public key cert_signer.pub
The cert_signer public key will trust any server whose public host key is signed by the cert_signer private key.
Although this requires a one-time configuration on the client side, you can trust multiple servers, including those that haven't been provisioned yet (as long as you sign each server, that is).
For more details, see this wiki page.
Do this -> chmod +w ~/.ssh/known_hosts. This adds write permission to the file at ~/.ssh/known_hosts. After that the remote host will be added to the known_hosts file when you connect to it the next time.
With reference to Cori's answer, I modified it and used below command, which is working. Without exit, remaining command was actually logging to remote machine, which I didn't want in script
ssh -o StrictHostKeyChecking=no user#ip_of_remote_machine "exit"
Add these to your /etc/ssh/ssh_config
Host *
UserKnownHostsFile=/dev/null
StrictHostKeyChecking=no
Generally this problem occurs when you are modifying the keys very oftenly. Based on the server it might take some time to update the new key that you have generated and pasted in the server. So after generating the key and pasting in the server, wait for 3 to 4 hours and then try. The problem should be solved. It happened with me.
The following steps are used to authenticate yourself to the host
Generate a ssh key. You will be asked to create a password for the key
ssh-keygen -f ~/.ssh/id_ecdsa -t ecdsa -b 521
(above uses the recommended encryption technique)
Copy the key over to the remote host
ssh-copy-id -i ~/.ssh/id_ecdsa user#host
N.B the user # host will be different to you. You will need to type in the password for this server, not the keys password.
You can now login to the server securely and not get an error message.
ssh user#host
All source information is located here:
ssh-keygen
For anyone who finds this and is simply looking to prevent the prompt on first connection, but still wants ssh to strictly check the key on subsequent connections (trust on first use), you can set StrictHostKeyChecking to accept-new in ~/.ssh/config, which will do what you're looking for. You can read more about it in man ssh_config. I strongly discourage disabling key checking altogether.
Run this in host server it's premonition issue
chmod -R 700 ~/.ssh
I had the same error and wanted to draw attention to the fact that - as it just happened to me - you might just have wrong privileges.You've set up your .ssh directory as either regular or root user and thus you need to be the correct user. When this error appeared, I was root but I configured .ssh as regular user. Exiting root fixed it.
This is trying to establish password-less authentication. So, if you try to run that command manually once, it will ask to provide the password there. After entering password, it saves that password permanently, and it will never ask again to type 'yes' or 'no'.
For me the reason is that I have wrong permission on ~/.ssh/known_hosts.
I have no write permission on known_hosts file. So it ask me again and again.
In my case, the host was unkown and instead of typing yes to the question are you sure you want to continue connecting(yes/no/[fingerprint])? I was just hitting enter .
I solve the issue which gives below written error:
Error:
The authenticity of host 'XXX.XXX.XXX' can't be established.
RSA key fingerprint is 09:6c:ef:cd:55:c4:4f:ss:5a:88:46:0a:a9:27:83:89.
Solution:
1. install any openSSH tool.
2. run command ssh
3. it will ask for do u add this host like.
accept YES.
4. This host will add in the known host list.
5. Now you are able to connect with this host.
This solution is working now......