I have a private hosted registry at www.myDockerRepo.company.com:2222. To login to this repository I follow these steps
docker login www.myDockerRepo.company.com:2222
username : xxx
password : ***
email : xyz#company.com
WARNING: login credentials saved in /home/vagrant/.docker/config.json
Login Succeeded
Can these credentials be saved before hand in the config.json so that clients dont need to manually enter these credentials n every login? What is the best practice to login to private registries?
Yes, you can manually add the creds to the config. Just copy the file over from a host that you already logged in with.
As far as best practices, they depend on the setup, but most common is to use a generic system account for your registry that is only used by the hosts, and then when setting up the hosts and installing docker, drop in the config file for that system user. Then all pushes and pulls from those servers will be with that account.
If you try and reuse a user account, things will break if that user changes their password. It also allows you to have different permissions for hosts, maybe pull only access vs push, etc.
Related
So far I have always been able to log in successfully via sso.
cf login -a url --sso
I need another way to log in for my pipeline script and tried the following command.
cf login [-a API_URL] [-u USERNAME] [-p PASSWORD] [-o ORG] [-s SPACE]
This command does not work with my user, nor with a technical user to whom all necessary roles have been assigned (M D A). I get the following message.
API endpoint: url
Password>
Authenticating...
Credentials were rejected, please try again.
Does anyone know how to solve this problem?
Or maybe an alternative to create a gradle task, for example, that can be executed in a jenkins pipeline.
At the end, I want to automate a deploy (to cloud) of an artifact with my Jenkins pipeline.
You provided —sso flag, so you shouldn’t see a password prompt. Instead you should be given the url to get a token.
Maybe your CF has been misconfigured and does not support SSO yet. I tried to fix the CF CLI to avoid this but it was oddly rejected https://github.com/cloudfoundry/cli/pull/1624
Try fixing your CF installation (it needs to provide some prompts), or skip the —sso flag usage.
Using --sso and -u/-p are not doing the same thing on the backend, and there's no guarantee that a user which can login through SSO is also set up to login as a user stored directly in UAA. UAA has multiple origin's from which users can be loaded, like SAML, LDAP and internal to UAA. When you use the --sso flag, you are typically logging in via a user from your company's SAML provider. When you use the -u/-p flags, it's typically LDAP or UAA, something UAA validates directly.
In order for what you are trying to do to work, you would need to have a user available with an origin in SAML (for --sso) and a user in origin LDAP or UAA (internal), and technically those would be two separate users (despite the fact that they may have the same credentials).
At any rate, if you normally login with the --sso flag and you want to automate work, what you really want is to get a UAA client that is set with the grant type of client credentials. You can then use cf auth CLIENT_ID CLIENT_SECRET --client-credentials to automate logging in.
Typically you don't want your user account to be tied to pipelines and automated scripts anyway. If you leave the company and your user get deactivated then everything breaks :) You want a service account, and that is basically a client enabled with the client credentials grant type in UAA.
I'm creating a Express.js REST server that can invoke and query chaincodes (similar to the JavaScript fabcar example). I'm wondering how would I register, enroll, and use a network user that is based on a username and password, so that I could allow the user to login using their username and password and can invoke chaincodes with their network user.
Please tell me if I'm going about this the wrong way, or if there are configs to achieve this.
I installed google two factor authentication on my linux server.
(thanks to: https://github.com/google/google-authenticator-libpam)
When I try to access root account via ssh, authenticator works fine.
Verification code: .....
Password: ....
[root#hostname] works fine :)
But!! access other user account and try to access root account using su,
authenticator only require password.
[user#hostname] whoami
user
[user#hostname] su
password: .....
[root#hostname] What?!!!
I set all config to default value.
How can I fix it??
This is the default way this works. Since you are using the google-authenticator-libpam module you are only adding two factor authentication to the actual external interface login via the addition of auth required pam_google_authenticator.so to the sshd config file.
The proper security implementation (or at least one of the proper ways) is to not allow external login for the root user, going one step further and locking down ssh to only allow login from users who have two factor authentication enabled is even better.
To do that you would add the following in your sshd config :
AllowUsers admin bob
To enable Google two factor authentication for su - you have to add following parameter at the end of file /etc/pam.d/su :
auth required pam_google_authenticator.so
Save it and try login using the normal user and then su -, it will prompt for verification code.
i.e. no need to restart sshd service.
I created a repository on hub.docker.com and now want to push my image to the Dockerhub using my credentials. I am wondering whether I have to use my username and password or whether I can create some kind of access token to push the docker image.
What I want to do is using the docker-image resource from Concourse to push an image to Dockerhub. Therefore I have to configure credentials like:
type: docker-image
source:
email: {{docker-hub-email}}
username: {{docker-hub-username}}
password: {{docker-hub-password}}
repository: {{docker-hub-image-dummy-resource}}
and I don't want to use my Dockerhub password for that.
In short, you can't. There are some solutions that may appeal to you, but it may ease your mind first to know there's a structural reason for this:
Resources are configured via their source and params, which are defined at the pipeline level (in your yml file). Any authentication information has to be defined there, because there's no way to get information from an earlier step in your build into the get step (it has no inputs).
Since bearer tokens usually time out after "not that long" (i.e. hours or days) which is also true of DockerHub tokens, the concourse instance needs to be able to fetch a new token from the authentication service every time the build runs if necessary. This requires some form of persistent auth to be stored in the concourse server anyway, and currently Dockerhub does not support CI access tokens a la github.
All that is to say, you will need to provide a username and password to Concourse one way or another.
If you're worried about security, there are some steps you can most likely take to reduce risk:
you can use --load-vars-from to protect your credentials from being saved in your pipeline, storing them elsewhere (LastPass, local file, etc).
you might be able to create a user on Dockerhub that only has access to the particular repo(s) you want to push, a "CI bot user" if you will.
Docker Hub supports Access Token
goto Account Settings > Security
its same as Github personal access token (PAT)
You can use this token instead of actual password
I am able to authenticate radius users using radius server+pam+ssh with creating local user with blank password in linux.
Is it possible to authenticate radius users without creating users in local machine with blank password?
/etc/pam.d/ssh file as below
#%PAM-1.0
auth sufficient pam_radius_auth.so debug
auth sufficient pam_unix.so use_first_pass
auth required pam_auth_status.so
account sufficient pam_unix.so
account required pam_auth_status.so
session required pam_unix.so
You can authenticate the user without creating an entry for him in /etc/passwd and /etc/shadow files. But now , the user is not associated with any shell in '/etc/passwd' , so it can be of no use.
Do you want to launch a shell after authentication or you want the user just to be authenticated?
I found two nss libraries that could help in this case:
libnss-mapuser from Cumulus Linux.
libnss-ato
The general process is that these will map unknown (but authenticated) user to a single user template. Each user will get his/her own /home folder though but both libs have in common that the user id will be the same.
These packages are mainly targeted at network devices where there is no ldap setup done. Cumulus describes the setup nicely.
I recommend reading https://serverfault.com/questions/538383/understand-pam-and-nss to understand what is happening there.