Rsync Won't Connect - ssh

I've just set up a new website on SiteGround and am trying to sync files to it from another server, however, when running the command, I'm getting the following error:
Enter passphrase for key '/cygdrive/c/Users/Example User/.ssh/id_rsa':
Permission denied (publickey).
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: unexplained error (code 255) at /home/lapo/packaging/rsync-3.0.4-1/src/rsync-3.0.4/io.c(632) [sender=3.0.4]
The passphrase is definitely correct.
Here's the rsync command that I'm running:
rsync -avz --exclude-from='exclude.txt' -e 'ssh -p 1234' test/test.txt user#host:/home/user/www/sitename/public_html/
I know my keys and passphrase are correct because I'm able to ssh on to the server with no issues, using the following command:
ssh user#host -p 1234
I've tried many tweaks to the rsync code such as making sure there are trailing slashes, that the directories exist. I've tried it both with -avz and without. I've also tried a key without a passphrase.
I also thought that maybe Siteground is blocking things but rsync is available on the server so I don't know why this would be.
Unfortunately, despite being able to SSH to the server, rsync simply won't even though it's using the same key, passphrase and port.
Where am I going wrong?

I've managed to connect now and should anyone else run into the issue, the fix I found worked for me was to create a new SSH key outside of the Users directory. I'm putting this down to permissions, as soon as I move it to the the C drive in it's own folder, everything worked as expected!

Related

first time out of many with ssh "permission denied (publickey)"

Forgive me, I know this has been asked so many times, and I read most of the answers. The difference between this question and other questions is that, in my case I did this procedure so many times. But this time is the first time in my life this is not working and I can't debug this.
I created a new ssh key in the client (windows 10), and added it to the authorized keys in the server (Ubuntu 20.04) through another authorized client (Ubuntu 20.04), restarted ssh, but I can't connect: it throws me the classic error "permission denied (public key)"
As I stated in the beginning, I did this so many times without any problem at all.
I don't know what I should do to fix it, everything looks ok..
UPDATE
I forgot to mention one important thing, using:
ssh -i ~/.ssh/private_key username#host
I can connect to the server without any problem.
I don't know why the simple ssh command is not working. I just have one key set up in the client.
Start the ssh-agent in the background.
$ eval "$(ssh-agent -s)"
then
Add your SSH private key to the ssh-agent.
$ ssh-add ~/.ssh/private_key

Cannot ssh into remote machine after rsync

I followed this page on Protecting the Docker daemon Socket with HTTPS to generate ca.pem, server-key.pem, server-cert.pem, key.pem and key-cert.pem
I wanted a remote Docker daemon to use those keys so i used rsync via ssh to send three of the files(ca.pem, server-key.pem and key.pem) to the remote host's home directory. The identity file for ssh into the remote host is called dl-datatest-internal.pem
ubuntu#ip-10-3-1-174:~$ rsync -avz -progress -e "ssh -i dl-datatest-internal.pem" dockerCer/ core#10.3.1.181:~/
sending incremental file list
./
ca.pem
server-cert.pem
server-key.pem
sent 3,410 bytes received 79 bytes 6,978.00 bytes/sec
total size is 4,242 speedup is 1.22
The remote host stopped recognising the identity file ever since and started asking for a non-existent password.
ubuntu#ip-10-3-1-174:~$ ssh -i dl-datatest-internal.pem core#10.3.1.151
core#10.3.1.151's password:
Does anyone know why and how to fix it? I still have all the keys if that helps.
There are a couple things about the rsync command that bother me, but, I can't put my finger on the problem (if there is one).
the rsync command and subsequent ssh command reference different hosts: rsync(core#10.3.1.181:~/
) and ssh to the host(core#10.3.1.151). Those are different machines, no?
the ~ in the target of the rsync command. core#10.3.1.181:~/. I am pretty sure that the ~/ references the core home directory, but, you could just get rid of the ~/ and replace that with a . (dot).
If you can reproduce the environment you did the copy in, you can add a --dry-run to the rsync command to see what it is going to do. Looking at this command I can't see it erasing the target's .ssh directory.

Pass ssh options to ssh-copy-id

I'm stuck in the Permission denied (publickey) hell trying to copy public key to a remote server so Jenkins can rsync files during builds.
Running:
sudo ssh-copy-id -i id_rsa.pub ubuntu#xx.xx.xx.xx
I have done this for another server, but that one has a separate key pair for SSH assigned by EC2, and my current guess is that ssh-copy-id is trying to use wrong private key for this connection. Is there a way to pass -vv to ssh-copy-id so I can see what jey it's trying to use. I've looked into the -o switch, but can't seem to get it right.
Thank you.
So here's what I've done:
added following to /etc/ssh/ssh_config:
Host xx.xx.xx.xx
User ubuntu
IdentityFile ~/.ssh/key-name-for-that-machine.pem
Then copied key-name-for-that-machine.pem into /var/lib/jenkins/.ssh
Didn't run ssh-copy-id again, simply have rsync use that key file when moving stuff, here's the rsync script:
rsync -rvh -e 'ssh -v' "/tmp/project-DEV-${BUILD_ID}/" ubuntu#xx.xx.xx.xx:"/www/www.project-dir.net/"
my guess would by running it without sudo. But that's depending on how you normally log into the server.
If you normally login by using ssh ubuntu#xx.xx.xx.xx then lose the
sudo.
If not than try to login with sudo ssh ubuntu#xx.xx.xx.xx
Reading your question, at least one of these should fail.

ssh -T git#github.com Permission denied (publickey)

I tried to push my blog (Octopress) to github and got this error:
MacBook-Air:octopress bdeely$ git push origin source
Permission denied (publickey).
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
I generated an SSH key, saved it, and even linked it with my GitHub account in the SSH key settings, but I went ahead and checked the status and got the same error:
MacBook-Air:.ssh bdeely$ ssh -T git#github.com
Permission denied (publickey).
In addition to this, I checked github's help page, did the following and got this error message:
MacBook-Air:~ bdeely$ ssh-add -l
The agent has no identities.
Does anyone know what is wrong and how I can fix this?
On OSX, if you type
ssh-add -l
and you get back "no identities", that means your ssh agent does not have any identities loaded into it. Oftentimes, when the mac reboots, you have no identities.
I add mine back after a re-boot by explicitly running
ssh-add
This loads a default identity from ~/.ssh/id_rsa
You can also use the ssh-add command with a specific identity
ssh-add ~/foo/bar/is_rsa
After you add your identies, you can seem them all listed by typing
ssh-add -l
Make sure you have at least one listed.
Follow the commands:
mkdir ~/.ssh //in case that the folder doesnt exist...
cd ~/.ssh
ssh-keygen -t rsa -C "youremail#somewhere.gr"
#hit enter when asks for file to save the key.
#enter the passphrase
At last copy the id_rsa.pub into your github account.
Try this in your terminal:
eval `ssh-agent -s`
ssh-add ~/.ssh/id_rsa
enter your passphrase if any and it should work. Hope this helps :-)
I hope this helps you:
I was having the identical problem and about to take my own eyes out with insane frustration; nothing online led me to an answer and I was trying to use the git push command without specifying the URL exactly (which could also solve the problem I believe), so I didn't see how the connection was failing.
I had set up my .ssh/config correctly for two users with two different keys, even using IdentitiesOnly yes which is supposed to override ssh-agent that was automatically supplying the WRONG ssh identity.
I finally realized the problem as I examined the local repository configuration - it was the entry
[remote "origin"]
url = git#github.com:{my-username}/{my-repo-name}.git
My configuration in .ssh/config file was using the same HostName github.com entry for both users and I'm completely new to all this so I didn't realize that to correctly override ssh-agent, I had to specify the exact URL or else the specific identities in my .ssh/config file would be ignored and the first key that ssy-agent listed (which was the wrong one my my case) would be used by default.
I fixed this by changing the local repo URL to url = git#github-personal:{my-username}/{my-repo-name}.git, where I had set Host github-personal as the identity in my .ssh/config.
Another way to solve this would be specifying the user in the URL in the git push command itself, or even better, a solution described here in a post AFTER solving this my own crappy way:
https://superuser.com/questions/272465/using-multiple-ssh-public-keys
I can't believe that no official source could offer a solution for or even properly explain this edge-case that seems really common (accessing two different github accounts from one machine with SSL).
I experienced the same problem. The reason was that I moved the key-files to another folder; it worked successfully when I moved them back to where they were originally.

How to run automated rsync using ssh2

i am trying to setup rsync between two machines over ssh2 protocol.
Earlier we used ssh1 for automated rsync without any passphrase, but recently we migrated to ssh2 and running rsync with ssh2 prompts for passphrase.
I generated a new SSH2-RSA key and that too without passphrase, but it still asks me for the passphrase.Here is the command that i run for ssh
/usr/bin/ssh -2 -i /usr/local/www-rsync-key fsuser#xyz
What steps do you have to do to get an ssh2 key with a null password to work? I'm guessing there are certain settings in /etc/ssh/sshd_config you have to set, but I can't figure out what!
This question appeared on Superuser, discussing the topic of ssh without a password.
If you're getting prompted for a password, check that you've added the public key to the correct file on the far side (could be authorized_keys2 now), and that the directory permissions are correct (.ssh and its contents shouldn't have any group or world permissions set).