New answers tagged

2

The reason it is failing, is because the actual plugin is called with_items and not with_item. You forgot the s.


0

Rather than type your password multiple times you can make use of pssh and its -A switch to prompt for it once, and then feed the password to all the servers in a list. NOTE: Using this method doesn't allow you to use ssh-copy-id, however, so you'll need to roll your own method for appending your SSH pub key file to your remote account's ~/.ssh/...


0

I would use a host variable "ssh_users", which states the users that need their host keys added. - ssh_users: - bob - root - alice Then, you have a seperate variable file that defines the name, key and state for each SSH user. Import that variable file, then call your original task pretty much as is.


1

Copy the putty key to your mac Install Homebrew (if not installed) Install putty command-line on your mac brew install putty Extract your private key puttygen id_dsa.ppk -O private-openssh -o id_dsa Extract your public key puttygen id_dsa.ppk -O public-openssh -o id_dsa.pub Move the extracted keys to your $HOME/.ssh Source: How to convert .ppk key to ...


1

Yes, it is possible something like ssh-copy-id -f -i hostkey.rsa.pub user@target with latest version of ssh-copy-id. If you have some older, it might or might not work (with RHEL7 and older Fedora with SSH_COPY_ID_LEGACY=1 environment variable)


1

The server didn't accept the key your client provided. The client provided only "/Users/kosmos/.ssh/id_rsa_old", guessing that's not the key that's in your authorized_keys file on the remote server. Check the auth.log on the server, it should contain something helpful as to why. If the public key for that id_rsa_old is in your authorized_keys file on that ...


3

It is not possible to "use" a private key without being able to read - and thus copy - that private key. So the idea that your admins can login to the jumpbox, then go onwards using a private key that they cannot directly access, is not going to fly. But you can arrange things so that the private keys can only be used from the jumpbox (see man sshd, from= ...


1

Following the advice of @Jakuje, I checked the logs after turning LogLevel from INFO to DEBUG3 in sshd_config and the problem was simply a permission issue with the user directory : Authentication refused: bad ownership or modes for directory /home/user


3

From comments: Do you have your authentication public key in ~/.ssh/authorized_keys and do this file and parent folder have proper permissions and SELinux labels? The .ssh folder needs to have permissions 700 (not readable by others). chmod 700 ~/.ssh/ chmod 600 ~/.ssh/authorized_keys


9

For that key, the organization don't have non-repudiation. IE, if someone does something abusive or destructive to that system using 'your' key, the admin can't point the blame at you for being solely responsible for it. Since the person that gave it to you also had the key. It probably isn't that bad for you, since it gives you a defense, but horrible ...


22

It is exactly as you say: The whole concept of public key authentication is that the private key should only be known to the owner, while the corresponding public key can be widely disseminated. The security of your authentication depends on the security of the private key, not of the security of the public key. The fact that somebody else provides you ...



Top 50 recent answers are included