Related
I am trying to connect to a remote Git repository that resides on my web server and clone it to my machine.
I am using the following format for my command:
git clone ssh://username#domain.example/repository.git
This has worked fine for most of my team members. Usually after running this command Git will prompt for the user's password, and then run the cloning. However, when running on one of my machines I get the following error:
Host key verification failed.
fatal: Could not read from remote
repository.
We are not using SSH keys to connect to this repository, so I'm not sure why Git is checking for one on this particular machine.
As I answered previously in Cloning git repo causes error - Host key verification failed. fatal: The remote end hung up unexpectedly, add GitHub to the list of known hosts:
ssh-keyscan -t rsa github.com >> ~/.ssh/known_hosts
You are connecting via the SSH protocol, as indicated by the ssh:// prefix on your clone URL. Using SSH, every host has a key. Clients remember the host key associated with a particular address and refuse to connect if a host key appears to change. This prevents man in the middle attacks.
The host key for domain.example has changed. If this does not seem fishy to you, remove the old key from your local cache by editing ${HOME}/.ssh/known_hosts to remove the line for domain.example or letting an SSH utility do it for you with
ssh-keygen -R domain.example
From here, record the updated key either by doing it yourself with
ssh-keyscan -t rsa domain.example >> ~/.ssh/known_hosts
or, equivalently, let ssh do it for you next time you connect with git fetch, git pull, or git push (or even a plain ol’ ssh domain.example) by answering yes when prompted
The authenticity of host 'domain.example (a.b.c.d)' can't be established.
RSA key fingerprint is XX:XX:...:XX.
Are you sure you want to continue connecting (yes/no)?
The reason for this prompt is domain.example is no longer in your known_hosts after deleting it and presumably not in the system’s /etc/ssh/ssh_known_hosts, so ssh has no way to know whether the host on the other end of the connection is really domain.example. (If the wrong key is in /etc, someone with administrative privileges will have to update the system-wide file.)
I strongly encourage you to consider having users authenticate with keys as well. That way, ssh-agent can store key material for convenience (rather than everyone having to enter her password for each connection to the server), and passwords do not go over the network.
I had the similar issue, but, using SSH keys. From Tupy's answer, above, I figured out that the issue is with known_hosts file not being present or github.com not being present in the list of known hosts. Here are the steps I followed to resolve it -
mkdir -p ~/.ssh
ssh-keyscan -t rsa github.com >> ~/.ssh/known_hosts
ssh-keygen -t rsa -C "user.email"
open the public key with this command $ cat ~/.ssh/id_rsa.pub and copy it.
Add the id_rsa.pub key to SSH keys list on your GitHub profile.
This is happening because github is not currently in your known hosts.
You should be prompted to add github to your known hosts. If this hasn't happened, you can run ssh -T git#github.com to receive the prompt again.
For me, I just had to type "yes" at the prompt which asks "Are you sure you want to continue connecting (yes/no)?" rather than just pressing Enter.
If you are in office intranet (otherwise dangerous) which is always protected by firewalls simply have the following lines in your ~/.ssh/config.
Host *
StrictHostKeyChecking no
UserKnownHostsFile=/dev/null
When asked:
Are you sure you want to continue connecting (yes/no)?
Type yes as the response
That is how I solved my issue. But if you try to just hit the enter button, it won't work!
I got the same problem on a newly installed system, but this was a udev problem. There was no /dev/tty node, so I had to do:
mknod -m 666 /dev/tty c 5 0
What worked for me was to first add my SSH key of the new computer, I followed these instructions from GitLab - add SSH key. Note that since I'm on Win10, I had to do all these commands in Git Bash on Windows (it didn't work in regular DOS cmd Shell).
Then again in Git Bash, I had to do a git clone of the repo that I had problems with, and in my case I had to clone it to a different name since I already had it locally and didn't want to lose my commits. For example
git clone ssh://git#gitServerUrl/myRepo.git myRepo2
Then I got the prompt to add it to known hosts list, the question might be this one:
Are you sure you want to continue connecting (yes/no)?
I typed "yes" and it finally worked, you should typically get a message similar to this:
Warning: Permanently added '[your repo link]' (ECDSA) to the list of known hosts.
Note: if you are on Windows, make sure that you use Git Bash for all the commands, this did not work in regular cmd shell or powershell, I really had to do this in Git Bash.
Lastly I deleted the second clone repo (myRepo2 in the example) and went back to my first repo and I could finally do all the Git stuff like normal in my favorite editor VSCode.
When the remote server wants to connect to the private repo, it would authenticate via ssh.
Create the private-public key pair with ssh-keygen or if you already have the public-private key. copy&paste the public key in the Settings of the private repo.
YourPrivateRepo -> Settings -> Deploy Keys -> Add deploy key -> Paste the public key.
Now the remote server would be able to connect to the private repo.
NOTE: The deploy keys has access only for reading the repo. Need to explicitly allow write access.
If you are using git for Windows.
Open the git GUI.
Open the local git repository in git GUI.
Add the remote or push if the remote already exists.
Answer "yes" to the question about whether you want to continue.
The GUI client adds the key for you to ~/.ssh/known_hosts. This is easier to remember if you don't do it often and also avoids the need to use the git command line (the standard Windows command lines don't have the ssh-keyscan executable.
The solutions mentioned here are great, the only missing point is, what if your public and private key file names are different than the default ones?
Create a file called "config" under ~/.ssh and add the following contents
Host github.com
IdentityFile ~/.ssh/github_id_rsa
Replace github_id_rsa with your private key file.
I was facing the same error inside DockerFile during build time while the image was public. I did little modification in Dockerfile.
RUN git clone https://github.com/kacole2/express-node-mongo-skeleton.git /www/nodejs
This would be because using the git#github.com:... syntax ends up > using SSH to clone, and inside the container, your private key is not > available. You'll want to use RUN git clone > https://github.com/edenhill/librdkafka.git instead.
Check permissions on the known_hosts file as well - both the user's (~/.ssh/known_hosts) and the global one (/etc/ssh/ssh_known_hosts).
In my case the old host was in /etc/ssh/ssh_known_hosts. When I removed it as root with sudo ssh-keygen -f /etc/ssh/ssh_known_hosts -R THE_HOST it changed permissions on that file to 0600, so SSHing to THE_HOST as root worked, but for any other user it failed with "Host key verification failed". The fix was:
sudo chmod 644 /etc/ssh/ssh_known_hosts
One small addition to Tupy's answer, you may need to add the port number for your repository host:
ssh-keyscan -p 8888 -t rsa domain.example >> ~/.ssh/known_hosts
If you have another machine that does have remote access you can find the port number by viewing ~/.ssh/known_hosts:
[user]$ less ~/.ssh/known_hosts
[domain.example]:8888,[000.00.000.000]:8888 ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCi...
Its means your remote host key was changed (May be host password change),
Your terminal suggested to execute this command as root user
$ ssh-keygen -f "/root/.ssh/known_hosts" -R [www.website.net]
You have to remove that host name from hosts list on your pc/server. Copy that suggested command and execute as a root user.
$ sudo su // Login as a root user
$ ssh-keygen -f "/root/.ssh/known_hosts" -R [www.website.net] // Terminal suggested command execute here
Host [www.website.net]:4231 found: line 16 type ECDSA
/root/.ssh/known_hosts updated.
Original contents retained as /root/.ssh/known_hosts.old
$ exit // Exist from root user
Try Again, Hope this works.
You kan use https instead of ssh for git clone or git pull or git push
ex:
git clone https://github.com/user/repo.git
Reason seems to be that the public key of the remote host is not stored or different from the stored one. (Be aware of security issues, see Greg Bacon's answer for details.)
I was used to git clone prompting me in this case:
The authenticity of host 'host.net (10.0.0.42)' can't be established.
ECDSA key fingerprint is 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00.
Are you sure you want to continue connecting (yes/no)?
Not sure, why this error is thrown instead. Could be the configuration of your shell or the git SSH command.
Anyhow, you can get the same prompt by running ssh user#host.net.
A other alternative worked for me, instead of cloning the SSH link
git#gitlab.company.net:upendra/mycode.git
there is a option to select http link
http://gitlab.company.net:8888/upendra/mycode.git
So I used http link to clone for Visual studio and it worked for me
If you are not using a Windows Session to update the code, and you use PortableGit, you need to set the HOMEPATH environment variable before running the git command.
This example fits better for other use case, but I think it is a good of proof-of-concept for this post.
$env:HOMEPATH="\Users\Administrator";C:\path\to\PortableGit\bin\git.exe -C C:\path\to\repository.git pull'
Pushing to Git returning Error Code 403 fatal: HTTP request failed
Check if there is Billing issue.
Google Cloud stops uploading files to https://source.cloud.google.com/
I got this problem went away after Payment issue was fixed.
But did not change the Keys.
Thanks
Dashboard > Manage Jenkins > Configure Global Security > Git Host Key Verification Configuration.
Then in Host Key Verification Strategy select Accept first connection.
You can use your "git url" in 'https" URL format in the Jenkinsfile or wherever you want.
git url: 'https://github.com/jglick/simple-maven-project-with-tests.git'
Alternatively, if you're using MSYS2 terminals (on Windows*) and a passphrase, it might be that the terminal does not prompt the 'Enter passphrase' properly, thus denying access to SSH.
If you're on Windows, you can instead use the Git Bash or Powershell to get the prompt and properly connect. (I'm currently looking for a solution for MSYS.)
*Not sure if relevant.
Problem:
Host key verification failed.
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
Solution: I've checked all the settings and also checked the key settings in GitHub. Finally, I changed the Git URL from "git#github.com:palvsv/travelo-moon.git" to "https://github.com/palvsv/travelo-moon.git" in .config file "yourprojectdirectory/.git/config" and it works.
for me, I just rename the "known_hosts" file to "known_hosts.del" for backup. and then rerun git clone xxx and type "yes". I will create new "known_hosts"
Just type 'yes' and press enter this should work
When the terminal shows:
Are you sure you want to continue connecting (yes/no)?
DO NOT I repeat DO NOT directly pressed Enter.
You MUST TYPE yes first in the terminal, then press Enter.
I had the similar issue, unfortunately I used the GitExtensions HMI and forgot that I wrote a passphrase.
With HMI.... forget it ! Do not enter passphrase when you generate your key !
I got this message when I tried to git clone a repo that was not mine. The fix was to fork and then clone.
I'm attempting to clone a repo from my BitBucket account to my Windows 10 laptop (running GitBash). I've completed all of the steps necessary to connect (set up my SSH key, verified by successfully SSHing git#bitbucket.org, etc). However, whenever I attempt to clone a repo, the prompt continually hangs up after confirming that I want to cache Bitbucket's key.
User#Laptop MINGW64 /C/Repos
$ git clone git#bitbucket.org:mygbid/test.git
Cloning into 'test'...
The server's host key is not cached in the registry. You
have no guarantee that the server is the computer you
think it is.
The server's rsa2 key fingerprint is:
ssh-rsa 2048 97:8c:1b:f2:6f:14:6b:5c:3b:ec:aa:46:46:74:7c:40
If you trust this host, enter "y" to add the key to
PuTTY's cache and carry on connecting.
If you want to carry on connecting just once, without
adding the key to the cache, enter "n".
If you do not trust this host, press Return to abandon the
connection.
Store key in cache? (y/n) y
No files are cloned, and the result is an empty repo. Trying to initiate a git pull origin master from this repo also asks to cache the key, then hangs with no feedback. Despite not asking for the key to be cached when I do a test SSH, git operations always ask for the key every time before failing.
With no error messages to work with, I'm really at a loss as to what is wrong. I've tried multiple repos, including very small ones, with no success at all.
I had this problem when cloning a repo on Windows 10 too.
I got around it by using the Putty GUI to SSH to the server in question (in your case: bitbucket.org) then clicked 'Yes' when the prompt asks if you want to save the server key to the cache. Running the clone command again then worked for me!
Open Putty
Type in the Host Name (like bitbucket.org)
Click Open
Click yes in the popup to cache the host key
Close Putty
I managed to get it working by running plink directly, after pageant is running use the plink command directly - plink.exe -agent -v git#github.com then after this git works without hanging.
To do this from powershell open a powershell window and paste in the following:
echo y | & 'C:\Program Files (x86)\GitExtensions\PuTTY\plink.exe' -ssh git#github.com
echo y | & 'C:\Program Files (x86)\GitExtensions\PuTTY\plink.exe' -ssh git#gist.github.com
echo y | & 'C:\Program Files (x86)\GitExtensions\PuTTY\plink.exe' -ssh git#bitbucket.org
or with PuTTY standalone version:
echo y | & 'C:\Program Files (x86)\PuTTY\plink.exe' -ssh git#github.com
echo y | & 'C:\Program Files (x86)\PuTTY\plink.exe' -ssh git#gist.github.com
echo y | & 'C:\Program Files (x86)\PuTTY\plink.exe' -ssh git#bitbucket.org
Also worth knowing is that putty stores known hosts under a registry key:
HKEY_CURRENT_USER\SoftWare\SimonTatham\PuTTY\SshHostKeys
To shortcut the above you could put the following in a .reg file and run it:
Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\SOFTWARE\SimonTatham\PuTTY\SshHostKeys]
"rsa2#22:github.com"="0x23,0xab603b8511a67679bdb540db3bd2034b004ae936d06be3d760f08fcbaadb4eb4edc3b3c791c70aae9a74c95869e4774421c2abea92e554305f38b5fd414b3208e574c337e320936518462c7652c98b31e16e7da6523bd200742a6444d83fcd5e1732d03673c7b7811555487b55f0c4494f3829ece60f94255a95cb9af537d7fc8c7fe49ef318474ef2920992052265b0a06ea66d4a167fd9f3a48a1a4a307ec1eaaa5149a969a6ac5d56a5ef627e517d81fb644f5b745c4f478ecd082a9492f744aad326f76c8c4dc9100bc6ab79461d2657cb6f06dec92e6b64a6562ff0e32084ea06ce0ea9d35a583bfb00bad38c9d19703c549892e5aa78dc95e250514069"
"rsa2#22:gist.github.com"="0x23,0xab603b8511a67679bdb540db3bd2034b004ae936d06be3d760f08fcbaadb4eb4edc3b3c791c70aae9a74c95869e4774421c2abea92e554305f38b5fd414b3208e574c337e320936518462c7652c98b31e16e7da6523bd200742a6444d83fcd5e1732d03673c7b7811555487b55f0c4494f3829ece60f94255a95cb9af537d7fc8c7fe49ef318474ef2920992052265b0a06ea66d4a167fd9f3a48a1a4a307ec1eaaa5149a969a6ac5d56a5ef627e517d81fb644f5b745c4f478ecd082a9492f744aad326f76c8c4dc9100bc6ab79461d2657cb6f06dec92e6b64a6562ff0e32084ea06ce0ea9d35a583bfb00bad38c9d19703c549892e5aa78dc95e250514069"
"rsa2#22:bitbucket.org"="0x23,0xb9b88df3578371a7eb80c78bcda14fb30da436f11ca932a5fd5a8b6adfcc681df7a59cb4cb7ac966d9eac11daa38ebdbc0a6582a210ed4ee95a8d101c4abc925e942ab47535d64f9a5b3b68035c2ea1e900d709a1e8ea938718f532f9805a190446b92bac3040126225ae9d8374bc2008f106979d631734c7453f78c70091f4783b288869cb3c1941a784cd9baad823be27333833dc1f488a45b85952be75cf0a64965662302e3915378dcd5cfcd3ec903d804a29dff2fdf19df5deba4534b09e4dea6e44f152e339b3c43be98ddadfc56533192e216a3d673f00b4aa9cc9e7870acd8b6adb7e0feb77f2292fc2dede94819def3eb1e785541a06ab31ccf725f"
putty-hosts.reg gist
To workaround this problem I configured GitBash to use plink with -batch option. The option disables all prompts - the plink will terminate without hanging and won't add any key fingerprint to cache.
To add -batch parameter to plink command executed by GitBash you can set a git config option:
git config --global core.sshCommand "plink -batch"
Or set GIT_SSH_COMMAND environment variable.
The output when you cloning a repo from unknown host will be similar to this:
The server's host key is not cached in the registry. You
have no guarantee that the server is the computer you
think it is.
The server's rsa2 key fingerprint is:
ssh-rsa 2048 97:8c:1b:f2:6f:14:6b:5c:3b:ec:aa:46:46:74:7c:40
Connection abandoned.
fatal: Could not read from remote repository.
After this message you can add a key to cache with command:
echo y | plink git#bitbucket.org
REMARK: Please check if plink is in your PATH. Alternatively use UNIX-like path in the GitBash config option, e.g.:
/c/Program\ Files/PuTTY/plink.exe -batch
Even after performing the workaround mentioned in other answers, you may encounter an error like:
FATAL ERROR: Disconnected: No supported authentication methods available (server sent: publickey)
To solve both problems at once, change git bash to use SSH instead of PuTTY by adding the following to your ~/.profile file (C:\Users\<Username>\.profile). If you don't already have this file, then create a new file with this line.
GIT_SSH="/usr/bin/ssh.exe"
Then open a new git bash window and try your git clone or git pull again.
Note that this may require you to create an SSH key if you don't already have one. To do this, follow the instructions on the Bitbucket site.
See this SO question for related info.
In your git bash shell, check for existence of GIT_SSH:
echo $GIT<tab><tab>
If it exists and is set to putty, execute:
unset GIT_SSH
You'll probably want to put this into one of the git bash startup scripts.
This is NOT a universal solution. It worked in our particular case.
It sounds a bit silly, but after trying all of the above, I decided to reinstall Git Bash with default options and it worked.
If you use KiTTY (instead of PuTTY), it has -auto-store-sshkey argument.
So, you can set GIT_SSH_COMMAND (or git config --global core.sshCommand) to something like c:/KiTTY/klink.exe -auto-store-sshkey.
The output still contains information about new key and the question, but it doesn't wait for the answer:
The server's host key is not cached in the registry. You
have no guarantee that the server is the computer you
think it is.
The server's ssh-ed25519 key fingerprint is:
ssh-ed25519 255 2e:65:6a:c8:cf:bf:b2:8b:9a:bd:6d:9f:11:5c:12:16
If you trust this host, enter "y" to add the key to
PuTTY's cache and carry on connecting.
If you want to carry on connecting just once, without
adding the key to the cache, enter "n".
If you do not trust this host, press Return to abandon the
connection.
Store key in cache? (y/n)
Autostore key is on
Default SSH port to connect to is 7999
my machine setup is as follows:
windows 7, Git for windows,Git Bash, openSSH 1.6 installed via cygwin.
I followed the instructions on https://help.github.com/articles/generating-ssh-keys
But I still have to login in everytime I push something.
I guess my setup is messed up... any help is very much appreciated.
To be able to use key-based authentication (instead of HTTP basic-auth), you have to use the SSH-Protocol. On Github, the URLs look like this:
git#github.com:username/repository.git
Once you use key authentication, you can use the common SSH tools to manage the connections. One of these tools is the SSH agent which will decrypt your private key once after loading and keep it in main memory while it is running. This allows new SSH sessions to use this key without having to bother you with a password-question.
You can add a private key to the current SSH agent session by running
ssh-add /path/to/key
If you want to remove the passphrase and it annoys you then enter:
ssh-keygen -p
enter the old passphrase and when asks for the new one, just leave it empty.
I now got it working kinda...
At first I uninstalled the ssh package from cygwin since git for windows ships with ssh.
like Holger said I had to add the key to the ssh-agent but from the git bash I was not able to add it. It worked like this:
eval 'ssh-agen.exe'
ssh-add ~/.ssh/id_rsa
After this I was able to push without entering a passphrase.
The only problem got left is that I have to add the key after every system reboot...
ANy ideas how to fix this?
These instructions are for Windows 7 and above.
Create a filename named .bashrc in your home directory (so full file path is C:\Users\XYZ\.bashrc where XYZ is your windows user name
In the file add these two lines. Note: change location of private key file if not at ~/.ssh/id_rsa
eval `ssh-agent`
ssh-add ~/.ssh/id_rsa
Open Git Bash application and you should be prompted with asking for your key's password
Is there a way to save the password of a ssh-connection inside an uri-link. AFAIK a uri can look like this username:password#domain/path. But the following example doesn't work on ubuntu:
ssh user:pass#domain/path
I always receive a "please enter password"-question. I know that it is not a quite secure way to save the password in plain text inside a link, but I have to work with other developers and what should I say... they are ex-Windows user, they don't like terminals and therefore I want to write a tiny shell script. this script should clone a remote git repo and create some specific stuff.
One click and I should do some magic!
You should use a ssh-key generated with ssh-keygen (man ssh-keygen). This is also available on the windows platform within the putty environment.
eval $(ssh-agent)
ssh-add ssh./yourkeyfilewithoutpassphrase
ssh user#sshserver "your remote command"
Befor you can use your ssh-key in the remotehost, you must insert the public key to the authorized_keys file. A convenient way is the command
ssh-copy-id -i ssh./yourkeyfilewithoutpassphrase.pub user#sshserver
or, if the key is already loaded by the ssh-agent
ssh-copy-id user#sshserver
After this point, you dont need any password for ssh connection to established remote hosts. You should use per user a different ssh-key, so you are able to enable and disable keys without bothering the other users.
You can't login with input password using ssh.
Another alternate way is setup a pair of ssh-keys, and login using ssh-key.
I follow the guide here: http://www.softwareprojects.com/resources/programming/t-ssh-no-password-without-any-private-keys-its-magi-1880.html
AFAIK, the commands ssh or scp do not have/take a password parameter. Otherwise I could keep the password in a shell variable and probably get rid of the enter password prompt. If I write an scp command in my shell script, it prompts the user to input the password. I have multiple ssh and scp commands in my script and I do not want the user to enter the password every time. I would prefer to save the password in a shell variable in the beginning (by asking password once), then use it for every ssh or scp.
I read about "public key identification" in this question. Is it related to the solution I am looking for?
Update
I read in How to use ssh command in shell script? why it is unsafe to specify passwords on the commandline. Does using expect also store the password and is world visible (using ps aux)? Is that the security issue with using expect?
Further Explanation
To further make it clear, I am writing this shell script to automate code and database backup, do code upload, run necessary database queries, do all the things that are needed for a new version release of a LAMP project from a developer system to a remote live server. My shell script will be there inside the main codebase of the project in every developer instance.
Requirement
I want all developers (all may be working from different remote systems) knowing the SSH/FTP password to be able to use the shell by entering the ssh/ftp password same only at run-time once. I would prefer the password to be the ssh/ftp password
Note - I do not want other developers who don't know the SSH password to be able to use it (So I guess public key authentication will not work because it stores the passwords in the systems).
I do not want any command line solution which stores the password in some log in the system and can be world visible using ps aux or something.
Opening Bounty
From all the answers so far and my anaylsis of those solutions, it looks like other than public key authentication all others are insecure. I am not yet sure if using expect is insecure. I think it is otherwise the correct solution for me. In that case, I am getting command not found errors while trying to do that as already commented on one of the answers.
From http://www.debianadmin.com/sshpass-non-interactive-ssh-password-authentication.html -
First and foremost, users of sshpass
should realize that ssh’s insistance
on only getting the password
interactively is not without reason.
It is close to be impossible to
securely store the password, and users
of sshpass should consider whether
ssh’s public key authentication
provides the same end-user experience,
while involving less hassle and being
more secure.
So, is it not possible to securely run multiple ssh, scp commands by entering the ssh/ftp password (if only once at runtime? Please read my Requirement section again.
Also, can anyone explain this -
In particular, people writing programs
that satisfies are meant to
communicate the above points)password
programatically are encouraged to use
an anonymous pipe and pass the pipe’s
reading end to sshpass using the -d
option.
Does this mean anything is possible?
Indeed, you'll definitely want to look into setting up ssh keys, over saving a password in a bash script. If the key is passwordless, then no user input will be required to ssh/scp. You just set it up to use the key on both ends and voila, secured communication.
However, I'll get downvoted to hell if I don't say this. Many consider passwordless ssh keys to be a Bad Idea(TM). If anybody gets their hands on the keys, the have full access. This means that you are relying on other security measures such as file permissions to keep your password safe.
Also, look into ssh-agent. It allows you to set it up so that you have a password protected ssh-key, but you only need to type it in once and it will manage the password for the key for you and use it when necessary. On my linux box at home, I have ssh-agent set up to run in my .xinitrc file so that it prompts me once and then starts X. YMMV.
UPDATE:
With regards to your requirements, password protected public key authentication + ssh-agent still seems to fit. Only the developers privy to the SSH/FTP password could start up ssh-agent, type in the password and ssh-agent would manage the passwords for the public keys for the rest of the session, never requiring interaction again.
Of course, how it stores it is another matter entirely. IANASE, but for more information on security concerns of using ssh-agent, I found symantec's article to be pretty informative: http://www.symantec.com/connect/articles/ssh-and-ssh-agent
"The ssh-agent creates a unix domain
socket, and then listens for
connections from /usr/bin/ssh on this
socket. It relies on simple unix
permissions to prevent access to this
socket, which means that any keys you
put into your agent are available to
anyone who can connect to this socket.
[ie. root]" ...
"however, [..] they are only usable
while the agent is running -- root
could use your agent to authenticate
to your accounts on other systems, but
it doesn't provide direct access to
the keys themselves. This means that
the keys can't be taken off the
machine and used from other locations
indefinitely."
Hopefully you're not in a situation where you're trying to use an untrusted root's system.
The right way to do that is as follows:
Ensure that all your users are using ssh-agent (nowadays this is the default for most Linux systems). You can check it running the following command:
echo $SSH_AUTH_SOCK
If that variable is not empty, it means that the user is using ssh-agent.
Create a pair of authentication keys for every user ensuring they are protected by a non empty passphrase.
Install the public part of the authentication keys on the remote host so that users can log there.
You are done!
Now, the first time an user wants to log into the remote machine from some session it will have to enter the passphrase for its private key.
In later logins from the same session ssh-agent will provide the unlocked key for authentication in behalf of the user that will not be required to introduce the passphrase again.
Ugh. I hit the man pages hard for this. Here's what I got:
Use this code near the beginning of the script to silently get the ssh password:
read -p "Password: " -s SSHPASS # *MUST* be SSHPASS
export SSHPASS
And then use sshpass for ssh like so:
sshpass -e ssh username#hostname
Hope that helps.
You can Using expect to pass a password to ssh do this or as said already use public key authentication instead if that's a viable option.
For password authentication, as you mentioned in you description, you can use "sshpass". On Ubuntu, you can install as "sudo apt-get install sshpass".
For public/private key-pair base authentication,
First generate keys using, "ssh-keygen"
Then copy your key to the remote machine, using "ssh-copy-id username#remote-machine"
Once copied, the subsequent logins should not ask for password.
Expect is insecure
It drives an interactive session. If you were to pass a password via expect it would be no different from you typing a password on the command line except that the expect script would have retrieve the password from somewhere. It's typically insecure because people will put the password in the script, or in a config file.
It's also notoriously brittle because it waits on particular output as the event mechanism for input.
ssh-agent
ssh-agent is a fine solution if this is script that will always be driven manually. If there is someone who will be logged in to drive the execution of the script than an agent is a good way to go. It is not a good solution for automation because an agent implies a session. You usually don't initiate a session to automatically kick of a script (ie. cron).
ssh command keys
Ssh command keys is your best bet for an automated solution. It doesn't require a session, and the command key restricts what runs on the server to only the command specified in the authorized_keys. They are also typically setup without passwords. This can be a difficult solution to manage if you have thousands of servers. If you only have a few then it's pretty easy to setup and manage.
service ssh accounts
I've also seen setups with password-less service accounts. Instead of the command entry in tehh authorized_keys file, and alternative mechanism is used to restrict access/commands. These solutions often use sudo or restricted shells. However, I think these are more complicated to manage correctly, and therefore tend to be more insecure.
host to host automatic authentication
You can also setup host 2 host automatic authentication, but there are alot of things to get write to do this correctly. From setting up your network properly, using a bastion host for host key dissemination, proper ssh server configuration, etc. As a result this is not a solution a recommend unless you know what your doing and have the capacity and ability to set everything up correctly and maintain it as such.
For those for who setting up a keypair is not an option and absolutely need to perform password authentication, use $SSH_ASKPASS:
SSH_ASKPASS - If ssh needs a passphrase, it will read the passphrase from the current terminal if it was run from a terminal. If ssh does not have a terminal associated with it but DISPLAY and SSH_ASKPASS are set, it will execute the program specified by SSH_ASKPASS and open an X11 window to read the passphrase. This is particularly useful when calling ssh from a .xsession or related script. (Note that on some machines it may be necessary to redirect the input from /dev/null to make this work.)
E.g.:
$ echo <<EOF >password.sh
#!/bin/sh
echo 'password'
EOF
$ chmod 500 password.sh
$ echo $(DISPLAY=bogus SSH_ASKPASS=$(pwd)/password.sh setsid ssh user#host id </dev/null)
See also Tell SSH to use a graphical prompt for key passphrase.
Yes, you want pubkey authentication.
Today, the only way I was able to do this in a bash script via crontab was like that:
eval $(keychain --eval --agents ssh id_rsa id_dsa id_ed25519)
source $HOME/.keychain/$HOSTNAME-sh
This is with the ssh agent already running and to achieve that it was needed the passphrase.
ssh, ssh-keygen, ssh-agent, ssh-add and a correct configuration in /etc/ssh_config on the remote systems are necessary ingredients for securing access to remote systems.
First, a private/public keypair needs to be generated with ssh-keygen. The result of the keygen process are two files: the public key and the private key.
The public key file, usually stored in ~/.ssh/id_dsa.pub (or ~/.ssh/id_rsa.pub, for RSA encryptions) needs to be copied to each remote system that will be granting remote access to the user.
The private key file should remain on the originating system, or on a portable USB ("thumb") drive that is referenced from the sourcing system.
When generating the key pair, a passphrase is used to protect it from usage by non-authenticated users. When establishing an ssh session for the first time, the private key can only be unlocked with the passphrase. Once unlocked, it is possible for the originating system to remember the unlocked private key with ssh-agent. Some systems (e.g., Mac OS X) will automatically start up ssh-agent as part of the login process, and then do an automatic ssh-add -k that unlocks your private ssh keys using a passphrase previously stored in the keychain file.
Connections to remote systems can be direct, or proxied through ssh gateways. In the former case, the remote system only needs to have the public key corresponding to the available unlocked private keys. In the case of using a gateway, the intermediate system must have the public key as well as the eventual target system. In addition, the original ssh command needs to enable agent forwarding, either by configuration in ~/.ssh/config or by command option -A.
For example, to login to remote system "app1" through an ssh gateway system called "gw", the following can be done:
ssh -At gw ssh -A app1
or the following stanzas placed in the ~/.ssh/config file:
Host app1
ForwardAgent = yes
ProxyCommand = ssh -At gw nc %h %p 2>/dev/null
which runs "net cat" (aka nc) on the ssh gateway as a network pipe.
The above setup will allow very simple ssh commands, even through ssh gateways:
ssh app1
Sometimes, even more important than terminal sessions are scp and rsync commands for moving files around securely. For example, I use something like this to synchronize my personal environment to a remote system:
rsync -vaut ~/.env* ~/.bash* app1:
Without the config file and nc proxy command, the rsync would get a little more complicated:
rsync -vaut -e 'ssh -A gw' app1:
None of this will work correctly unless the remote systems' /etc/ssh_config is configured correctly. One such configuration is to remove "root" access via ssh, which improve tracking and accountability when several staff can perform root functions.
In unattended batch scripts, a special ssh key-pair needs to be generated for the non-root userid under which the scripts are run. Just as with ssh session management, the batch user ssh key-pair needs to be deployed similarly, with the public key copied to the remote systems, and the private key residing on the source system.
The private key can be locked with a passphrase or unlocked, as desired by the system managers and/or developers. The way to use the special batch ssh key, even in a script running under root, is to use the "ssh -i ~/.ssh/id_dsa" command options with all remote access commands. For example, to copy a file within a script using the special "batch" user access:
rsync -vaut -e 'ssh -i ~batch/.ssh/id_dsa -A gw' $sourcefiles batch#app2:/Sites/www/
This causes rsync to use a special ssh command as the remote access shell. The special-case ssh command uses the "batch" user's DSA private key as its identity. The rsync command's target remote system will be accessed using the "batch" user.