All the public keys of our users are in our LDAP. Gitolite already gets the usernames and groups out of this LDAP. But for each new user, we have to manually add the userkey to the keydir of gitolite.
Is there a way of letting gitolite automatically get the keys directly from LDAP?
the gitolite gets the users from the authorizedkyes file. This file is generated when you add a new public key to the keys folder.
You have to configure your ssh to use external command for authorized keys file. From OpenSSH 6.1 you can use AuthorizedKeysCommand (for the external command) and AuthorizedKeysCommandUser (under the id the command will run). You have to write your own script or adjust one from the internet to provide the proper output. The command takes one option (uid) and give back the list of public keys ot the user.
If you check the authorized keys of the gitolite it looks more advanced.
command="/usr/share/gitolite/gl-auth-command username",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa AAAAB3Nza
So you have to adjust your script to generate such an output if the user match with your gitolite user (normally git or gitolite).
Related
For convenience purposes I don't have a "default" private key, usually ~/.ssh/id_rsa, ~/.ssh/id_dsa or ~/.ssh/identity. I have multiple keys to manage multiple accounts, one for work and one for personal. I use SSH agent forwarding to get proper authentication. It all works just fine.
The problem I have is after every logoff/reboot, the SSH agent does not automatically add the my keys because, it seems, it only looks for the default named keys, as stated by GitHug at: Error: Permission denied (public key): Make sure you have a key that is being used.
Is there a way to define what keys the SSH agent should automatically add upon loading or will I have to manually add them each time? Possibly create a script that opens upon logon and adds them.
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....
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.
I had a working instance of Gitlab until a few weeks ago, when we had to move all the user directories to another disk b/c of resource constraints. I've gone through and fixed all the paths that I could find, and so now my gitlab instance is up and running again. Git appears to be working, and I pass the gitlab self-diagnostic test.
However, from a remote client that's previously worked, I get prompted to provide the git user's password, which suggests an ssh problem.
Looking in my .gitolite stuff (conf/gitolite.conf & the keydir), things look in order. My public key is in the keydir, and the rights are assigned in the gitolite.conf correctly.
EDIT: gitolite public keys were in the .ssh/authorized_keys file and the protections were as created by gitolite setup.
What am I missing?
My public key is in the keydir, and the rights are assigned in the gitolite.conf correctly.
This isn't enough.
For ssh to not ask you for a password, you need to check if your ~gitlab/.ssh/authorized_keys is complete (with the gitolite public keys in it, and with the right protections)
Check out the gitolite setup command (for gitolite V3).
I have a machine running gitolite that is used both for code repos and for Sparkleshare. The problem is that Sparkleshare creates it's own key pair; that key pair authenticates first, and has no permissions on the code repos, so gitolite terminates without trying any other pairs.
I'm thinking that I may need to figure out how to either tell Sparkleshare to use my original key, or write an alias that forces gitolite to use the correct private key--something I'm not sure is even possible.
Never having used SparkleShare, I am not quite sure of its requirements, but I read some of the documentation to try to get a feel for how it interacts with Git. It looks like it is designed to publish and pull data through a Git repository (it describes using “your own server”, Github, and Gitorious for data storage/transfer/sync/whatever).
In the following I am assuming that you want to serve both your SparkleShare repository and other non-SparkleShare repositories through the same Gitolite installation (so that you can use Gitolite to control access to both kinds of repositories).
It seems to me that it will probably work just fine with a Gitolite-hosted repository if you follow Gitolite’s rules for giving access instead of the generic “Git over SSH” that is described in SparkeShare’s “use your own server” documentation.
In particular, do not use ssh-copy-id, or cat keyfile >> .ssh/authorized_keys to install public keys into the Gitolite user’s .ssh/authorized_keys. This effectively gives the owners of those public keys “administrative access” to the Gitolite installation (e.g. the ability to completely delete the Gitolite installation and anything else stored under that account). Instead, you should add users through Gitolite to grant new SparkeShare users access to a Gitolite-hosted repository (make and push changes in your gitolite_admin clone: put the user’s public key into keydir/newusername.pub and add newusername to the repository’s access lists in conf/gitolite.conf). You can even have multiple SSH keys associated with a single Gitolite user if you think that is the way to go.
If you find that you absolutely must still have users with both “full access” keys (no command=) and Gitolite-managed keys (keys with command=, managed through keydir/ in the Gitolite admin repository) in the same account’s .ssh/authorized_keys, then you may find that you can force ssh clients to supply only certain specified keys via the IdentitiesOnly parameter (see ssh_config(5)).
Assuming that you can access Gitolite through Git URLs like git#server.example.com:projectA.git, then configure each client like this:
Host sparkleshare
User git
HostName server.example.com
IdentityFile ~/sparkelshare/pub_key
IdentitiesOnly yes
Host gitolite
User git
HostName server.example.com
IdentityFile ~/.ssh/id_rsa # or the user's normal, non-SparkleShare key
IdentitiesOnly yes
In SparkleShare, set “my own server” to sparkleshare (or git#sparkleshare if it demands a user part) and set the “folder name” to our-sparkleshare.git (whatever the “Gitolite path” to the repository is, not the “full server site path” since access will be going though Gitolite and it expects paths relative to its REPO_BASE setting).
For non-SparkleShare access, use Git URLs like gitolite:projectA.git