I have a server which will run various ansible playbooks on host groups in my infrastructure. I have seen various questions about this, with the end result being something like use ssh-agent and ssh-add to initially add the key and enter the passphrase. But there are conflicting discussions that say, you can't do anything about user input when configuring a server using ansible (i.e. echoing the input when prompted).
So if I automate the ansible server and need to add the keys, there's not a way for me to authenticate using the passphrase for any subsequent ansible-playbook runs from that server to the appropriate machines.
Is there to use a passphrase protected key with ansible playbook without requiring human interaction?
No, it defeats the purpose of using a password protected private key by bypassing the step of entering the password. If you are using some other method to authenticate the user that you are confident with then you could use a non-password protected private key but then you would need to have very good processes for managing your private key.
The point of ssh-agent is that you only need to enter the private key password once and not for each host you connect to or each time the session times out, it is not to bypass authenticating the owner of the private key.
Related
As in the title. I WANT to type in my password every time I do a git push or pull. Currently, it prompts me to enter in the passphrase every restart and then caches it, but I don't want that.
I'm not sure what I did to cause this as it never happened before on any of my other machines across the years
With SSH, only a passphrase (if you have created a private SSH key protected with a passphrase) would be asked, then cached by the ssh-agent.
Typing a password would mean using an HTTPS URL (one requiring your remote GitHub or GitLab user account name, and password or token).
I am using Windows machine and I have WinSCP installed.
I am writing a script that logs in to the server and downloads file.
I do not want to store account password in the script. Is there anyway I can login to server with some-kind of host-key or private-key or something.
Yes, you can use the public key authentication. But for that you still have to store the private key along with your script. Normally the key is encrypted with a passphrase. To automate the login, you would have to store the passphrase to the script file anyway (using the -passphrase switch). So still, if anyone gets an access to your machine, he/she is still able to steal your identity, just as with the password. Though there's an advantage. You can have multiple keys (while only one password). If you use a special key for the script and the key is ever compromised, you can revoke it, while keeping the other keys.
Note that, if you are not absolutely sure of the physical and electronic security of the system on which you are connecting, there's hardly any way to setup an automatic authentication. If you are sure about the security, storing password in the script file is just ok.
Anyway, your question is mostly duplicate of:
How do I setup Public-Key Authentication?
For WinSCP specifics, see the guide to Setting up SSH public key authentication.
See also the WinSCP guide to Protecting credentials used for automation.
I had a similar issue on windows so I used Putty instead http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html
If you need to generate a public key then use: http://the.earth.li/~sgtatham/putty/latest/x86/puttygen.exe
I gave the public key + password to whoever owned the SFTP server to install it on his side.
I saved the private key on my side lest say on "C:\privatekey.ppk"
You don't use password on your script but you link to the private which you must have on you machine.
Then, when you want to automate a batch to download from the FTP server the Pageant in order to load the private key into session http://the.earth.li/~sgtatham/putty/latest/x86/pageant.exe
Then use the PSFTP to connect and perform actions http://the.earth.li/~sgtatham/putty/latest/x86/psftp.exe
So here is sample code for the batch file:
!--Loading the key to session--!
#C:\pageant.exe "C:\privatekey.ppk"
!--Calling the PSFTP.exe with the uaser and sftp address + command list file--!
#C:\psftp user#your.server.address -b C:\sftp_cmd.txt
Command list file (sftp_cmd.txt) will like like this:
mget "*.*" !--downloading every thing
!--more commands can follow here
close
Now, all you need to to schedule it in scheduled tasks *I wish it was simple as unix's cron job....
We have a 'master' Mercurial server on our network that we use for a local staging box. Our team does all of our pushes and pulls to/from this one box. I'm having trouble with the implementation I'm using, but I'm also second guessing whether what I want to do is even a good idea...
We also want to start using BitBucket, but only as a secondary server. I'd like to use a hook to automatically push to Bitbucket, but I can't get it working right...
Here's the HGRC from the 'master' repo:
[hooks]
changegroup =
changegroup.update = hg update
changegroup.bitbucket = hg push ssh://hg#bitbucket.org/account/repo
If I manually fire off the above push, everything works perfectly. However, as a hook it fails:
warning: changegroup.bitbucket hook exited with status 255
I followed this guide to get SSH working: Set up SSH for Git and Mercurial on Mac OSX/Linux
I get my keys generated, I run ssh-agent, and I ssh-add the key. But ssh-agent doesn't seem to be doing anything, and as soon as I exit the SSH session it seems to leave memory. Additionally, when I test it out with ssh -Tv hg#bitbucket.org it prompts me for my password. I thought the whole point of this was for it not to do that?
But taking a step back, maybe this is a terrible idea to being with. If I give my public key to Bitbucket wouldn't that theoretically mean if someone got a hold of it, they could SSH in to my box without a password?
And if so, what alternative do I have to forward commits to bitbucket? I'd rather not use HTTPS because it would require putting our bitbucket password as plain/text in the .hg/hgrc file...
Maybe there's some more obvious way to do this that I'm missing? For the developers, I'd rather keep things the way they are now (everyone push to master) instead of reconfiguring everyone's developer box to have a private key and to push to bitbucket instead...
As always, thanks for any help you guys can provide.
Woah, there are a lot of questions there. I'll hit a few of 'em:
But ssh-agent doesn't seem to be doing anything, and as soon as I exit the SSH session it seems to leave memory.
You're correct. ssh-agent is for interactive sessions, not for automation. In most usages when you log out it's killed, but even if that weren't the case it wouldn't be working as you imagine because when someone does that hg push they're running a new, non-interactive session that wouldn't have access to the ssh-agent anyway
Additionally, when I test it out with ssh -Tv hg#bitbucket.org it prompts me for my password.
Testing it out like that isn't valid. That's saying "I want to log into an interactive session at bitbucket with the username hg", but that's not what they authorize you to do. If you send them your public key they let you login as the user hg only for the purposes of doing hg non-interactive commands.
Additionally, when I test it out with ssh -Tv hg#bitbucket.org it prompts me for my password.
No, public keys are meant to be public -- you can list anyone's on github for example. The public key just says "anyone who has the private key that matches this is authorized to...", so any site that wants your private key are crooks, but any site that wants you public key is just offering you a way to use something better than a password.
One thing you may be missing about hooks is "who" the hook runs as. When people are pushing to your "centralish" repo over ssh that the hook is being run as their unix user, and if they're pushing over http the hook is being run as the web server's user.
If you had:
a private ssh key with no password on it
the public key matching that private key setup on bitbucket
the unix user running the hook using that private key for access to bitbucket.org
then what you're trying to do would work.
I'm using scp in a script, which normally should always use private key authentication. If for some reason the private key is missing, I want the script to fail rather than display a password prompt.
Is it possible to disable this prompt, or to somehow specify that private key authentication should always be used?
The option I was looking for is -B:
-B Selects batch mode (prevents asking for passwords or passphrases).
If you follow the GitHub HowTo "Generating SSH Keys", you get three files in your ~/.ssh directory: known_hosts, id_rsa, and id_rsa.pub.
The file known_hosts is used for the server authentication, id_rsa is used for the client authentification (here is an article, that explains the difference).
Why should I create / why GitHub does need both -- a host and a user authentification files? How does the GitHub authentification work?
Thx
This is just plain old SSH authentication; nothing about it is specific to GitHub.
id_rsa and id_rsa.pub are the two halves of your key: the private key and the public key. Effectively, the public key is the lock for the private key. You put the lock (public key) on whatever servers you want easy access to, without too much worry that someone else will see it, because it's just a lock. You keep the (private) key on your machine, and use it to log into those servers; they see you have a key fitting the lock, and let you in.
(Not to say that you should put your public key on completely untrustworthy machines; there are malicious tricks that can take advantage of shortcuts like ssh -A.)
known_hosts doesn't actually have much to do with this; it's just where ssh stores the fingerprints of all the servers you've connected to, so it can throw up a big scary warning if the fingerprint changes. (That would mean it's not the same machine: either something has changed radically on the server side, or your connection has been hijacked.)
So, anyway, one of the protocols Git itself understands is SSH. When you use git#github.com:... as a repository URL, Git is just connecting over SSH. Of course, GitHub doesn't want you mucking around on their machines, so they only let you do Git things, not get a full shell.
As usual, the Arch wiki has a whole lot more words on this.
known_hosts stores the server's identity the first time you connect, so that you know the next time that you're connecting to the same server. This prevents someone from pretending to be the server the next time you connect (but sadly not the first time)
id_rsa is your secret key that proves that you are really you. Never give this away.
id_rsa.pub is the public key, its purpose for authentication is basically just to prove that you have the secret key without giving it out. This key you can give to anyone what needs it since there's nothing secret about it.
When you connect to the server, SSH first checks that the server has the correct key (ie it should match the one in known hosts. If the client is comfortable that the server is genuine, it uses its private key to sign the following data and sends it to the server;
string session identifier
byte SSH_MSG_USERAUTH_REQUEST
string user name
string service name
string "publickey"
boolean TRUE
string public key algorithm name
string public key to be used for authentication
The server verifies the signature using the public key (which you earlier uploaded to Github), and if it is correct, the client is authenticated.
The known_hosts file is used by ssh whenever you actually connect to a host via SSH. It stores a signed key of sorts for the server. Then, if it changes, you will know.
ssh-keygen -t rsa -C yourgithub#accountemail.com is used to generate the SSH key in which you will give the id_rsa.pub to github. Then, when you connect to github you have the private key id_rsa in your ~/.ssh folder which is then used to validate your information with github.
This is a very low-level explanation, but the private key (non .pub) file is your end, the .pub is for github and the known_hosts is for your box to know what is what.
You can also generate a config file in ~/.ssh for use to specify which key goes to which host..
authorized_keys and known_hosts are entirely different..
Your SSH server (sshd, ie) uses authorized_keys, or whatever file is defined within your /etc/ssh/sshd_config/ for knowing the public side of another key. So when a user connects to your server, they pass their private key, your SSH server verifies against the public key it has within authorized_keys and if it doesn't match, it doesn't work.
Github maintains an authorized_keys so-to-speak on their users. Your public key goes into your authorized_keys on your account and then when you connect via ssh to clone,push,etc, it checks your private key you send over with your public key they already know.