I have a site on CyberPanel, user "thows3051" and want to use git to manage my site. But when I try ssh -T git#github.com I get git#github.com: Permission denied (publickey)..
If I ssh into the server on that user ssh thows3051#mysite.com, into the .ssh directory, there is a thows3051.pub file which I copied the contents into the repo on github under "deploy keys".
EDIT
Was able to explicitly use the correct key with ssh -i ~/.ssh/thows3051 -T git#github.com which shows You've successfully authenticated....
So my question is why isn't the user using the right ssh key?
Thanks in advance
Was able to fix it. I'm not sure what key was being used, if any?
But if you create a file in ~/.ssh/config, you can put the following inside:
IdentityFile ~/.ssh/thows3051
And it will use that key.
Note that you can set specific keys for certain hosts, for example:
Host github.com
IdentityFile ~/.ssh/github.key
I'm new to GitHub and experimenting with my first repo. I'm using my Mac which was used by my friend for few days. Now the problem is, as I tried to push my first commit, I see an error that says -
remote: Permission to myUserName/repo.git denied to myFrndsUserName.
fatal: unable to access 'https://github.com/myUserName/repo.git/': The requested URL returned error: 403
I understand that my friend has used his credentials earlier and those are mismatching with my credentials as I tried to push my code. In best case, I would like to replace my friend's credentials with mine and I don't have to give my username and password everytime for different repos that I create in the near future.
Can somebody help me with this? Thank you.
Try this:
Open terminal :
Enter: ls -al ~/.ssh to see if existing SSH key are present in your case may be your friend have removed your previous SSH key.
if dont have any public or private key pair or if you do not want to use those keys available you have to generate new one.
$ ssh-keygen -t rsa -b 4096 -C "your_email#exaple.com"
# Creates a new ssh key, using the provided email as a label
When you are prompted to "Enter a file which to save the key" press Enter. this accepts the default file location.
At the prompt, Type a secure passphrase. For more info see "Working with SSH Key"
Add SSH key to your GitHub account
Copy the SSH key to clipboard.
If your SSH key file has a different name than the example code, modify the filename to match your current setup. When copying your key, don't add any newlines or whitespace.
$ pbcopy < ~/.ssh/id_rsa.pub
To follow further steps click here
Let me know if this doesn't work out properly
I have to deal with a rather annoying situation. I must transfer a file via shell script using scp from one server to another. The problem is that I do not have root access on either of them. I'm not allowed to install any packages like, sshpass, ssh2, expect etc. I don't even have write permission in the home directory of the user I have to use on the second server.
Since I can't use sshpass etc. to enable my script to enter the login credentials, I thought about using an ssh keypair for auth. Actually that was my first thought, but since the user on the second server doesn't have write permissions in its home directory but only in a subsequent directory, ssh-keygen fails as it can't put the keys in ~/.ssh.
Both are Debian servers btw.
Is there any way to generate a ssh keypair and use it outside of ~/.ssh?
Any help is greatly appreciated.
On the clientside yes. However, on serverside, unless configured differently, sshd will expect your credentials in that directory.
If you can scp from the server where you can't access .ssh to the one where you can, you can use -i option to specify the keyfile location.
Do you have an alternative transport mechanism? Can you put the filn your public_html and wget it on the other side?
You can have the keypairs anywhere. What is key is that the permissions are set correctly on the keypair. The ownership needs to be set to the user chown user:user keyfile and the permissions must be chmod 400 keyfile.
Once you have your key moved and permissions set all that's left is to tell scp which key to use. You can do this by using the -i flag.
IE: scp /source/file user#host:/target/location/ -i keyfile
Edit:
As Amadan alluded to in his answer - this assumes the server you're connecting to already has the key as an authorized key on the user. If not it would require an /etc/ssh/sshd_config change that only someone with the right access can do. It might be worth trying a cat /etc/ssh/sshd_config on the server if your user has access to it at all right now. If you have read access you'll be able to discern the expected authorized_keys location. It's possible the server admin has already customized the expected key location to something you have write access to.
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.
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......