I recently changed the DNS cname record of one of the slaves that my jenkins machine uses. After the change was made, I updated the information in the node so that it points to the new name. Since then, the jenkins slave fails to launch with the following error:
[09/10/14 18:24:11] [SSH] Opening SSH connection to name.domain.com:22.
ERROR: Server rejected the 1 private key(s) for ubuntu (credentialId:xxxxxxxxxxxxxxxxxxxxxxx/method:publickey)
[09/10/14 18:24:11] [SSH] Authentication failed.
hudson.AbortException: Authentication failed.
at hudson.plugins.sshslaves.SSHLauncher.openConnection(SSHLauncher.java:1143)
at hudson.plugins.sshslaves.SSHLauncher$2.call(SSHLauncher.java:648)
at hudson.plugins.sshslaves.SSHLauncher$2.call(SSHLauncher.java:642)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
[09/10/14 18:24:11] [SSH] Connection closed.
[09/10/14 18:24:11] Launch failed - cleaning up connection
Can anyone give me info on how I might resolve this? Its using the same key that had been working prior to the DNS change.
The problem is visible on the line that says:
ERROR: Server rejected the 1 private key(s) for ubuntu (credentialId:xxxxxxxxxxxxxxxxxxxxxxx/method:publickey)
You need to log into the slave and examine /var/log/auth.log to discover why the slave refused the key.
You might want to double-check which credential the slave is configured to use. Sometimes when I have edited slave configuration, some settings have changed that I have no recollection changing.
This may be an odd issue that has to do with AWS permissions, and to be honest I don't entirely understand the why of it, but in the end I was able to resolve the issue.
The machine would not accept the .pem key that I had previously been using. I ended up having to make a new pem key and add it to authorized keys on the destination machine.
I confirmed that I am still able to use the original key to ssh into the box, but for some reason it would not work from the jenkins machine.
Related
I've got an ec2 instance running as an SSH server, and recently needed to restart the instance. Upon restart, clients that were connecting through this SSH server started seeing connection errors related to the SSH fingerprint changing.
Deleting the existing fingerprint from knownhosts resolves the issue. But, is there a way to prevent the server's fingerprint from changing, or persisting the existing fingerprint on restart?
I am trying to create localhost Apache Ambari cluster on CentOS7. I am using Ambari 2.2.2 binaries downloaded and installed from the Ambari repository with the following commands
cd /etc/yum.repos.d/
wget http://public-repo-1.hortonworks.com/ambari/centos7/2.x/updates/2.2.2.0/ambari.repo
yum install ambari-server
ambari-server setup
ambari-server start
Before starting the server I have done all the necessary preparations steps described on the Hortonworks including the setup of passwordless ssh, which is frequent reason of problems according to the posts found on the internet. I verify it with
ssh root#localhost
During the creation of cluster in the "Install options" window I enter the name of the host I want to create (localhost in my case) and have already tried both of the options, which are
providing rsa secret key direktly - in this case the next window
simply stucks in the "Installing" stage and does not go any further,
showing no errors
performing manual registration of hosts.
For the second option I have downloaded and installed ambari-agent
yum install ambari-agent
ambari-agent start
In case of manual host registration I am getting the following error
"Host checks were skipped on 1 hosts that failed to register.".
When I click on "Failed", which in some cases described over the internet is supposed to deliver more precise description of a problem I see the following
"Registering with the server...
Registration with the server failed."
As a result I don't even now where to start searching for the possible reasons of this error.
Ambari cluster nodes need to be configured with a Fully Qualified Domain Name (FQDN). localhost is not an FQDN. You will need to configure the node with an FQDN and then retry the installation. You could use something like: localhost.local which is an FQDN. This requirement and how to configure the node to meet it are documented in the pre-requirements. From the HDP documentation:
All hosts in your system must be configured for both forward and and reverse DNS.
If you are unable to configure DNS in this way, you should edit the /etc/hosts file on every host in your cluster to contain the IP address and Fully Qualified Domain Name of each of your hosts.
I had the same "Registering with the server... Registration with the server failed." problem just recently.
I found the response on the same topic recommending to take a look at the log file which is located here /var/log/ambari-agent/ambari-agent.log from there was able to check that the hostname was set up incorrectly during some other phase of installation (I had it something like ambari.hadoop instead of localhost). So I went to the /etc/ambari-agent/conf/ambari-agent.ini and fixed it there.
I know that I'm digging some quite old question, but seems that compiling all that at one place might help someone with the same problem.
I am trying to connect from a windows computer to a ubuntu linux server, It is about cvs, I want to do a checkout. I use smartcvs 7.1.9.
I get this error when I try to connect to the server: (Project > Checkout > Next)
Authentication Failed: You could not get authenticated by the
CVS-server. Details: I/O-Exception: Failed to negotiate a transport
component [diffie-hellman-group-exchange-sha1]
[diffie-hellman-group14-sha1]
Anybody ideas what I can do?
This is a cvs server issue.
SmartCVS uses the diffie-hellman key exchange method for authentication which is known to have security issues. Therefore it has been disabled by default in current standard openssh(d) server configurations.
If you know what you are doing and don't care about the security implications, just add the following lines to sshd_config:
starts here
KexAlgorithms diffie-hellman-group1-sha1,curve25519-sha256#libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1
Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm#openssh.com,aes256-gcm#openssh.com,chacha20-poly1305#openssh.com,blowfish-cbc,aes128-cbc,3des-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc
ends here
If you're on linux.. recreate the keys and restart the opensshd service:
dpkg-reconfigure openssh-server
/etc/init.d/ssh restart
Regards
Erwin
I am trying to copy a current Puppet Master server on one domain and move it to another. Im finding that its very hard to try to change all the config remanence. Is there an easy way to do this, or a step by step best practice? I have grepped most of the old fqdn name and changed it to the new one, yet when I delete all certs, and re-issue new ones on the master, it wants to keep pulling a cert for the old FQDN.
Edit 1: I have resolved many of the issues I was previously getting. However I can not get past this SSL issue for the life of me.
[root#puppet lib]# puppet resource service apache2 ensure=running
Error: Could not run: SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed: [unable to get local issuer certificate for /CN=puppet.foundry.test]
I have attempted to completely purge all certs from the master, using this link, and then regenerate all. But I still keep getting the same errors:
Error: Could not run: SSL_connect SYSCALL returned=5 errno=0 state=SSLv3 read finished A
Now Im not sure if I am having puppet SSL issues, or SSL issues in general.
Most likely you're connecting to a wrong server (default is hostname puppet).
Check your agent's config, you're mostly interested in server variable
puppet config print --section agent | grep "server = "
Also it's good to know where is puppet agent looking for its config:
$ puppet config print --section agent | grep "^config = "
config = /etc/puppetlabs/puppet/puppet.conf
Edit your config, set correct puppet master:
[agent]
server=puppet4.example.com
Just for sure, you can clean your cerfificate (on agent):
find /etc/puppetlabs/puppet/ssl -name $(hostname -f).pem -delete
on puppet server:
puppet cert clean {broken hostname}
And finally run puppet agent -t
You can use this link: http://bitcube.co.uk/content/puppet-errors-explained
Did you try to change the puppet master dns?
Try looking if the puppet master cert is the same as what you are writing in server on the node.
If not you can always use dns_alt_names = puppet_hostname.your_domain and all the names you want for the puppet master & CA.
Then try to restart the puppet master service, clean the slave certname from the master, remove all /var/lib/puppet/ssl/ folder from the slave, and run puppet again.
What puppet isn't telling you is that there is a cert mismatch. The master disconnects as soon as it determines that the cert is invalid or a mismatch. Because the disconnect is so sudden, puppet isn't told why it happens.
When this happens puppet could, for example, change that error message to be, "Hey! Here's a list of things you might check." and then suggest things like verify the cert expiration date, cert mismatch, etc. However why would anyone do that?
Here's one way you can get into this situation: Set up two puppet client machines with the same name by mistake. The second machine to use that name will work, but the first machine will no longer work.
How might someone get into that situation? Two machines can't have the same name! Of course not. But we have seen situations like this:
Machine A, B, C, D, E are all Puppet clients.
Machine C gets wiped and reloaded. The technician accidentally calls it "B". To get it working with Puppet, they "puppet cert clean B".
The technician realizes their mistake and reconfigures machine C with the proper name, performs "puppet cert clean C", and machine C now works fine.
A week later someone notices that machine B hasn't been able to talk to the master. It gets this error message. After hours of debugging they see that the client cert has one serial number but the master expects that client to have a very different serial number. Machine B's cert is cleaned, regenerated, etc. and everything continues.
Should Puppet Labs update the error message to hint that this may be the problem? They could, but then I wouldn't get rep points for writing this awesome answer. Besides, technicians should never make such a mistake, so why handle a case that obviously should never happen... except when it does.
Make sure that you are running puppet as root, or with sudo. I have received this exact error when I was my normal user and ran "puppet agent -t" without elevating my privileges.
Sorry but I am a newbie... I have checked other questions but nothing has worked and I am not great with SSH.
Followed the steps to connect to EC2 with SSH in Eclipse. Worked like a charm. Then I terminated the working server and started a new instance.
Now I can't connect and receive
RSEG1066 "Failed to connect sshd on server name" Auth failed
Also Port 22 is open ->
Port 22 (SSH) Source: 0.0.0.0/0
My SSH connection references the new hostname and I have applied my .pem file via rsa. Any thoughts? What else should I check?
Thank you.
Seems many people are having this problem with AWS when terminating an instance and launching a new instance. Here is what I did to solve the problem for me.
Terminated instance
Deleted key pair from AWS console
Deleted key pair from client
Launched a new instance
When prompted, used a different name for my key pair (.pem) file
Choose the default security group
Added SSH / Port 22 inbound access to the security group
Connected (with user *ubuntu* since I am using an ubunutu server)
And if using Eclipse RSE like the tutorial link in the original question, be sure to restart Eclipse before connecting.