Adding slave in PVM asks for password - linux

I tried to add slave in master machine. But when it adds it ask for password. That I didn't understand.
Master = jhamb
Slave = naveen, raja, gaurav
Please solve below error. Looking for your kind response.
Snapshot of console :-
when I try to add any hosts it shows these lines
0successful
HOST DTID
ANY NAME NO SUCH HOST
vim /etc/hosts shows :-
# Do not remove the following line, or various programs
# that require network functionality will fail.
#127.0.0.1 localhost.localdomain localhost
10.40.54.180 gaurav.my.domain #node 1 slave
10.40.54.92 naveen.my.domain #node 2 slave
10.40.55.31 raja.my.domain #node 3 slave
10.40.55.113 localhost.localdomain #node 4 master
#::1 localhost6.localdomain6 localhost6
EDITED
I write here, about my work, what I do till now
Download pvm3 tar file.
Setup all the variables to run PVM.
export PVM_RSH=/ur/bin/ssh
make passwordless connection between master and slave.
Run simple code on single machine, it works.
When I tried to add slave on master, by using command
add naveen.my.domain
it says the same, as of above image.
I think now it is sufficient information.
EDIT NO. 2
when I run ssh -v naveen#10.40.54.92, it says,
......
.....
debug1: Authentications that can continue: publickey, password
debug1: Next Authentication method: publickey
debug1: Trying private key: /root/.ssh/identity
debug1: Offering public key: /root/.ssh/id_rsa
debug1: Server accepts key:pkalg ssh-rsa blen 277
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).
debug1: channel 0:new [client-session]
debug1: Entering Interactive session.
debug1: Sending environment.
.......
.....

When you add a slave, PVM tries to start pvmd on that machine. To do that, it will try to login via ssh(1). So the line "user#host password:" are from ssh.
You can try it yourself:
> ssh naveen.my.domain
This article explains what you can do to allow ssh login onto a different machine without giving it a password every time and without compromising the security of SSH: 3 Steps to Perform SSH Login Without Password Using ssh-keygen & ssh-copy-id
EDIT Here is the important part of the image above:
Verifying Local Path to "rsh"
Rsh found in /usr/bin/ssh - O.K.
Testing Rsh/Rhosts Access to Host ...
PVM can use rsh(1) and ssh(1) to login remotely. Don't every use rsh(1). It's unsecure, brittle and ugly.
The output suggests that PVM uses ssh. You can verify that by looking at the process list while PVM asks for the password: You should see a ssh child process with PVM as the parent.
So for some reason, your password-less SSH setup is broken.
EDIT 2 Security isn't easy :-) What you need to understand is that there is a software which remembers the password for you. That's the "ssh agent."
When SSH asks you for a password, then there can be many reasons:
The ssh agent isn't running
Your key isn't loaded in the ssh agent
The wrong key is loaded in the ssh agent
You made it work and started a new terminal / new process and that new process doesn't "see" the ssh agent.
To check these:
Make sure you see a ssh agent running with your user ID in the process list.
Make sure the correct key is loaded (add it again if in doubt)
Make sure that ssh naveen works correctly.
Try pvm in the same console where you tried ssh naveen

Related

Ssh fails to use private key from ssh-agent: communication with agent failed

I'm getting an error when using ssh, which tries to use keys from ssh-agent, but fails with this message (when running ssh -v):
debug1: get_agent_identities: ssh_fetch_identitylist: communication with agent failed
Full log
I can see both of my keys added to the agent when running ssh-add -l:
$ ssh-add -l
3072 SHA256:0i3sqR60WRsAOpFVJyw951NUDW01jkAWFB1na921Asd xxxxxx#somehost (RSA)
4096 SHA256:CG6njka821AOd82j1xGFkyiOjwG/yo921KAIOWm3t/4 xxxxxx#anotherhost (RSA)
The same error appears with no keys or one key inside the agent.
I'm running the fish shell on Archlinux, and also tried this under bash, but it doesn't seem to make a difference. The same setup was working for me on Ubuntu. There seem to be no questions about this exact issue, and I'm stuck with no clues.
I found that this problem on my pc is caused by the windows default ssh client which stores my ssh key files. After upgrading to 8.9 with https://github.com/PowerShell/Win32-OpenSSH/releases/tag/v8.9.0.0p1-Beta I solved this problem.

can't ssh login without password through nfs

I have 3 nodes with centos 7 :master,slave01,slave02. i am trying to use ssh login without password among them, I've configured nfs filesystem among them, the master is server, the others are clients.
This is my installation steps of nfs:
on master node:
yum install nfs-utils
vi /etc/exports
In exports file, I add this line
/home/hadoop/.ssh *(sync,rw,no_boot_squash,no_subtree_check,fsid=0)
then start nfs:
service rpcbind start
service nfs start
on client node:
yum install nfs-utils
service rpcbind start
mkdir /home/hadoop/nfs_share
mount -t nfs master:/ /home/hadoop/nfs_share
I'm sure nfs is ok. then I change to hadoop user to configue ssh without password.
on master node:
ssh-keygen -t rsa
cp ~/.ssh/id_rsa.pub ~/.ssh/authorized_keys
on client node:
ssh-keygen -t rsa
ln -s /home/hadoop/nfs_share/authorized_keys /home/hadoop/.ssh/
cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
that's all, but I can only ssh login master without password, when login slave, it still require to enter password. I've checked authority of /home they are 700 except authorized_keys,the authorized_keys is 644. following is the authorized_keys in my client:
lrwxrwxrwx. 1 hadoop bigdata 1675 authorized_keys -> /home/hadoop/nfs_share/authorized_keys
later I run this command:
ssh slave01 -v
it prints some information may be useful:
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/hadoop/.ssh/id_rsa
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Trying private key: /home/hadoop/.ssh/id_dsa
debug1: Trying private key: /home/hadoop/.ssh/id_ecdsa
debug1: Next authentication method: password
why did it happen?anyone could help me ,thanks in advance.
add1:
I've found this bug is most probably caused by nfs file system. when I modify the value of AuthorizedKeysFile in file /etc/ssh/sshd_config,
just change
AuthorizedKeysFile .ssh/authorized_keys
to
AuthorizedKeysFile /home/hadoop/nfs_share/authorized_keys
It still didn't work. the /home/hadoop/nfs_share is my nfs system file,is located in my slave node. If I don't use the nfs system file ,it is ok. the file which is ok has the same owner ,group and permissions as the nfs system file.

Openldap Client Machine hangs when slapd daemon is stopped on Openldap Server

First i will explain my architecture briefly
Openldap Server: Ubuntu 14.04 machine with openldap installed. I followed this article
https://www.digitalocean.com/community/tutorials/how-to-install-and-configure-a-basic-ldap-server-on-an-ubuntu-12-04-vps
I have added schema for sshpublickey for every posix account
OpenLDAP client: Ubuntu 14.04 with libpam-ldap nscd installed. Again i followed digital ocean link.
https://www.digitalocean.com/community/tutorials/how-to-authenticate-client-computers-using-ldap-on-an-ubuntu-12-04-vps
I changed sshd_config file on OpenLDAP client machine and provided AuthorizedKeysCommand /my/script which queries ldap server and gets sshkey and then i have a key based ssh authentication.
This is working fine so far. Also i have a ubuntu user which is a local user and is not managed by LDAP.
Now when i stop the slapd daemon on Openldap Server machine then
my active ssh session as ubuntu user on client machine hangs(not able to restart any service or run basic commands like ls or cat). Even when i try to login into client machine as ubuntu user which is not managed by LDAP, it fails(it succeeds the authentication but fails to get enviornment variable and open an interactive session )
Excerpt from ssh -v ubuntu#IP
debug1: Authentication succeeded (publickey).
Authenticated to 54.200.221.217 ([54.200.221.217]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions#openssh.com
debug1: Entering interactive session.
It stucks there and then timedout.
What is the reason behind this? Also is there any flaw with my architecture. I don't want password based ssh as it is prone to hacking.
The reason is that you stopped slapd, of course, and the cure is not to do it. It should be running at all times.

EC2 ssh Permission denied (publickey,gssapi-keyex,gssapi-with-mic)

I got this permission denied problem when I want to ssh to my ec2 host. I tried existing solution chmod 600 "My.pem" but still didn't work. Here is my debug information:
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 21: Applying options for *
debug1: Connecting to 54.223.47.74 [54.223.47.74] port 22.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file My.pem type -1
debug1: key_load_public: No such file or directory
debug1: identity file My.pem-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.9
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1
debug1: match: OpenSSH_6.6.1 pat OpenSSH_6.6.1* compat 0x04000000
debug1: Authenticating to 54.223.47.74:22 as 'root'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client chacha20-poly1305#openssh.com <implicit> none
debug1: kex: client->server chacha20-poly1305#openssh.com <implicit> none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:tfjxcE5kePSv1cJK7SWBp/56kgm2DQkyPLSLZ4d73Io
debug1: Host '54.223.47.74' is known and matches the ECDSA host key.
debug1: Found key in /Users/tan/.ssh/known_hosts:24
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic
debug1: Next authentication method: publickey
debug1: Trying private key: My.pem
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic
debug1: No more authentication methods to try.
Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
I resolved this issue in my centos machine by using command:
ssh -i <Your.pem> ec2-user#<YourServerIP>
It was about userName which was ec2-user in my case.
Referenced From: AMAZONTroubleshooting
You can find default usernames of ec2 instances here:
https://alestic.com/2014/01/ec2-ssh-username/
But in case you want to find the username of your instance:
click on the Connect button to see the default username.
After finding the username, run this command, to ensure your key is not publicly viewable.
chmod 400 <private-key-file.pem>
Then Connect to your instance using its Public DNS or IP:
ssh -i <private-key-file.pem> ec2-user#<public ip>
Solved by connecting with the user centos instead of ec2-user.
I noticed each Linux instance launches with a default Linux system user account. This might be different from ec2-user, depending on your instance. You log in using following command where DefaultUserName stands for a username from the quote below.
ssh -i <Your.pem> <DefaultUserName>#<YourPublicServerIP>
Each Linux instance launches with a default Linux system user account. The default user name is determined by the AMI that was specified when you launched the instance.
For Amazon Linux 2 or the Amazon Linux AMI, the user name is ec2-user.
For a CentOS AMI, the user name is centos.
For a Debian AMI, the user name is admin.
For a Fedora AMI, the user name is ec2-user or fedora.
For a RHEL AMI, the user name is ec2-user or root.
For a SUSE AMI, the user name is ec2-user or root.
For an Ubuntu AMI, the user name is ubuntu.
Otherwise, if ec2-user and root don't work, check with the AMI provider.
Apart from the username issue mentioned here, it can very well be an issue with.
permissions on the instance
public key on the instance not matching the public key you have available locally in your .pem file.
The following link Method 1 resolved it for me. https://aws.amazon.com/premiumsupport/knowledge-center/ec2-linux-fix-permission-denied-errors/
For me it was the public key mismatch. and the is how I resolved it. I am on Mac which comes with an ssh-client.
You can get your local public key from your .pem file by running the following command:
ssh-keygen -y -f /path_to_key_pair/my-key-pair.pem
On your instance navigate to your authorized_keys file which will typically be found here:
/home/username/.ssh/authorized_keys
Add your public key to this file. Save and Done. That should do it.
Just a little context for why I ran into the issue. I had to create a new .pem file because I lost the one I downloaded when I launched the instance. For security reasons, this file cannot be downloaded again. As a I created a new .pem file, this created a new public key with it. This public key needs to be update manually on the instance as the authorized_keys file is still pointing to the old public key.
There is more formal 9 step process to get this sorted as well. See here.
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/replacing-lost-key-pair.html
Recently I went through this issue,
Accidently I have changed Home permission using, chmod -R g+rw .
it changed .ssh folder permission.
If nothing work out,
Create Temp Instance on Amazon-EC2
Detach Your Server storage (Before that Down your source Machine)
Mount it as secondary storage in Temp Instance
Do below permission changes,
[ec2-user ~]$ chmod 600 mount_point/home/ec2-user/.ssh/authorized_keys
[ec2-user ~]$ chmod 700 mount_point/home/ec2-user/.ssh
[ec2-user ~]$ chmod 700 mount_point/home/ec2-user
Unmount your Source Disk from Temp Instance
Attach it back to source Machine
Now Use same command to login,
ssh -i FileName.pem username#MachineIP
For More Details see this AWS Trouble Shooting Docs
add user to /etc/sshd_special_user
Check if you are in the same directory where your key is there.
I had the same problem and figured out that it was the wrong directory form where I tried to connect
cd .ssh
rm authorized_keys
file or edit and remove the saved key for the machine you are trying to access.
Change permissions on the key file with chmod 400 keyname (make sure keyname matches exactly as you have it on Amazon).
Try again with ec2-user#IPaddress -i keypair.pem
Make sure you are in the same directory where you have your .pem file.
use command, chmod 0400 example.pem
then use command, ssh -i example.pem ec2-user#YOUR-IP
Make sure the ssh command specifies the ec2 user:
# ec2 user is missing
ssh -i <identity_file.pem> <hostname>
# ec2 user is specified
ssh -i <identity_file.pem> ec2-user#<hostname>
I had the same problem, and, in my case, the problem was the file "My.pem" should be created with the admin user
So, the solution was, first create the file "My.pem" with sudo and change the permison to 400
$ sudo su
$ sudo vim My.pem
#paste the content
$ sudo vim chmod 400 My.pem
$ ssh -i My.pem user#host
# Login ok
I had the same issue but in my case it was because I created a new key to connect from a different device. The key pairs only get added when you create a new instance, if you want to create a new key after the instance has been created you will have to add it manually.
You can follow this guide here https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html#identify-key-pair-specified-at-launch
or
ssh into the AWS instance using your old key pair
cd into the ~/.ssh folder and
open authorized_keys file using nano or whatever you like
then go to you new .pem key pair and retrieve the public key using
ssh-keygen -y -f /path_to_key_pair/my-key-pair.pem
copy the returned public key and paste it inside authorized_keys file below your other keys , save and exit.
chmod 400 my-key-pair.pem if you haven't already
Then you should be all good to connect using your new key pair.
On Mac:
cd ~/.ssh
sudo nano known_hosts
And delete the info of the host with the problem.
Well, The default user name for your EC2 instance is determined by the AMI that was specified when you launched the instance.
For Amazon Linux 2 or the Amazon Linux AMI, the user name is ec2-user.
Therefore, you will need to use ec2-user when SSH.
Afterwards, grant file permissions via chmod in Linux. (Make sure you are in the same directory where you have your .pem file)
use command, chmod 400 <Ur_Pem_File_Name>.pem
Now use command, ssh -i <Ur_Pem_File_Name>.pem ec2-user#<Public_IP_of_EC2>
By doing the above, I was able to SSH into my EC2 via CLI.
Check if selinux is blocking access to the file.
Try the following:
restorecon -r -vv .ssh/authorized_keys
I had same issue and resolved by -
in Window machine , Save key into Pageant
See https://aws.amazon.com/es/blogs/security/securely-connect-to-linux-instances-running-in-a-private-amazon-vpc/
and then in Putty select SSH->Auth-> Check "Allow Agent Forwarding" & put ppk file into "Private Key file for Authentication" .
if you are connecting ec2 via ssh using your terminal (.zsh) on mac then you have to change the name from .pem to .cer in all the commands because on mac your downloaded key_pair file has an extension .cer,
otherwise, you can follow the commands same as given on aws.
In addition to harneet singh's answer you can also change your ec2 instance user name from "ec2-user". navigate to EC2 instance->connect-> ec2InstanceConnect->user-name.
A good solution for this: https://bobbyhadz.com/blog/aws-ssh-permission-denied-publickey
In the AWS EC2 console, click on the checkbox next to your instance's name, then click on Actions and select Connect. Click on the SSH client tab and copy the ssh command example.
Soluction in terminal for error
Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).
ssh-keygen -f " ~/.ssh/known_hosts" -R xx.xx.xxx.xxx
xx - ip host
http://pastebin.com/YpqGSJ2E
You have to run below commands for ssh to your ec2 host
ssh -i <user.pem> ec2-user#<public ip>
if have
WARNING: UNPROTECTED PRIVATE KEY FILE!
Permissions 0644 for 'user.pem' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
then run chmod 0400 <user.pem>
after run above command run ssh -i <user.pem> ec2-user#<public ip>

Not able to "git pull" - Host key verification failed

I've got root access to our production server and I want to deploy the latest version in git to the server but I'm running into the error below when I "git pull" on the folder I want to update.
I've browsed around a bit, but can't find a clear answer on what to do..
The staging server runs on the same machine, but just in a different folder and when I pull on that folder it all goes fine.
I'm not very experienced when it comes to Linux, so please help me out with a clear answer on how to fix :-)
Otherwise I have access to anything I need
p.s.
This has worked in the past, so I'm assuming it's got something to do with the SSH key
Error:
###########################################################
# WARNING: POSSIBLE DNS SPOOFING DETECTED! #
###########################################################
The ECDSA host key for www.site.org has changed,
and the key for the corresponding IP address x.x.x.x
is unknown. This could either mean that
DNS SPOOFING is happening or the IP address for the host
and its host key have changed at the same time.
###########################################################
# WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! #
###########################################################
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
*************
Please contact your system administrator.
Add correct host key in /root/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /root/.ssh/known_hosts:1
remove with: ssh-keygen -f "/root/.ssh/known_hosts" -R gitlab.site.org
ECDSA host key for gitlab.site.org has changed and you have requested strict checking.
Host key verification failed.
In the log you see the following text:
(...)
Please contact your system administrator.
Add correct host key in /root/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /root/.ssh/known_hosts:1
remove with: ssh-keygen -f "/root/.ssh/known_hosts" -R gitlab.site.org
ECDSA host key for gitlab.site.org has changed and you have requested strict checking.
Host key verification failed.
So it is a matter of performing the command that is suggested there:
ssh-keygen -f "/root/.ssh/known_hosts" -R gitlab.site.org
Windows:
Go to /Users/Abhilash/.ssh/known_hosts and delete the contents in it and save.
Linux / Mac:
Go to ~/.ssh/
nano known_hosts
remove content inside and save ctrl+O
Note:
You will be promted to save the key while pushing again.
I have also faced the same issue after following these steps it worked for me.
For macOS:
Step 1: Go to Folder or use command+shift+g
Step 2: type "~/.ssh/"
Step 3: Open "known_hosts" file and Remove all the content
Step 4: Now Open terminal and pull from another branch, It will ask for password give your system password.
It will work surely.
All of the other answers introduce security risks.
This error appears because you have a record in your known_hosts file which says that the server should have a particular ssh key. But when you try to connect, the server has sent a different ssh key which does not match the one in your known_hosts file. Your particular error message says:
Offending ECDSA key in /root/.ssh/known_hosts:1
This means that the first line in the known_hosts file is different to what the remote server is sending.
The secure way to fix the issue is as follows:
Find out what the correct key fingerprint should be from a trustworthy source. e.g. Here you can find the correct fingerprints for GitHub and GitLab. (If your organisation self-hosts GitLab, you will need to talk to your administrator to get the ssh key fingerprints.)
CHECK that the existing fingerprint in your known_hosts file is correct.
You can run ssh-keygen -lf ~/.ssh/known_hosts (or /root/.ssh/known_hosts in your case) to generate SHA256 fingerprints from your known_hosts file. Your error message says that the problem is with the first key. Find the equivalent SHA256 fingerprint on GitHub or GitLab and check if it matches exactly.
e.g. Here is the output of the above command:
256 SHA256:HbW3g8zUjNSksFbqTiUWPWg2Bq1x8xdGUrliXFzSnUw gitlab.com (ECDSA)
and here is the ECDSA SHA256 fingerprint from the GitLab website:
HbW3g8zUjNSksFbqTiUWPWg2Bq1x8xdGUrliXFzSnUw
If the existing fingerprint from known_hosts matches the official fingerprint from the GitHub or GitLab website, then ssh has detected a Man in the Middle (MitM) attack. STOP. Do not connect to the server. Try connecting from a different internet connection. Talk to your administrator.
If the existing fingerprint in known_hosts does not match the official fingerprint, then either you were under a MitM attack previously, or the server hosting GitLab has changed its ssh keys. You can delete the fingerprint from your known_hosts file. (Note: Only delete the specific fingerprint which is causing trouble.) Next time you connect to GitLab, you will be prompted to add the new fingerprint to the known_hosts file.
The authenticity of host 'gitlab.com (172.65.251.78)' can't be established.
ECDSA key fingerprint is SHA256:HbW3g8zUjNSksFbqTiUWPWg2Bq1x8xdGUrliXFzSnUw.
Are you sure you want to continue connecting (yes/no/[fingerprint])?
Double-check that the fingerprint matches what is shown on the GitHub or GitLab website, then type yes or no accordingly.
Try replacing ssh with:
ssh -oStrictHostKeyChecking=no
since if the key hasn’t been accepted yet, then it will ask do you want to accept it yes/no. Alternatively, you can also do this in your CI file just before the SSH command:
echo "StrictHostKeyChecking no" >> ~/.ssh/config
courtesy:
https://forum.gitlab.com/t/error-host-key-verification-failed/77315/3
if you'd like to remove this message permanently you can edit your ssh config file (~/.ssh/config) to include:
Host {YOUR HOST HERE}
StrictHostKeyChecking no
UserKnownHostsFile /dev/null

Resources