I have tried these steps a number of time but failing. Did lot of RnD but could not fix the issue.
I am using CentOS running on Oracle VM.
I am trying to connect from CentOS host -> Jenkins -> Remote Host using SSH
My present working directory is : /root/connect2nareshc/jenkins_0_to_hero/jenkins_image
I did ssh-keygen -f remote-key to generate public and private keys.
In the directory /root/connect2nareshc/jenkins_0_to_hero/jenkins_image I have Dockerfile as follows:
FROM centos:7
RUN yum -y install openssh-server
RUN useradd remote_user && \
echo "1234" | passwd remote_user --stdin && \
mkdir /home/remote_user/.ssh && \
chmod 700 /home/remote_user/.ssh
COPY remote-key.pub /home/remote_user/.ssh/authorized_keys
RUN chown remote_user:remote_user -R /home/remote_user/.ssh && \
chown 600 /home/remote_user/.ssh/authorized_keys
RUN ssh-keygen -A
CMD /usr/sbin/sshd -D
In one directory above in /root/connect2nareshc/jenkins_0_to_hero, I have docker-compose.yml as follows:
version: '3'
services:
jenkins:
container_name: jenkins_yml
image: "jenkins/jenkins:lts"
ports:
- 8080:8080
networks:
- net
remote_host:
container_name: remote-host
image: remote_host
build:
context: /root/connect2nareshc/jenkins_0_to_hero/jenkins_image
networks:
- net
networks:
net:
I execute the following command and it works fine. I.e. From host I connect to Jenkins and from Jenkins I connect to remote_host using password.
docker-compose build
docker-compose up -d
docker exec -it jenkins_yml bash
ssh remote_user#remote_host
#Enter password 1234 when prompted.
When I try to connect using keys, I am not able to:
docker cp remote-key jenkins_yml:/tmp/remote-key
docker exec -it jenkins_yml bash
cd /tmp
ssh -i remote-key remote_user#remote_host
Instead it prompts me to connect with password.
While on remote_host I did ls -altr on /var/log and got following output. I cannot find auth.log
drwxr-xr-x. 1 root root 4096 May 4 15:36 ..
-rw-r--r--. 1 root root 193 May 4 15:36 grubby_prune_debug
-rw-------. 1 root utmp 0 May 4 15:36 btmp
drwxr-xr-x. 1 root root 4096 May 4 15:37 .
-rw-------. 1 root root 1751 Jul 28 16:35 yum.log
-rw-------. 1 root root 64064 Jul 28 16:36 tallylog
-rw-rw-r--. 1 root utmp 1152 Jul 29 03:17 wtmp
-rw-r--r--. 1 root root 292292 Jul 29 03:17 lastlog
I'm using a Android cell phone. I write python program and run the program in Termux. But there some lib can't be installed or use in Android cell phone, sklearn and tensorflow for example. So I decided to try to use a docker container for my programing envirment.
I create a docker image and update it to docker-hub: zwdnet/mypython. Then I installed qemu in Termux,and installed Alpine Linux (alpine-virt-3.10.1-x86_64) in Termux. I followed this pages' method(It is a Chinese blog, not English): https://stageguard.top/2019/08/15/run-docker-on-qemu-alpine/#1-Docker
After this, I use the command
qemu-system-x86_64 -hda python.img -boot c -m 4096 -netdev user,id=nde1,hostfwd=tcp::2222-:22 -device e1000,netdev=nde1,id=d-net1 -nographic &
start the alpine linux in back and
ssh root#localhost -p 2222
login. (After then I installed the docker and run the container success, that is another question.)
Now I want to login Apline linux without enter the passwords.
First I use
ssh-keygen -t rsa
generate the key, and use
ssh-copy-id -i ./mykey.pub root#localhost -P 2222
to sent the pub key to the Apline linux and changed the /etc/ssh/sshd_config file.
At last I restarted the sshd service and logout.
But when I login again, It is ask me to enter the password again.
I thought maybe that is because I login in with root. So I login and create a new username, and repeat the ahead operators. But I failed. The ssh ask me to enter password again.
This is my mod of ~/.ssh and the key files.
$ssh zym#localhost -p 2222 "ls -la"
zym#localhost's password:
total 20
drwxr-sr-x 3 1000 zym 4096 May 16 15:04 .
drwxr-xr-x 3 root root 4096 May 16 14:44 ..
-rw------- 1 1000 zym 251 May 16 15:04 .ash_history
drwx------ 2 1000 zym 4096 May 16 14:56 .ssh
-rw------- 1 root zym 883 May 16 15:04 .viminfo
$ ssh zym#localhost -p 2222 "ls -la .ssh"
zym#localhost's password:
total 12
drwx------ 2 1000 zym 4096 May 16 14:56 .
drwxr-sr-x 3 1000 zym 4096 May 16 15:04 ..
-rw------- 1 root zym 571 May 16 14:56 authorized_keys
and this is my /etc/ssh/sshd_config file:
# $OpenBSD: sshd_config,v 1.103 2018/04/09 20:41:22 tj Exp $
# This is the sshd server system-wide configuration file. See
# sshd_config(5) for more information.
# This sshd was compiled with PATH=/bin:/usr/bin:/sbin:/usr/sbin
# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented. Uncommented options override the
# default value.
#Port 22
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::
#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_ecdsa_key
#HostKey /etc/ssh/ssh_host_ed25519_key
# Ciphers and keying
#RekeyLimit default none
# Logging
#SyslogFacility AUTH
#LogLevel INFO
# Authentication:
#LoginGraceTime 2m
PermitRootLogin yes
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10
PubkeyAuthentication yes
# The default is to check both .ssh/authorized_keys and .ssh/authorized_keys2
# but this is overridden so installations will only check .ssh/authorized_keys
AuthorizedKeysFile .ssh/authorized_keys
#AuthorizedPrincipalsFile none
#AuthorizedKeysCommand none
#AuthorizedKeysCommandUser nobody
# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes
# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication yes
#PermitEmptyPasswords no
# Change to no to disable s/key passwords
#ChallengeResponseAuthentication yes
# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no
# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes
# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication. Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
#UsePAM no
#AllowAgentForwarding yes
# Feel free to re-enable these if your use case requires them.
AllowTcpForwarding no
GatewayPorts no
X11Forwarding no
#X11DisplayOffset 10
#X11UseLocalhost yes
#PermitTTY yes
#PrintMotd yes
#PrintLastLog yes
#TCPKeepAlive yes
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS no
#PidFile /run/sshd.pid
#MaxStartups 10:30:100
#PermitTunnel no
#ChrootDirectory none
#VersionAddendum none
# no default banner path
#Banner none
# override default of no subsystems
Subsystem sftp /usr/lib/ssh/sftp-server
# Example of overriding settings on a per-user basis
#Match User anoncvs
# X11Forwarding no
# AllowTcpForwarding no
# PermitTTY no
# ForceCommand cvs server
The login information is
$ ssh zym#localhost -p 2222 -v
OpenSSH_8.2p1, OpenSSL 1.1.1g 21 Apr 2020
debug1: Reading configuration data /data/data/com.termux/files/usr/etc/ssh/ssh_config
debug1: Authenticator provider $SSH_SK_PROVIDER did not resolve; disabling
debug1: Connecting to localhost [127.0.0.1] port 2222.
debug1: Connection established.
debug1: identity file /data/data/com.termux/files/home/.ssh/id_rsa type 0
debug1: identity file /data/data/com.termux/files/home/.ssh/id_rsa-cert type -1
debug1: identity file /data/data/com.termux/files/home/.ssh/id_dsa type -1
debug1: identity file /data/data/com.termux/files/home/.ssh/id_dsa-cert type -1
debug1: identity file /data/data/com.termux/files/home/.ssh/id_ecdsa type -1
debug1: identity file /data/data/com.termux/files/home/.ssh/id_ecdsa-cert type -1
debug1: identity file /data/data/com.termux/files/home/.ssh/id_ecdsa_sk type -1
debug1: identity file /data/data/com.termux/files/home/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file /data/data/com.termux/files/home/.ssh/id_ed25519 type -1
debug1: identity file /data/data/com.termux/files/home/.ssh/id_ed25519-cert type -1
debug1: identity file /data/data/com.termux/files/home/.ssh/id_ed25519_sk type -1
debug1: identity file /data/data/com.termux/files/home/.ssh/id_ed25519_sk-cert type -1
debug1: identity file /data/data/com.termux/files/home/.ssh/id_xmss type -1
debug1: identity file /data/data/com.termux/files/home/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.2
debug1: Remote protocol version 2.0, remote software version OpenSSH_8.1
debug1: match: OpenSSH_8.1 pat OpenSSH* compat 0x04000000
debug1: Authenticating to localhost:2222 as 'zym'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305#openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305#openssh.com MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:Vwx+lpRpyl04g5gaO73Es9C1IslCcD7f9CUfBFyi96M
debug1: Host '[localhost]:2222' is known and matches the ECDSA host key.
debug1: Found key in /data/data/com.termux/files/home/.ssh/known_hosts:3
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey in after 134217728 blocks
debug1: Will attempt key: /data/data/com.termux/files/home/.ssh/id_rsa RSA SHA256:l/1hMa3CC1MHkHsJT6R7CRZJzYEXU
debug1: Will attempt key: /data/data/com.termux/files/home/.ssh/id_dsa
debug1: Will attempt key: /data/data/com.termux/files/home/.ssh/id_ecdsa
debug1: Will attempt key: /data/data/com.termux/files/home/.ssh/id_ecdsa_sk
debug1: Will attempt key: /data/data/com.termux/files/home/.ssh/id_ed25519
debug1: Will attempt key: /data/data/com.termux/files/home/.ssh/id_ed25519_sk
debug1: Will attempt key: /data/data/com.termux/files/home/.ssh/id_xmss
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2->
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering public key: /data/data/com.termux/files/home/.ssh/id_rsa RSA SHA256:l/1hMa3CC1MHkHsJT6R7CRZJzU
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Trying private key: /data/data/com.termux/files/home/.ssh/id_dsa
debug1: Trying private key: /data/data/com.termux/files/home/.ssh/id_ecdsa
debug1: Trying private key: /data/data/com.termux/files/home/.ssh/id_ecdsa_sk
debug1: Trying private key: /data/data/com.termux/files/home/.ssh/id_ed25519
debug1: Trying private key: /data/data/com.termux/files/home/.ssh/id_ed25519_sk
debug1: Trying private key: /data/data/com.termux/files/home/.ssh/id_xmss
debug1: Next authentication method: keyboard-interactive
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: password
zym#localhost's password:
I copyed the mykey and mykey.pub to /data/data/com.termux/files/home/.ssh/ , no use.
Could you please help me to see how to sovle this problem? Thanks!
I'm a Chinese and my English is poor. Please forgive me for the words errors.
Thanks #MarcoLucidi ,but the -i in ssh dose not work.
$ ssh -i ./mykey -p 2222 zym#localhost -v
OpenSSH_8.2p1, OpenSSL 1.1.1g 21 Apr 2020
debug1: Reading configuration data /data/data/com.termux/files/usr/etc/ssh/ssh_config
debug1: Authenticator provider $SSH_SK_PROVIDER did not resolve; disabling
debug1: Connecting to localhost [127.0.0.1] port 2222.
debug1: Connection established.
debug1: identity file ./mykey type 0
debug1: identity file ./mykey-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.2
debug1: Remote protocol version 2.0, remote software version OpenSSH_8.1
debug1: match: OpenSSH_8.1 pat OpenSSH* compat 0x04000000
debug1: Authenticating to localhost:2222 as 'zym'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305#openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305#openssh.com MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:Vwx+lpRpyl04g5gaO73Es9C1IslCcD7f9CUfBFyi96M
debug1: Host '[localhost]:2222' is known and matches the ECDSA host key.
debug1: Found key in /data/data/com.termux/files/home/.ssh/known_hosts:3
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey in after 134217728 blocks
debug1: Will attempt key: ./mykey RSA SHA256:4rVLy6uWZoHmCMqYYyaASSV2iaoIdIbvIDtA1EBNuW0 explicit
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2->
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering public key: ./mykey RSA SHA256:4rVLy6uWZoHmCMqYYyaASSV2iaoIdIbvIDtA1EBNuW0 explicit
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: keyboard-interactive
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: password
zym#localhost's password:
i discovered that alpine linux image is shipped with a root user that has no password set yet. And for some reason it seems like not having a password set for root prevents the public key authentication from succeeding when trying to ssh on root account.
try setting a password to root user: ex:
echo 'root:dummy_passwd'|chpasswd
and then retry:
shh root#<ip_address>
now the command should work with the public key authentication. don't ask me why.
note: i discovered that because i could connect to a normal user session but not to root session with the same sshd_config, on the same machine, and with the same authorized_keys file (with correct permissions and correct ownership). that was the only thing i could think of and it made the difference.
You indicated in a comment that this user "zym" has UID 0. You also show that zym's home directory and .ssh directory are owned by UID 1000:
drwxr-sr-x 3 1000 zym 4096 May 16 15:04 .
drwxr-xr-x 3 root root 4096 May 16 14:44 ..
-rw------- 1 1000 zym 251 May 16 15:04 .ash_history
drwx------ 2 1000 zym 4096 May 16 14:56 .ssh
The OpenSSH server enforces strict permissions on the authorized_keys file:
~/.ssh/authorized_keys
Lists the public keys (DSA, ECDSA, Ed25519, RSA) that can be used for logging in as this user. The format of this file is described above. The content of the file is not highly sensitive, but the recommended permissions are read/write for the user, and not accessible by others.
If this file, the ~/.ssh directory, or the user's home directory are writable by other users, then the file could be modified or replaced by unauthorized users. In this case, sshd will not allow it to be used unless the StrictModes option has been set to “no”.
The actual permissions-checking performed by sshd is complicated. But basically it checks for two things:
The authorized_keys file must be owned by the user logging in, and it must not be group- or world-writable.
The directory containing authorized_keys, the .ssh directory, and the home directory must be owned by root or the user logging in, and must not be group- or world-writable.
The OpenSSH server is probably ignoring your authorized_keys file because these requirements aren't being met. You're trying to log in as a user with UID 0, while the authorized_keys file, .ssh directory, and home directory are owned by a different UID.
You can fix this by making the UIDs match. Either set "zym" to have UID 1000, or change zym's home directory and the files contained there to be owned by zym's actual UID of 0.
Alternately, you can disable this permissions check by setting StrictModes to "no" in sshd_config on the server and restarting sshd.
After trying to disable my root user's password with passwd -l, or by directly setting the password hash to ! in /etc/shadow, I was surprised to find my attempts to log in via ssh key rejected with "User root not allowed because account is locked" reported in /var/log/messages.
Based on guidance from https://unix.stackexchange.com/a/193131/353183, I changed the password hash in /etc/shadow from ! to *, and that let me log in successfully.
Hashes beginning with an exclamation point signify a locked user, and OpenSSH rejects logins for locked users even when they use an authorized key. The asterisk still disables password logins by serving as an impossible-to-match hash, but it does not mark the account as locked. For more details, see https://stackoverflow.com/a/25211719/2402324.
I can connect from my windows PC using putty to my AMI E2C linux instances but I cannot ssh from one instance to another. I get the following error message, I have just copied the last part of the error message:
debug1: Found key in /home/ec2-user/.ssh/known_hosts:3
debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /home/ec2-user/.ssh/id_rsa
debug1: Trying private key: /home/ec2-user/.ssh/id_dsa
debug1: Trying private key: /home/ec2-user/.ssh/id_ecdsa
debug1: Trying private key: /home/ec2-user/.ssh/id_ed25519
debug1: No more authentication methods to try.
Permission denied (publickey).
the security group for all servers has SSH open to source 0.0.0.0
I have tried creating new ssh keys, ssh-keygen -t -rsa, and copying and pasting the content of the .pub file to /.ssh/authorized_keys file on the other server. But it still does not work.
I have tried copying contents of both files to the other server to /.ssh keeping the same file name and running chmod 600 again both files. But still it does not work.
I cannot believe it, I have been stuck on this issue for 2 days.
On closer inspection of the ID_RSA file I created on the server I wanted to connect to, which I had a copy and pasted the public key from the other server, did not have all of the key pasted. The copy and paste function missed off the first few characters of the key.
Once I put those in the ssh connection worked!
It might be that you're creating key with non-standard name.
This is how I do in this case:
server #1:
$ ls -la ~/
...
drwx------ 2 ec2-user ec2-user 4096 Mar 16 00:27 .ssh
...
$ ls -l ~/.ssh
total 12
-rw------- 1 ec2-user ec2-user 731 Mar 3 16:05 authorized_keys
-rw-r--r-- 1 ec2-user ec2-user 2220 Mar 17 11:39 known_hosts
-rw------- 1 ec2-user ec2-user 3326 Mar 4 00:48 roman.pem
server #2:
$ ls -la ~/
...
drwx------ 2 ec2-user ec2-user 4096 Mar 17 12:10 .ssh
...
$ ls -l ~/.ssh
total 4
-rw------- 1 ec2-user ec2-user 731 Mar 17 12:10 authorized_keys
authorized_keys has only one record and is identical to the one from server #1
This is the command I use for connection from server #1 to server #2:
$ ssh -v <server#2-ip> -i ~/.ssh/roman.pem
As you can see, I use -i to specify full path to key name.
Update:
Also, custom key could be added to ssh-agent on server #1: ssh-add ~/.ssh/roman.pem in order to skip -i switch.
Example of the problem:
docker run -ti -v my_passwd:/etc/passwd -v my_shadow:/etc/shadow --rm centos
[root#681a5489f3b0 /]# useradd test # does not work !?
useradd: failure while writing changes to /etc/passwd
[root#681a5489f3b0 /]# ll /etc/passwd /etc/shadow # permission check
-rw-r--r-- 1 root root 157 Oct 8 10:17 /etc/passwd
-rw-r----- 1 root root 100 Oct 7 18:02 /etc/shadow
The similar problem arises when using passwd:
[root#681a5489f3b0 /]# passwd test
Changing password for user test.
New password:
BAD PASSWORD: The password is shorter than 8 characters
Retype new password:
passwd: Authentication token manipulation error
I have tried using the ubuntu image, but the same problem arises.
I can manually edit passwd file and shadow file from within container.
I am getting the same problem on following two machines:
Host OS: CentOS 7 - SELinux Disabled
Docker Version: 1.8.2, build 0a8c2e3
Host OS: CoreOS 766.4.0
Docker version: 1.7.1, build df2f73d-dirty
I've also opened issue on GitHub: https://github.com/docker/docker/issues/16857
It's failing because passwd manipulates a temporary file, and then attempts to rename it to /etc/shadow. This fails because /etc/shadow is a mountpoint -- which cannot be replaced -- which results in this error (captured using strace):
102 rename("/etc/nshadow", "/etc/shadow") = -1 EBUSY (Device or resource busy)
You can reproduce this trivially from the command line:
# cd /etc
# touch foo
# mv foo shadow
mv: cannot move 'foo' to 'shadow': Device or resource busy
You could work around this by mounting a directory containing my_shadow and my_passwd somewhere else, and then symlinking /etc/passwd and /etc/shadow in the container appropriately:
$ docker run -it --rm -v $PWD/my_etc:/my_etc centos
[root#afbc739f588c /]# ln -sf /my_etc/my_passwd /etc/passwd
[root#afbc739f588c /]# ln -sf /my_etc/my_shadow /etc/shadow
[root#afbc739f588c /]# ls -l /etc/{shadow,passwd}
lrwxrwxrwx. 1 root root 17 Oct 8 17:48 /etc/passwd -> /my_etc/my_passwd
lrwxrwxrwx. 1 root root 17 Oct 8 17:48 /etc/shadow -> /my_etc/my_shadow
[root#afbc739f588c /]# passwd root
Changing password for user root.
New password:
Retype new password:
passwd: all authentication tokens updated successfully.
[root#afbc739f588c /]#
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 7 years ago.
Improve this question
I have 3 CentOS VM and am trying to setup passwordless ssh from any host to any other host. (call them db01,db02,dbmgr)
I have the RSA public keys copied to .ssh/authorized_keys
i.e
db01->.ssh/authorized_keys has entries of public keys from db02, dbmgr
db02->.ssh/authorized_keys has entries of public keys from db01, dbmgr
dbmgr->.ssh/authorized_keys has entries of public keys from db01, db02
I have verified that the public key strings across the host
[abhyas_db01#abhyas ~]$ cat .ssh/id_rsa.pub
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAsT8zUe4or3VCN8C1k0XVyQ9erpEiXDKORnS9rujBTDw1bFdCDnQLngteu+dbHIeZ2O8vrtH6cJVdqSjhGJjlswnhOdH6IfxIrKDb+Rug4LhxSei6jTxH3gq0vmrPzsoy14J/Q1xxAEbtIyc2J6JmupKf/bmafITnijvFUgZ70xlzVs1cmzAaU6+A/te9Oc+HCvpGzDLLUNSQUq8rRhAm8IFDy3+qHk+h2+BQCMx0uDRKGaxXhqur/1l0nzJNL49gANTF4LYmdqU7Vb07Vm7BbIdKwxgc2njAqOPfhE3iBmAeOmmq715Dhf2OO4DY/OdnDSFDo+MZAscf/tk1ZA0hvw== abhyas_db01#abhyas.db01
[abhyas_db02#abhyas ~]$ cat .ssh/id_rsa.pub
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEApkPWB3L9LJNyUW/iFKlJGKTSeIviBRrP6lTvmw7wPGMEto5TFvie4vogaGv6euUNLQiM7HdneNCoZjoeMDgOl7od9ZMZpXNslSX/tPZI0Ha55Mx2T5l7ka4t/Uzm/rzYz3GgNmag8o8buKDCfjXzAMJWU7DnkLFf04rFenzQC3twTIfQKXXnnOo5Fka1f6110xEDuHaRZ24Fesp7T67joSECwjTJvPfFXT3EUMCAXmuzBsFc2fXQmPM/MSGvrBY6pj6ntGQ6+R8OR1yS/2sZudmSb2uxsRnKdhue9E20HEE/tiyL6IByY9s70KRsNarB7GGvVPfZvTXu/N8/TkNHaQ== abhyas_db02#abhyas.db02
[abhyas_db02#abhyas ~]$
[abhyas_mgr#abhyas ~]$ cat .ssh/id_rsa.pub
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEArfc2PvbGmOX638qhFh2h2oZ3ZzP8r177BnclMe22xi+Fe8tj/RGVM5NQStAXulBlwVc2KSWgkAt5+oe7nDoVENWaetapTBaMwJcxiGyJPs7SIrcVOUI4CDaHbXQAM2Bs7EjsGfY7LlFyOCZZWnwEjRMW23wnis6200grleZftrU07Tk05v1rfihlY2pm2dV1mMckoyUOP7gn8MDvLCj6DlFPwcGw6h5siIU0UU0wiSxg8Q3zXdFaXnDXGp3lFic71TzfPidmimu8k2PDZhikz21ypxn1YaDluYJ6Wn+zTgkNFrdV6T7tT27RIzWXAJHT9OMnhpKFa+HTxbTKlecxqw== abhyas_mgr#abhyas.dbmgr
[abhyas_mgr#abhyas ~]$
[abhyas_db01#abhyas ~]$ cat .ssh/authorized_keys
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEApkPWB3L9LJNyUW/iFKlJGKTSeIviBRrP6lTvmw7wPGMEto5TFvie4vogaGv6euUNLQiM7HdneNCoZjoeMDgOl7od9ZMZpXNslSX/tPZI0Ha55Mx2T5l7ka4t/Uzm/rzYz3GgNmag8o8buKDCfjXzAMJWU7DnkLFf04rFenzQC3twTIfQKXXnnOo5Fka1f6110xEDuHaRZ24Fesp7T67joSECwjTJvPfFXT3EUMCAXmuzBsFc2fXQmPM/MSGvrBY6pj6ntGQ6+R8OR1yS/2sZudmSb2uxsRnKdhue9E20HEE/tiyL6IByY9s70KRsNarB7GGvVPfZvTXu/N8/TkNHaQ== abhyas_db02#abhyas.db02
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEArfc2PvbGmOX638qhFh2h2oZ3ZzP8r177BnclMe22xi+Fe8tj/RGVM5NQStAXulBlwVc2KSWgkAt5+oe7nDoVENWaetapTBaMwJcxiGyJPs7SIrcVOUI4CDaHbXQAM2Bs7EjsGfY7LlFyOCZZWnwEjRMW23wnis6200grleZftrU07Tk05v1rfihlY2pm2dV1mMckoyUOP7gn8MDvLCj6DlFPwcGw6h5siIU0UU0wiSxg8Q3zXdFaXnDXGp3lFic71TzfPidmimu8k2PDZhikz21ypxn1YaDluYJ6Wn+zTgkNFrdV6T7tT27RIzWXAJHT9OMnhpKFa+HTxbTKlecxqw== abhyas_mgr#abhyas.dbmgr
[abhyas_db02#abhyas ~]$ cat .ssh/authorized_keys
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAsT8zUe4or3VCN8C1k0XVyQ9erpEiXDKORnS9rujBTDw1bFdCDnQLngteu+dbHIeZ2O8vrtH6cJVdqSjhGJjlswnhOdH6IfxIrKDb+Rug4LhxSei6jTxH3gq0vmrPzsoy14J/Q1xxAEbtIyc2J6JmupKf/bmafITnijvFUgZ70xlzVs1cmzAaU6+A/te9Oc+HCvpGzDLLUNSQUq8rRhAm8IFDy3+qHk+h2+BQCMx0uDRKGaxXhqur/1l0nzJNL49gANTF4LYmdqU7Vb07Vm7BbIdKwxgc2njAqOPfhE3iBmAeOmmq715Dhf2OO4DY/OdnDSFDo+MZAscf/tk1ZA0hvw== abhyas_db01#abhyas.db01
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEArfc2PvbGmOX638qhFh2h2oZ3ZzP8r177BnclMe22xi+Fe8tj/RGVM5NQStAXulBlwVc2KSWgkAt5+oe7nDoVENWaetapTBaMwJcxiGyJPs7SIrcVOUI4CDaHbXQAM2Bs7EjsGfY7LlFyOCZZWnwEjRMW23wnis6200grleZftrU07Tk05v1rfihlY2pm2dV1mMckoyUOP7gn8MDvLCj6DlFPwcGw6h5siIU0UU0wiSxg8Q3zXdFaXnDXGp3lFic71TzfPidmimu8k2PDZhikz21ypxn1YaDluYJ6Wn+zTgkNFrdV6T7tT27RIzWXAJHT9OMnhpKFa+HTxbTKlecxqw== abhyas_mgr#abhyas.dbmgr
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEArfc2PvbGmOX638qhFh2h2oZ3ZzP8r177BnclMe22xi+Fe8tj/RGVM5NQStAXulBlwVc2KSWgkAt5+oe7nDoVENWaetapTBaMwJcxiGyJPs7SIrcVOUI4CDaHbXQAM2Bs7EjsGfY7LlFyOCZZWnwEjRMW23wnis6200grleZftrU07Tk05v1rfihlY2pm2dV1mMckoyUOP7gn8MDvLCj6DlFPwcGw6h5siIU0UU0wiSxg8Q3zXdFaXnDXGp3lFic71TzfPidmimu8k2PDZhikz21ypxn1YaDluYJ6Wn+zTgkNFrdV6T7tT27RIzWXAJHT9OMnhpKFa+HTxbTKlecxqw== abhyas_mgr#abhyas.dbmgr
[abhyas_mgr#abhyas ~]$ cat .ssh/authorized_keys
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAsT8zUe4or3VCN8C1k0XVyQ9erpEiXDKORnS9rujBTDw1bFdCDnQLngteu+dbHIeZ2O8vrtH6cJVdqSjhGJjlswnhOdH6IfxIrKDb+Rug4LhxSei6jTxH3gq0vmrPzsoy14J/Q1xxAEbtIyc2J6JmupKf/bmafITnijvFUgZ70xlzVs1cmzAaU6+A/te9Oc+HCvpGzDLLUNSQUq8rRhAm8IFDy3+qHk+h2+BQCMx0uDRKGaxXhqur/1l0nzJNL49gANTF4LYmdqU7Vb07Vm7BbIdKwxgc2njAqOPfhE3iBmAeOmmq715Dhf2OO4DY/OdnDSFDo+MZAscf/tk1ZA0hvw== abhyas_db01#abhyas.db01
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEApkPWB3L9LJNyUW/iFKlJGKTSeIviBRrP6lTvmw7wPGMEto5TFvie4vogaGv6euUNLQiM7HdneNCoZjoeMDgOl7od9ZMZpXNslSX/tPZI0Ha55Mx2T5l7ka4t/Uzm/rzYz3GgNmag8o8buKDCfjXzAMJWU7DnkLFf04rFenzQC3twTIfQKXXnnOo5Fka1f6110xEDuHaRZ24Fesp7T67joSECwjTJvPfFXT3EUMCAXmuzBsFc2fXQmPM/MSGvrBY6pj6ntGQ6+R8OR1yS/2sZudmSb2uxsRnKdhue9E20HEE/tiyL6IByY9s70KRsNarB7GGvVPfZvTXu/N8/TkNHaQ== abhyas_db02#abhyas.db02
And I am able to ssh to db01 to db02 and the other way around without a password and I am able to ssh to db01 and db02 from dbmgr without a password.
But trying to ssh to dbmgr from db01 or db02 asks for a password.
I am not sure what I am missing.
EDIT:Solved it, by looking at the logs. The logs indicated that there was indeed a permission issue.
14:13:01 localhost sshd[3787]: debug1: userauth-request for user abhyas_mgr service ssh-connection method none
Sep 6 14:13:01 localhost sshd[3787]: debug1: attempt 0 failures 0
Sep 6 14:13:01 localhost sshd[3786]: debug1: PAM: initializing for "abhyas_mgr"
Sep 6 14:13:01 localhost sshd[3786]: debug1: PAM: setting PAM_RHOST to "abhyas.db01"
Sep 6 14:13:01 localhost sshd[3786]: debug1: PAM: setting PAM_TTY to "ssh"
Sep 6 14:13:01 localhost sshd[3787]: debug1: userauth-request for user abhyas_mgr service ssh-connection method publickey
Sep 6 14:13:01 localhost sshd[3787]: debug1: attempt 1 failures 0
Sep 6 14:13:01 localhost sshd[3787]: debug1: test whether pkalg/pkblob are acceptable
Sep 6 14:13:01 localhost sshd[3786]: debug1: temporarily_use_uid: 500/500 (e=0/0)
Sep 6 14:13:01 localhost sshd[3786]: debug1: trying public key file /home/abhyas_mgr/.ssh/authorized_keys
Sep 6 14:13:01 localhost sshd[3786]: debug1: fd 4 clearing O_NONBLOCK
Sep 6 14:13:01 localhost sshd[3786]: Authentication refused: bad ownership or modes for file /home/abhyas_mgr/.ssh/authorized_keys
Sep 6 14:13:01 localhost sshd[3786]: debug1: restore_uid: 0/0
Sep 6 14:13:01 localhost sshd[3786]: debug1: temporarily_use_uid: 500/500 (e=0/0)
Sep 6 14:13:01 localhost sshd[3786]: debug1: trying public key file /home/abhyas_mgr/.ssh/authorized_keys2
Sep 6 14:13:01 localhost sshd[3786]: debug1: Could not open authorized keys '/home/abhyas_mgr/.ssh/authorized_keys2': No such file or directory
Sep 6 14:13:01 localhost sshd[3786]: debug1: restore_uid: 0/0
Sep 6 14:13:01 localhost sshd[3786]: Failed publickey for abhyas_mgr from 192.168.102.131 port 54518 ssh2
^C
This is usually indicative of a permissions issue. Make sure that your permissions are set correctly on the following directories and files:
/home/username/ - permissons should be at least 700 or 750
/home/username/.ssh/ - permissions should be at least 500
/home/username/.ssh/authorized_keys - permissions should be at least 400
Permissions can be set using the chmod command. For example:
chmod 500 /home/username/.ssh
As Luis Colorado pointed out below there is also a maximum permission level that OpenSSH allows. If it's set too loosely (such as 777) you will not be able to log in. See the OpenSSH faq for more information.