We are using the community version of Tyk. When trying to add new API via file-based add, and then reloading - it doesn't seem to work! It produces this in logs.
tyk-gateway_1 | time="Jun 21 04:56:28" level=warning msg="Attempted administrative access with invalid or missing key!" prefix=main
When I execute this…
curl -H "x-tyk-authorization: '352d20ee67be67f6340b4c0605b044b7'" -s http://localhost:8080/tyk/reload/group | python3 -mjson.tool
I am 100% sure the docker-compose took secret listed in tyk.standalone.conf file. I even logged into the container created and checked “tyk.conf” and it has this very secret. Not sure what is wrong at this stage. It just doesn’t seem to recognize it as an admin key. Any advice?
Please check whether docker-compose.yaml file has the environment variable TYK_GW_SECRET set. If so, please use that value as secret as the environment variable takes precedence over the config values.
Please refer to https://tyk.io/docs/tyk-environment-variables/ for more information.
Please remove the single quote covering the secret value.
Please try with below command and let us know.
curl -H "x-tyk-authorization: 352d20ee67be67f6340b4c0605b044b7" -s http://localhost:8080/tyk/reload/group | python3 -mjson.tool
Related
I have a windows AD server machine (2012 windows), say 'abc.com'. From the client, I try with port '636' and '3269'.
With port '636' and base-dn set as 'DC=abc,DC=com' and bind-dn set as 'CN=Administrator,DC=abc,DC=com', I am able to lookup for a user and get its details.
However, when I try using global catalog port '3269', I get entry not found error for the same uesr. I tried to provide a blank (" ") for the base-dn and bind-dn in this case but that also couldn't help.
I am not sure how to make a successful search into the global catalog. Can someone help.
You need to use an ""<empty string" for the baseDN AND a scope=base.
Access does not even require authentication, although you may not get all the data you are looking for.
ldapsearch -H ldaps://example.net:3269 -b "" -s base -z 1000 "(objectClass=*)" "objectClass"
I'm not very familiar with OpenLDAP, but I'm trying to get a local instance working in order to test a client in development, which needs the memberOf attribute.
I've downloaded and installed OpenLDAP on a Centos 7 VM, per the instructions at http://www.openldap.org/doc/admin24/guide.html#A Quick-Start Guide. I did not use package management to install it. Since I'm using 2.4.45, it's using the cn=config OLC config and not the slapd.conf configuration scheme
At step 4 above, I used the --enable-memberof and --enable-refint flag to the configure script. When I ran the pre-install tests, it did run the memberof tests, and they passed, so I know the overlay can be applied somehow.
I've tried the directions found at https://adimian.com/blog/2014/10/how-to-enable-memberof-using-openldap/ and, with slight variants, many other places. I've run into the following issues with this...
Errors about an invalid objectClass oldModuleList during ldapadd
Insufficient access errors during ldapadd
I don't have a local directory that corresponds to the module path found in any of the examples. I don't seem to have the memberof.la file anywhere on the machine.
Is this even on the right track? Or will the process be different because I installed from source or used the --enable-memberof flag?
Let me know if there's any info I need to provide.
Update:
Currently, I am trying to add the entry with dn dn: olcOverlay={0}memberof,olcDatabase={1}hdb,cn=config as found in the linked instructions above. I get
# ldapadd -x -D "cn=Manager,dc=aaron,dc=com" -W -f member.ldif
Enter LDAP Password:
adding new entry "olcOverlay={0}memberof,olcDatabase={1}mdb,cn=config"
ldap_add: Insufficient access (50)
Another update:
Progress!
I added an olcRootPW to the cn=config database by editing
etc/slapd.d/cn=config/olcDatabase={0}config.ldif
then used that dn to run the ldapadd:
ldapadd -x -D "cn=config" -W -f member.ldif
I had to put the {0} and {1} back.
Trying to add the first refint ldif failed, but I think I don't need that since these aren't modules, but compiled directly into slapd based on how I configured it.
Now I'm trying to add the second refint entry and getting
[root#openldap openldap]# ldapadd -x -D "cn=config" -W -f refint2.ldif
Enter LDAP Password:
adding new entry "olcOverlay={1}refint,olcDatabase={1}mdb,cn=config"
ldap_add: Other (e.g., implementation specific) error (80)
additional info: olcRefintAttribute <manager>: attribute type undefined
So here's everything I had to do to get it working from my original issue:
Add an olcRootPW entry to the olcDatabase={0}config.ldif config entry. As EJP says, this is bad form, but since this is a local testing directory only, and I only want it to allow me to test a client...
Without the {0} and {1} items in the file, the load still failed. I but both back and it worked. I did not go back to check EJP's suggestion to only have the {1}.
Then the ldapadd command needs to be run with bind dn 'cn=config'. At that point the entry to enable the memberof config would add successfully.
I tried to add the first refint file, the one that does the module. This did not work, I got an error about the olcModuleList attribute. I think since I compiled the overlays directly into OpenLDAP via the --enable-memberof and --enable-refint I didn't need this part?
For the second refint file, the one to add the overlay, I just needed to remove the 'manager owner' part of the attributes, since my directory does not have those attributes. At this point the ldif added successfully.
Then I went into the directory and added users, groups, and assigned users to groups, and (once I told it to fetch the operational attributes) lo and behold my users had the appropriate memberOf attributes!
I want to add an ssh key to my drone secrets, but can't get the command to work. I've tried many versions of the command found on various stackoverflow/documentation pages, but none of them work. The command help also gives an entirely different syntax than the one in the documentation...
From the documentation:
drone secret add \
--repository <registry> \
--image <image> \
--name <name> \
--value <value>
This just doesn't work for me.
Then I've found this Stackoverflow question about adding ssh keys to secrets. The answer shows again a different syntax, I tried this way, still doesn't work.
When I try to use the command, I get this:
Incorrect Usage.
NAME: drone secret add - adds a secret
USAGE: drone secret add [command options] [repo] [key] [value]
OPTIONS: --event [--event option --event option] inject the secret
for these event types --image [--image option --image
option] inject the secret for these image types --input input
secret value from a file --skip-verify skip verification for the
secret --conceal conceal secret in build logs
Which suggests it should be used like this:
drone secret add user/repo SSH_KEY <my_id_rsa>
But that doesn't work either.
So what's the actual way of using this command?
Turns out there is an option to add secrets in the web interface, in the settings page of a repo. I completely missed it and the documentation doesn't mention it.
So no need to use the command line.
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.
Want to use ldap_mod_add command with SSL on Centos but get the following error message;
PHP Warning: ldap_mod_add (): Modify: Server is unwilling to perform in ...
However the SSL ldapsearch command is working well;
ldapsearch -x -H ldaps://winsvr.intra -b dc=windows, dc=intra -D "DOMAIN\user"-w "123456"
The required Windows.pem file is in /etc/ssl/certs/windows.pem directory and has the appropriate line in /etc/openldap/ldap.conf.
Indeed getting above error message.
What else should I configure to work properly?
Updated:
Everything's OK. Problem was that I didn't recognize existing AD user. That's why the ldap_mod_add returned with above error messages (it couldn't add same AD user through ldap_mod_add).
The LDAP client in your PHP example is apparently doing an update, whereas the ldapsearch tool is doing a search, not to point too fine a point on it. The configuration of the server, the nature of the target entries involved, and any access controls involved might affect the update but not the search.