To update:In the meantime, I published a Forge modulernelson0 - local_userwhich can also be used to distribute keys. If you use keys with local users, I recommend using the Forge module. If you are not managing users directly (e.g. for domain joined nodes) then continue using the solution below.
Today, let's take a look at providing authorized SSH keys through Puppet. An authorized key is a public key used for public key authentication (not to be confused with an SSH key, which is a unique host key identifier that verifies that the server is who it claims to be). Attaching an authorized key to a user successfully authenticates any login attempt for that user by presenting the corresponding private key, allowing them to log in without a password. This is often used for automation when no user is present to enter a password, or when a user with a private key can access systems without additional steps.
Authorized keys are typically considered more secure than a password, but rely on private key protection. If the private key is not protected, anyone who obtains the private key can impersonate the account. If a non-privileged user's password is lost, only that user's access and files are immediately at risk. An attacker would still have to increase privileges to damage the system. If you lose a privileged user's password (nobody reading this is logging in as a privileged user, like root, right? RIGHT?) or an automation account's password, the immediate risk is much greater. An attacker could gain access to the entire system or attack other systems. It is imperative that you back up your private keys and make sure you keep track of them.principle of least privilegefor all users, especially automation accounts.
Let's see an example of using a duly protected authorized key. In previous articles, we created a yum repository and a build server. You can often log into these servers and transfer files between the two. Every time you have to enter your passwords. It gets old fast. If you have an authorized key, you can ssh to both servers and present your private key without a password. Likewise, if you copy the private key to the build server or create a new key, you can transfer files from the build server to the yumrepo scp. That should make your life a lot easier.
There are many ways to generate keys, depending on the operating system and applications. My workflow is to use putty on a Windows 7 laptop to connect to Linux VMs and then use the Opensh Linux client to ssh to other Linux VMs. I'll cover generating and configuring keys with putty and OpenSH.
Windows users can download Putty and PuttygenHere. Run Puttygen first. The key generator is very simple. Choose the key type (SSH2-RSA) and the number of bits (the default is 1024, I suggest 2048 or higher) and click the Generate button.
You are asked to move the mouse around a specific area to generate randomness (entropy). When you've spawned enough, you'll have a key.
Usefully, you can press Ctrl-C and get the authorized key you need. This is how mine looks like:
ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQBxjRfeEHj2n9bKt1VBBiJUri396kprjndOgd5CVc6MvdbEsL96dRUcd2J/d4Tu0vYqpsRaUh9lfPfW8CThBrMFZfvGkGPF5vKrlffELyfrJxPPnRJIazmee1g6U1AwNhiJNiwp0dLHcnUvozfXagWI1fDg6uT6/M3CrUwqLBQsOLxYx5qFpAQjDvrbGkBXF/XcW97wglzr/INUcKaAKWSitj+5TPwgjGzVty5k+uGxHxNZUGEF3qVNKb11sifKxvNYgaT+86x2Ir2qH/6CJrTqWdF/Bw+1hNPOjS/En+9A7jG9txPXQ35X9sDgE+xxmkxMFtZZFxV6y/Uk+zcAzwE1 rsa-key-20141029
you have to click on itsave private keykey and protect this key. You definitely want to make sure it's available to you in the future, so make sure you back it up. A secure cloud storage service in a folder that is NOT shared might be a good place. you probably wantsave public keyhowever, even if you are storing the above string, this is not strictly necessary.
To use this key, start Putty. LowConnection -> SSH -> Authentication, show aAuthentication private key file:to your private key. Then go up the stairsmeeting, contributionDefault settingmilitarysaved sessionsname and clicksave not computer. This key is now used by default when connecting to any IP address.
My linux virtual machine already has openssh ssh client and ssh-keygen apps installed. They are usually present on most modern *nix systems, so these steps may work for your operating system with little or no modification.
Runssh-keygen -b 2048. The default type is SSH2-RSA, as we use with putty-gen, but the default byte is 1024, so we'll override that. Optionally, you can enter a password. This is like a password for your certificate and you might not want it. You certainly don't want an automation key passphrase because no one is around to enter the key or the automation script automatically enters it, defeating the purpose of a passphrase. After providing or omitting the password, you will be provided with the location of the public and private keys and an intelligent random interpretation of the key. If you don't like it, then it's useless and you can forget about it; otherwise, print it out and save it to your desktop. Finally navigate to the pub file and you will see a string similar to the one provided by puttygen.
[rnelson0@build ~]$ ls .sshid_rsa id_rsa.pub known_hosts[rnelson0@build ~]$ rm .ssh/id_rsa*[rnelson0@build ~]$ ls .ssh/known_hosts[rnelson0@build ~]$ ssh-keygen - b 2048 Generation of an RSA public/private key pair. Enter the file where the key should be saved (/home/rnelson0/.ssh/id_rsa): Enter the password (blank if there is no password): Enter the same password again: Your ID has been saved in /home/rnelson0/. ssh/id_rsa. Your public key was stored in /home/rnelson0/.ssh/id_rsa.pub. The key fingerprint is: 6e:14:17:38:aa:1e:9d:dd:e0 :21:be:64:9d:07:e3:e9 rnelson0@build The key randomart image is: + - - [RSA 2048]----+| .. || ANY . || .... || or = or || +OSB || or *oB or || . +oh || . ..And || |+-----------------+[rnelson0@build ~]$ ls .ssh/id_rsa id_rsa.pub known_hosts[rnelson0@build ~]$ cat /home/rnelson0/. ssh/id_rsa.pubssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAnoeEgdExZhsiWm0tln++sFuQZGX/U8wTQUv/uo2WMdfTD4cnI8XvXzEAwcVQQ/Y2u5kkWUbYJvSHfoDwDlL8xoevjOecWfegYVe4UEaYe4LhAE8GijtnTBsroB+AJl4WYvXdACzfxB7xTNjYQKfxvoJd3QdQi9IJQdb4HmjC2doVPKrR+DeVdNt5L/ziXvtGp9A0w3CKyl2wZ5A6MLIlkCN0Kad8/mcfhi7eQ6XZUfC84ksx7+t+/2BR1pwf67Z93VxPtPMWiyUjkYHjw3CVAue5L2fOwFhpaFOSAqzBEMsMHrXSS+8U2/lhi4XBl4zAH2PNUv1KnHfc5sBk95CgGw== rnelson0@build
In rare cases, your preferred *nix might store the key in a different format, similar to this:
---- BEGIN SSH2 PUBLIC KEY ----Comment: "2048-bit RSA, converted from OpenSSH by rn7284@build"AAAAB3NzaC1yc2EAAAABIwAAAQEAnoeEgdExZhsiWm0tln++sFuQZGX/U8wTQUv/uo2WMdfTD4cnI8XvXzEAwcVQQ/Y2u5kkWUbYJvSHfoDwDlL8xoevjOecWfegYVe4UEaYe4LhAE8GijtnTBsroB+AJl4WYvXdACzfxB7xTNjYQKfxvoJd3QdQi9IJQdb4HmjC2doVPKrR+DeVdNt5L/ziXvtGp9A0w3CKyl2wZ5A6MLIlkCN0Kad8/mcfhi7eQ6XZUfC84ksx7+t+/2BR1pwf67Z93VxPtPMWiyUjkYHjw3CVAue5L2fOwFhpaFOSAqzBEMsMHrXSS +8U2/lhi4XBl4zAH2PNUv1KnHfc5sBk95CgGw==---- ENDE SSH2 ÖFFENTLICHER SCHLÜSSEL ----
This is the SSH RFC 4716 public key format. It's ugly, but platforms that don't use openssh, like Solaris, might need this format. You can switch between the two formats using the-mi(RFC) y-EU(OpenSSH) arguments tossh-keygen, then:
[rnelson0@build ~]$ ssh-keygen -e -f /home/rnelson0/.ssh/id_rsa.pub > test.pub[rnelson0@build ~]$ cat test.pub---- COMENZAR CLAVE PÚBLICA SSH2 -- --Comment: "2048-bit RSA, converted from OpenSSH by rnelson0@build"AAAAB3NzaC1yc2EAAAABIwAAAQEAnoeEgdExZhsiWm0tln++sFuQZGX/U8wTQUv/uo2WMdfTD4cnI8XvXzEAwcVQQ/Y2u5kkWUbYJvSHfoDwDlL8xoevjOecWfegYVe4UEaYe4LhAE8GijtnTBsroB+AJl4WYvXdACzfxB7xTNjYQKfxvoJd3QdQi9IJQdb4HmjC2doVPKrR+DeVdNt5L/ziXvtGp9A0w3CKyl2wZ5A6MLIlkCN0Kad8/mcfhi7eQ6XZUfC84ksx7+t+/2BR1pwf67Z93VxPtPMWiyUjkYHjw3CVAue5L2fOwFhpaFOSAqzBEMsMHrXSS+8U2/lhi4XBl4zAH2PNUv1KnHfc5sBk95CgGw==---- END SSH2 PUBLIC KEY ----[rnelson0@build ~]$ ssh-keygen -i -f test.pubssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAnoeEgdExZhsiWm0tln++sFuQZGX/U8wTQUv/uo2WMdfTD4cnI8XvXzEAwcVQQ/Y2u5kkWUbYJvSHfoDwDlL8xoevjOecWfegYVe4UEaYe4LhAE8GijtnTBsroB+AJl4WYvXdACzfxB7xTNjYQKfxvoJd3QdQi9IJQdb4HmjC2doVPKrR+DeVdNt5L/ziXvtGp9A0w3CKyl2wZ5A6MLIlkCN0Kad8/mcfhi7eQ6XZUfC84ksx7+t+/2BR1pwf67Z93VxPtPMWiyUjkYHjw3CVAue5L2fOwFhpaFOSAqzBEMsMHrXSS + 8U2 / i4XBl4zAH2PNUv1KnHfc5sBk95CgGw==
By default, openschThe client uses the key stored in~/.ssh/id_rsato identify itself to remote systems. With you can generate an additional keyssh-keygen-fand use it withssh -i ~/.ssh/ …According to the necessity. You probably don't need this for a single user, but it can help with automation if you want separate keys for each remote system to reduce the risk to those remote systems if a specific private key is released. We assume that only the default key has been created and is being used.
Puppet has a built-in resource type ofssh_authorized_key. By defining a resource that corresponds to our authorized key and applying it to a system, we can authenticate with that key. Let's focus on our build server, which we'll connect to from our Windows laptop. This is what a login attempt looks like now, with putty configured to present our key, but without an author_key configured on the virtual machine:
Login as: rnelson0CentOS Version 6.4 (Final) Kernel \r on a \mServer refused our key rnelson0@build.nelson.va password:Last login: Tue Oct 28 15:27:04 2014 10.0.0.200[rnelson0 @build ~ ] $
The server rejects the key and asks for a password. Showing the key doesn't hurt, but it doesn't help either... yet. Let's define a key in the file.ssh_authorized_key.ppand apply it. Note that there isno line breaksin the manifest i just added some for readability in this blog.
ssh_authorized_key { 'rnelson0@putty': user => 'rnelson0', type => 'ssh-rsa', key => 'AAAAB3NzaC1yc2EAAAABIwAAAQEAnoeEgdExZhsiWm0tln++sFuQZGX/U8wTQU v/uo2WMdfTD4cnI8XvXzEAwcVQQ/Y2u5kkWUbYJvSHfoDwDlL8xoevjOecWfegYVe4UEaY e4LhAE8GijtnTBsroB+AJl4WYvXdACzfxB7xTNjYQKfxvoJd3QdQi9IJQdb4HmjC2doVPK rR+DeVdNt5L/ziXvtGp9A0w3CKyl2wZ5A6MLIlkCN0Kad8/mcfhi7eQ6XZUfC84ksx7+ t+ /2BR1pwf67Z93VxPtPMWiyUjkYHjw3CVAue5L2fOwFhpaFOSAqzBEMsMHrXSS+8U2/lhi4 XBl4zAH2PNUv1KnHfc5sBk95CgGw==',}[rnelson0@build ~]$ sudo puppet apply ssh_authorized_key.pp[sudo] password for rnelson0:Notice: Compiled catalog for build.nelson.va in environment production in 0.05 secondsNotice: / Stage[main]/Main/Ssh_authorized_key[rnelson0@putty]/ensure: createdNotice: Fertiger Kataloglauf en 0,06 segundosLet's start a new putty session for this virtual machine and specify our username again:
Login as: rnelson0CentOS Version 6.4 (Final) Kernel \r at \mPublic Key Authentication "rsa-key-20141029" Last login: Wed Oct 29 14:12:44 2014 from 10.0.0.200[rnelson0@build ~ ]$
Success! You can now authenticate with the key instead of a password. However, when you SSH to another node, you still need to use a password. The key must be present on every node in your network. we could take itssh_authorized_keyresource in the manifest file and include itProfile::Base. That would add it everywhere, or at least try to. Puppet can manage Windows and network devices, what if you apply the same feature there?fariaWant to apply the feature there? We could avoid such potential problems by definingprofile::authorized_keys::administrators. By applying this profile to the correct roles, we have a little more control over which nodes have which authorized keys, but we still need to define and apply the profiles correctly. There is another way.
As we've already established, Hiera allows us to remove our data from our code. Authorized keys sound a lot more like data than code to me. We can put keys in hiera and apply them as needed according to our hierarchy (note: reviewWound-Tal Methodto make sure you understand how the hierarchy is used to determine values). Let's look at our ssh_authorized_key defined in YAML (again there'sno line breaksin a real file, this is just for readability):
ssh_authorized_keys: 'rnelson0@putty': user: 'rnelson0' type: 'ssh-rsa' key: 'AAAAB3NzaC1yc2EAAAABIwAAAQEAnoeEgdExZhsiWm0tln++sFuQZGX/U8wT QUv/uo2WMdfTD4cnI8XvXzEAwcVQQ/Y2u5kkWUbYJvSHfoDwDlL8xoevjOecWfegYV e4UEaYe4LhAE8GijtnTBsroB+AJl4WYvXdACzfxB7xTNjYQKfxvoJd3QdQi9IJQdb4 HmjC2doVPKrR+DeVdNt5L/ziXvtGp9A0w3CKyl2wZ5A6MLIlkCN0Kad8/mcfhi7eQ6 XZUfC84ksx7+t+/2BR1pwf67Z93VxPtPMWiyUjkYHjw3CVAue5L2fOwFhpaFOSAqzB EMsMHrXSS +8U2/lhi4XBl4zAH2PNUv1KnHfc5sBk95CgGw=='
let's add thisglobal.yaml. You could, and probably should, do this at any level of the hierarchy, but my lab's hierarchy isn't that complex. The next step is to modify the site's manifest to recognize and create this hash.ssh_authorized_keyResources. Be sure to create a new git branch and redeploy the environments after making the change. This is what the new default class definition looks like, the change is in bold:
[rnelson0@puppet puppet-tutorial]$ git checkout -bauthorized_key_demoWechsel zu einem neuen Branch 'authorized_key_demo'[rnelson0@puppet puppet-tutorial]$ vi manifests/site.pp[rnelson0@puppet puppet-tutorial]$ cat manifests/site. ppPackage { allow_virtual => true,}nodo predeterminado { hiera_include('classes')$ssh_authorized_keys = hiera_hash('ssh_authorized_keys', undef)if ($ssh_authorized_keys != undef) {create_resources('ssh_authorized_key', $ssh_authorized_keys)}}Commit your change, push the new branch, and redeploy your environments. run against themauthor_key_demoEnvironment and you won't see any changes on the build server. remove those.ssh/authorized_keysfile and Puppet rebuild the file.
[rnelson0@build ~]$ sudo puppet agent -t --environment=authorized_key_demo... Info: Applying configuration version '1414605740' Note: Completed catalog runs in 1.05 seconds[rnelson0@build ~]$ rm .ssh /authorized_keys[ rnelson0 @build ~]$ sudo puppet agent -t --environment=authorized_key_demo...Info: Applying configuration version '1414605740' Warning: /Stage[main]/Main/Node[default]/Ssh_authorized_key[rnelson0 @putty ] /ensure: createdNotice: Finished catalog runs in 0.99 threads
voila! If you merge this into production, all nodes should have this key pretty quickly. Before we do that, let's look at a second problem.
Addressed issue where a non-puppet-managed node wants to authenticate to a puppet-managed node. Can I ssh to all nodes from my laptop, yes. However, when I'm on the build server and I need to push scp files to the yum repository, I'm still stuck typing a password. If you are joining your Linux VMs to an Active Directory domain then this might not be a problem for you as your Kerberos tickets will follow but we assume you are not so lucky so something needs to be done.
The hardest but possibly safest way would be to run our opensh keygen process on top of each machine for each user and add the public key to hiera. It doesn't scale well. X users, Y nodes, you quickly have X*Y keys to manage. Revoking a key also becomes tedious, you have to generate up to Y new keys.
Instead we look at each otherhost based authentication. Enabling this on your nodes will allow all users on the specified nodes to SSH to the other specified nodes without a password. This requires working DNS (both forward and backward), some SSH configuration changes, and a design decision to allow this communication. Our configuration allows all users on all nodes, but you can restrict this to users and groups if you like. The other thing we need since we're going to be doing this through Puppet is puppetdb. lucky usI already installed it. Our guide specifies three points, oneshosts.equivFile and SSH host and client configuration. First let's focus on the configuration.
On the server side, we need to enableRSA host authenticationYHost based authentication. Let's add this to ours.Profile::Basewhich explains some other options. Be sure to fork your profile repository as well. Here's the relevant part:
class { '::ssh::server': opções => { 'PermitRootLogin' => 'sí', 'Protocolo' => '2', 'SyslogFacility' => 'AUTHPRIV', 'PasswordAuthentication' => 'sí' , 'GSSAPIAuthentication' => 'sí', 'GSSAPICleanupCredentials' => 'sí', 'AcceptEnv' => 'IDIOMA LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT LC_UAIDENTIFIC/BJEner'Lopenshan' '/etc/issue.net','RhostsRSAAuthentication' => 'ja','Host-based authentication' => 'ja',}, }Client-side changes are made in the same class:
class { '::ssh::client': options => { 'Host *' => { 'SendEnv' => 'LANG LC_*', 'HashKnownHosts' => 'sim', 'GSSAPIAuthentication' => 'sim' , 'GSSAPIDelegateCredentials' => 'nenhum','Host-based authentication' => 'ja','EnableSSHKeysign' => 'já',}, }, }The last piece we need is the file./etc/ssh/shosts.equiv. This is where puppets come into play. Hesaz/schThe module we are using uses resources exported from puppetdb toimplement ssh keysof all nodes managed by Puppet on each node. Based on that, we create our file. Let's create an EXE file to complete the file laterssh::known hostsdoes its job. This exec runs every time, slowing down each Puppet run, but currently the best way to handle this (I'm all ears if someone has a better way!). Here is the executive we will also addProfile::Base:
exec {'shosts.equiv': comando => 'cat /etc/ssh/ssh_known_hosts | grep-v "^#" | awk \'{$1 borracho}\' | sed -e \'s/,/\n/g\' > /etc/ssh/shosts.equiv', require => Class['ssh::knownhosts'], }You will find that the output file is very verbose and likely contains duplicates. could you pass it onorder | just, but you lose the order that helps you match hostnames to IP addresses.
Apply your changes, push them up and redeploy. Running Puppet in this environment should display all of our specified changes and we can inspect the generated file:
....Sugestão: /Stage[main]/Ssh::Client::Config/File[/etc/ssh/ssh_config]/content:--- /etc/ssh/ssh_config 2014-10-30 14:56: 33.595904923 +0000+++ /tmp/puppet-file20141030-4911-175447n-0 2014-10-30 16:06:44.856329783 +0000@@ -1,7 +1,9 @@# Von PuppetHost verwaltete Datei *+ EnableSSHKeysign ja GSSAPIAuthentication ja GSSAPIDelegateCredentials nein HashKnownHosts ja+ HostbasedAuthentication ja SendEnv LANG LC_*Info: /Stage[main]/Ssh::Client::Config/File[/etc/ssh/ssh_config]: Filebucketed /etc/ssh/ssh_config a marioneta con sum dc8e176896645889517c83214e690f4eNotice: /Stage[main]/Ssh::Client::Config/File[/etc/ssh/ssh_config]/content: content changed '{md5}dc8e176896645889517c83214e690f4e' to '{md5}84bbc5eb5e9ac092547db91116dfee49'Notice: /Stage[main] /Ssh::Servidor::Config/Archivo[/etc/ssh/sshd_config]/content:--- /etc/ssh/sshd_config 2014-09-22 22:23:55.627803019 +0000+++ /tmp/puppet- file20141030-4911-2emast-0 2014-10-30 16:06:45.212404828 +0000@@ -5,10 +5,12 @@ChallengeResponseAuthenticat ion no GSSAPIA Authentifizierung yesGSSAPICleanupCredentials yes+HostbasedAuthentication yesPasswordAuthentication yesPermitRootLogin yesPrintMotd noProtocol 2+RhostsRSAAuthentication yesSubsystem sftp /usr/libexec/openssh/sftp-serverSyslogFacility AUTHPRIVUsePAM yesInfo: /shtage/config/Server[main]/ ] : Filebucketed /etc/ssh/sshd_config zu Puppet mit Summe 1038629dbacf8f7cd04524cb6e4465c9Aviso: /Stage[main]/Ssh::Server::Config/File[/etc/ssh/sshd_config]/content: Inhalt geändert '{md5}1038629dbacf584f7cb0 '5cb6e4 {md5}c587f6cce01aeaadc96226aaa73ff936'Info: /Stage[ main]/Ssh::Server::Config/File[/etc/ssh/sshd_config]: Planung der Aktualisierung von Class[Ssh::Server::Service]Info: Class [Ssh: :Server::Config]: Planung der Atualização da classe[Ssh::Server::Service]Info: Class[Ssh::Server::Service]: Planung der Aktualisierung von Service[sshd]Notice: /Stage[ main]/Ssh: :Server::Service/Service [sshd]: Ausgelöste „Actualisierung“ de 1 Ereignissen Hinweis: /Stage[main]/Profile::Base/Exe c[shosts.equiv]/returns: exe erfolgreich geschnitten Hinweis: Fertiger Kataloglauf in 1,93 Sekunden[rnelson0@build ~]$ cat /etc/ssh/shosts.equivbuild.nelson. va_dsabuild.nelson.vabuild10.0.0.20Do this also in the yum node. You can now ssh between the two nodes without a password (yeah, I'll correct my misspelling now that it's public):
[rnelson0@build ~]$ ssh yumThis server is for Nelson family use. All other uses are unauthorized Last login: Thursday, October 30, 2:53:34 PM, 2014 from build.nelson.va[rnelson0@yumrepo01 ~]$[rnelson0@yumrepo01 ~]$ ssh buildCentOS version 6.4 ( end)Kernel \r at \mLast login: Thursday, October 30 12:09:41 2014 from 10.0.0.200[rnelson0@build ~]$
If things don't work correctly, you can fix the problem by stopping sshd on the server and enabling debug mode on both the server and the client.
#SERVER:[rnelson0@yumrepo01 ~]$ sudo service sshd stopStopping sshd: [ OK ][rnelson0@yumrepo01 ~]$ sudo /usr/sbin/sshd -d -ddebug2: load_server_config: filename /etc/ssh/sshd_configdebug2: load_server_config: done config len = 530debug2: parse_server_config: config /etc/ssh/sshd_config len 530debug1: sshd version OpenSSH_5.3p1debug1: read PEM private key done: enter RSAdebug1: host private key: #0 enter 1 RSAdebug1: read PEM private key done : enter DSAdebug1: host private key: #1 enter 2 DSDebug1: rexec_argv[0]='/usr/sbin/sshd'debug1: rexec_argv[1]='-d'debug1: rexec_argv[2] ='-d ' Set /proc /self/oom_score_adj from 0 to -1000debug2: fd set 3 O_NONBLOCKdebug1: bind port 22 to 0.0.0.0.Server listening on 0.0.0.0, port 22.debug2: fd set 4 O_NONBLOCKdebug1 : bind to port 22 at ::. server listening on ::port 22.#CLIENT:[rnelson0@build ~]$ ssh -vvv yumOpenSSH_5.3p1, OpenSSL 1.0.0-fips Mar 29 zo 2010debug1: configuration file not read /etc/ssh/ssh_configdebug1: apply options to *debug2: ssh _connect: needpriv 0debug1: connect to yum [10.0.0.252] port 22.
Check out the References section for troubleshooting help, and of course, hopefully Google will get you some results. If you get gethostbyname errors, be sure to check your back and forth entries on BOTH sides - the debugging information is not always clear which hostname is being looked up.
Once everything works fine, make sure to merge your changes back into master/production and deploy your environments so that all nodes can benefit from the changes.
You can now ssh from the Windows desktop to the Puppet managed node and between Puppet managed nodes. You can add new users here without changing your puppet code. If desired, you can further restrict host-based authentication between nodes for users and groups. But what you don't have to do is keep typing your password! I hope this helps make browsing the web a little easier.
There is a point that we have to see later. Puppetdb keeps host keys forever until you start tuning. If you destroy a node and create a new one with the same name, you will find two keys in your/etc/ssh/ssh_conocido_hostsfor the hostname. Clearly this could be a security flaw as the IPs of the downed nodes can be reused and end up gaining access to your network. You can check how to do itdisable idle nodes, but I'll get to that at some point.
- http://itg.chem.indiana.edu/inc/wiki/software/openssh/189.html– ignore reference to/etc/hosts.equiv