I'm constantly setting up passwordless ssh environments. And, while there are many howTos out there, most are rather long. This is going to be very short and without much explanation. Read the load documents for the details. I plan to add screen-shots, but that has to wait until after my wrist heals. I broke it badly just the day before yesterday.
PuTTY doesn't natively support the private key format (.pem)
You must convert your private key into a .ppk file
before you can connect to your instance using PuTTY
ssh-keygen generates 2 files.
- id_rsa: The private key
- id_rsa.pub: The public key
PuTTYgen will genrate the ppk for use with PuTTY.
On Linux (I’m using CentOS 8)
=================================
mkdir -p ~/.ssh
chmod 700 ~/.ssh
cd ~/.ssh
ssh-keygen -t rsa -b 4096 -N '' -f ~/.ssh/id_rsa -C "yourEmailAddr#yahoo.com"
cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
chmod 400 ~/.ssh/*
cp ~/.ssh/* /VMShare/ssh/ #a common mount between my virtual machines and windows
on Windows
----------
1. open PuTTYgen Click Load and open the private file (normally id_rsa)
2. Click “Save Private Key” and choose a name. I use id_rsa.ppk
3. Open Putty
3.1. Set Connection->Data->Auto-login username as appropriate
3.2. set the Connection->SSH->Auth->”Private key file for authentication” to the ppk file.
To setup 1 way ssh between 2 Linux machines
-------------------------------------------
copy the id_rsa file to ~/.ssh on the second machine
Next: chmod 400 ~/.ssh/id_rsa
Now you can ssh from the second machine to the first
To setup 1 way ssh between 2 Linux machines
-------------------------------------------
Copy the id_rsa and id_rsa.pub file to ~/.ssh on the second machine
cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
chmod 400 ~/.ssh/authorized_keys ~/.ssh/id_rsa ~/.ssh/id_rsa.pub
To Test the ssh use:
--------------------
ssh -i id_rsa.pub user#host1
<https://help.dreamhost.com/hc/en-us/articles/215464758-How-do-I-set-up-passwordless-login-in-PuTTY->
For an application I'm making I have to use GPG in a root process on machine #1. On some other machine (#2) I want to run a shell script, that creates keys (secret and public) in GPG for user root on machine #1.
First I create a file, key.scr, where I define characteristics for the new key.
When I run
gpg --batch --gen-key /hdd/myfolder/key.scr"
via ssh for user , a perfect key-pair is created and saved in /home//.gnupg
But my goal is to create keys for the user root, who must use these keys in some crontab-job.
I tried the following:
echo "<MyPassword>" | sudo -S gpg --batch --gen-key /hdd/myfolder/key.scr
and
sudo -u root gpg --batch --gen-key /hdd/myfolder/key.scr
I also placed
gpg --batch --gen-key /hdd/myfolder/key.scr
in a shell command file , and ran
sudo <BatchFile>
but I only messed up the .gnupg folder for (the access rights for several files in this folder are changed to root - root, so they are not readable any longer by .
So, what is the proper way to create via ssh GPG keys which can be used by user root, while root access is not possible via ssh?
I would very much like to take my Git install with me wherever I go, so I have installed GitPortable via PortableApps.
Unfortunately, the OpenSSH utilities available in git-bash insists on placing/searching for the .ssh folder in a nonsensical place (C/.ssh).
Now, I have seen others with the same problem, but the solution generally was to set HOME as a Windows environment variable. But this is not working for me.
From the usual Windows command prompt:
C:\Users\snb>echo %HOME%
C:\Users\snb
Showing that the environment variable is apparently set correctly.
From git-bash:
snb#SNB-WORKSTATION /c/Users/snb
$ echo $HOME
C:\Users\snb
Showing that git-bash agrees. However if I test out an SSH command, OpenSSH has the completely wrong idea of where to locate the .ssh folder:
snb#SNB-WORKSTATION /c/Users/snb
$ ssh -T git#bitbucket.org
Could not create directory 'C/.ssh'.
The authenticity of host 'bitbucket.org (131.103.20.167)' can't be established.
RSA key fingerprint is 97:8c:1b:f2:6f:14:6b:5c:3b:ec:aa:46:46:74:7c:40.
Are you sure you want to continue connecting (yes/no)?
I'm at a loss at what to do to make OpenSSH in the GitPortable installation understand where my home directory is. Do you have any ideas other than giving in and just installing Git for Windows?
EDIT:
The OpenSSH version is:
$ ssh -V
OpenSSH_6.6.1p1, OpenSSL 1.0.1i 6 Aug 2014
The command uses the correct .ssh folder location in a Windows command prompt when using git-cmd.bat:
C:\Users\snb>ssh -T git#bitbucket.org
The authenticity of host 'bitbucket.org (131.103.20.168)' can't be established.
RSA key fingerprint is 97:8c:1b:f2:6f:14:6b:5c:3b:ec:aa:46:46:74:7c:40.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'bitbucket.org,131.103.20.168' (RSA) to the list of known hosts.
Enter passphrase for key '/c/Users/snb/.ssh/id_rsa':
But I truly hate cmd.exe, I need this to work for git-bash! :)
The SSH command git-bash uses is:
$ which ssh
/bin/ssh
The /bin folder is located inside the GitPortable installation, so this would be the OpenSSH version distributed with GitPortable.
This GitPortable is based on msysgit PortableGit-1.9.5-preview20141217 github commit
The proper path for HOME in a bash session should be set with:
export HOME=/c/Users/snb
That would make it compatible with ssh in a unix shell.
Using posix path seems safer considering Git is running on top of a posix run-time environment.
To copy a folder from local computer to server I use
scp -r local_folder user#server:path
Now I forgot to specify the target path the first time:
scp -r local_folder user#server
Does anyone now if the folder has been copied and if yes, where in the server is it located at?
I issued the correct command later and copied the folder to my user directory but I just want to know whether the folder is also copied somewhere on the server the first time and find and delete it. I am a user and don't have permission to search the whole server. Thanks.
When you use user#server without a ':' character, scp interprets user#server as the file name on the local machine to which you would like to copy your file. So, you should find a file (or in this case a directory) called user#server in the directory from which you issued the scp -r local_folder user#server command.
I need to do rsync by ssh and want to do it automatically without the need of passing password for ssh manually.
Use "sshpass" non-interactive ssh password provider utility
On Ubuntu
sudo apt-get install sshpass
Command to rsync
/usr/bin/rsync -ratlz --rsh="/usr/bin/sshpass -p password ssh -o StrictHostKeyChecking=no -l username" src_path dest_path
You should use a keyfile without passphrase for scripted ssh logins. This is obviously a security risk, take care that the keyfile itself is adequately secured.
Instructions for setting up passwordless ssh access
You can avoid the password prompt on rsync command by setting the environment variable RSYNC_PASSWORD to the password you want to use or using the --password-file option.
I got it to work like this:
sshpass -p "password" rsync -ae "ssh -p remote_port_ssh" /local_dir remote_user#remote_host:/remote_dir
If you can't use a public/private keys, you can use expect:
#!/usr/bin/expect
spawn rsync SRC DEST
expect "password:"
send "PASS\n"
expect eof
if [catch wait] {
puts "rsync failed"
exit 1
}
exit 0
You will need to replace SRC and DEST with your normal rsync source and destination parameters, and replace PASS with your password. Just make sure this file is stored securely!
The following works for me:
SSHPASS='myPassword'
/usr/bin/rsync -a -r -p -o -g --progress --modify-window=1 --exclude /folderOne -s -u --rsh="/usr/bin/sshpass -p $SSHPASS ssh -o StrictHostKeyChecking=no -l root" source-path myDomain:dest-path >&2
I had to install sshpass
Use a ssh key.
Look at ssh-keygen and ssh-copy-id.
After that you can use an rsync this way :
rsync -a --stats --progress --delete /home/path server:path
Another interesting possibility:
generate RSA, or DSA key pair (as it was described)
put public key to host (as it was already described)
run:
rsync --partial --progress --rsh="ssh -i dsa_private_file" host_name#host:/home/me/d .
Note: -i dsa_private_file which is your RSA/DSA private key
Basically, this approach is very similar to the one described by #Mad Scientist, however you do not have to copy your private key to ~/.ssh. In other words, it is useful for ad-hoc tasks (one time passwordless access)
Automatically entering the password for the rsync command is difficult. My simple solution to avoid the problem is to mount the folder to be backed up. Then use a local rsync command to backup the mounted folder.
mount -t cifs //server/source/ /mnt/source-tmp -o username=Username,password=password
rsync -a /mnt/source-tmp /media/destination/
umount /mnt/source-tmp
The official solution (and others) were incomplete when I first visited, so I came back, years later, to post this alternate approach in case any others wound up here intending to use a public/private key-pair:
Execute this from the target backup machine, which pulls from source to target backup
rsync -av --delete -e 'ssh -p 59333 -i /home/user/.ssh/id_rsa' user#10.9.9.3:/home/user/Server/ /home/keith/Server/
Execute this from the source machine, which sends from source to target backup
rsync -av --delete -e 'ssh -p 59333 -i /home/user/.ssh/id_rsa' /home/user/Server/ user#10.9.9.3:/home/user/Server/
And, if you are not using an alternate port for ssh, then consider the more elegant examples below:
Execute this from the target backup machine, which pulls from source to target backup:
sudo rsync -avi --delete user#10.9.9.3:/var/www/ /media/sdb1/backups/www/
Execute this from the source machine, which sends from source to target backup:
sudo rsync -avi --delete /media/sdb1/backups/www/ user#10.9.9.3:/var/www/
If you are still getting prompted for a password, then you need to check your ssh configuration in /etc/ssh/sshd_config and verify that the users in source and target each have the others' respective public ssh key by sending each over with ssh-copy-id user#10.9.9.3.
(Again, this is for using ssh key-pairs without a password, as an alternate approach, and not for passing the password over via a file.)
Though you've already implemented it by now,
you can also use any expect implementation (you'll find alternatives in Perl, Python: pexpect, paramiko, etc..)
I use a VBScript file for doing this on Windows platform, it servers me very well.
set shell = CreateObject("WScript.Shell")
shell.run"rsync -a Name#192.168.1.100:/Users/Name/Projects/test ."
WScript.Sleep 100
shell.SendKeys"Your_Password"
shell.SendKeys "{ENTER}"
Exposing a password in a command is not safe, especially when using a bash script, if you tried to work with keyfiles thats will be nice.
create keys in your host with ssh-keygen and copy the public key with ssh-copy-id "user#hostname.example.com and then use rsync addin the option -e "ssh -i $HOME/.ssh/(your private key)" to force rsync using ssh connection via the the private key that you create earlier.
example :
rsync -avh --exclude '$LOGS' -e "ssh -i $HOME/.ssh/id_rsa" --ignore-existing $BACKUP_DIR $DESTINATION_HOST:$DESTINATION_DIR;
Here's a secure solution using a gpg encrypted password.
1.Create a .secret file containing your password in the same folder as your rsync script using the command:
echo 'my-very-secure-password' > .secret
Note that the file is hidden by default for extra security.
2.Encrypt your password file using the following gpg command and follow the prompts:
gpg -c .secret
This will create another file named .secret.gpg. Your password is now encrypted.
3.Delete the plain text password file
rm .secret
4.Finally in your rsync script use gpg and sshpass as follows:
gpg -dq secret.gpg | sshpass rsync -avl --mkpath /home/john user_name#x.x.x.x/home
The example is syncing the entire home folder for the user named john to a remote server with IP x.x.x.x
Following the idea posted by Andrew Seaford, this is done using sshfs:
echo "SuperHardToGuessPass:P" | sshfs -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no user#example.com:/mypath/ /mnt/source-tmp/ -o workaround=rename -o password_stdin
rsync -a /mnt/source-tmp/ /media/destination/
umount /mnt/source-tmp