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.
Related
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 2 years ago.
Improve this question
I've already looked for similar questions and tried changing several things in my configuration but couldn't come up with a solution.
I'm trying to connecting via SSH to a Docker container, here's the Dockerfile:
FROM ubuntu
RUN apt-get update && \
apt-get install -y openssh-server
RUN useradd remote_user && \
echo "remote_user:test1234" | chpasswd && \
mkdir /home/remote_user/.ssh -p && \
chmod 700 /home/remote_user/.ssh && \
mkdir -p -m0755 /var/run/sshd
COPY id_rsa.pub /home/remote_user/.ssh/authorized_keys
RUN chown remote_user:remote_user -R /home/remote_user && \
chmod 600 /home/remote_user/.ssh/authorized_keys
RUN apt-get install -y php php-mbstring php-xml php-bcmath php-fpm && \
apt-get install -y composer && apt-get install -y vim
RUN apt-get install -y nginx
CMD /usr/sbin/sshd -D
Once I try to connect to the container as "remote_user" with ssh -Tv remote_user#staging.local (where "staging.local" is the container IP) I get this message:
...
...
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,sk-ssh-ed25519#openssh.com,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,sk-ecdsa-sha2-nistp256#openssh.com>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering public key: /home/xxx/.ssh/id_rsa RSA SHA256:5QNPe89pdQp+tgE61N9YPaIJEs8QR9DxaChmStfvzBU agent
debug1: Authentications that can continue: publickey,password
debug1: Offering public key: xxx#xxx RSA SHA256:C+VWlGUd4mVywHnh8JWtjL0gmO8cuqUEs4YYCbQGvaE agent
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/xxx/.ssh/id_dsa
debug1: Trying private key: /home/xxx/.ssh/id_ecdsa
debug1: Trying private key: /home/xxx/.ssh/id_ecdsa_sk
debug1: Trying private key: /home/xxx/.ssh/id_ed25519
debug1: Trying private key: /home/xxx/.ssh/id_ed25519_sk
debug1: Trying private key: /home/xxx/.ssh/id_xmss
debug1: Next authentication method: password
remote_user#staging.local's password:
As you can see it can't connect and is asking for the password.
If I ls -ll .ssh folder files in my host machine I have this:
-rw------- 1 xxx xxx 2610 Jan 3 12:08 id_rsa
-rw-r--r-- 1 xxx xxx 577 Jan 3 12:08 id_rsa.pub
-rw-r--r-- 1 xxx xxx 222 Jan 3 12:25 known_hosts
If I docker exec into the container as root user and see permissions of /home/remote_user/.ssh I have:
home folder permissions:
drwxr-xr-x 1 root root 4096 Jan 3 11:22 home
remote_user folder permissions:
drwxr-xr-x 1 remote_user remote_user 4096 Jan 3 11:22 remote_user
.ssh folder permissions:
drwx------ 1 remote_user remote_user 4096 Jan 3 11:22 .ssh
authorized_keys file permissions:
-rw------- 1 remote_user remote_user 577 Jan 3 11:08 authorized_keys
Try changing the permissions for the /home/remote_user/.ssh/authorized_keys to 400 instead of 600. Other than that, I don't see any difference between my own setup.
p.s.
My setup runs with ubuntu 18.04 so maybe they changed something since then.
It should work if you forward the port :
docker run -p 222:22 your-image
then :
ssh -p 222 remote_user#localhost
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.
This starts driving me nuts!
I have the case here where a specific user when trying to login to a Linux server (running openSUSE 13.2 (Harlequin) (x86_64)) using a password or a private key is immediately logged out again.
The login seems successful (at least according to the ssh log - see below) but immediately after that the connection is closed and the intended command is not executed.
The below output captured using ssh's -vvv option:
ssh -vvv -i <path_to_private_key> <user>#<FQDN> touch /tmp/mms_was_here
...
debug1: Next authentication method: publickey
debug1: Offering public key: RSA SHA256:W4i/<removed> <path_to_private_key>
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 60
debug1: Server accepts key: pkalg ssh-rsa blen 279
debug2: input_userauth_pk_ok: fp SHA256:W4i/<removed-same-as-above>
debug3: sign_and_send_pubkey: RSA SHA256:W4i/<removed-same-as-above>
debug3: send packet: type 50
debug3: receive packet: type 52
debug1: Authentication succeeded (publickey).
Authenticated to <FQDN> ([10.10.8.88]:22).
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug3: send packet: type 90
debug1: Requesting no-more-sessions#openssh.com
debug3: send packet: type 80
debug1: Entering interactive session.
debug1: pledge: network
debug3: send packet: type 1
debug1: channel 0: free: client-session, nchannels 1
debug3: channel 0: status: The following connections are open:
#0 client-session (t3 nr0 i0/0 o0/0 fd 4/5 cc -1)
Connection to <FQDN> closed by remote host.
Transferred: sent 2564, received 2328 bytes, in 0.0 seconds
Bytes per second: sent 400692.9, received 363811.6
debug1: Exit status -1
Note: I replaced a few appearances of the server's name and some key hashes for privacy but they were correct.
What makes things even more absurd to me is that a different user can log in without problems (with both, password or key authentication)! I painstakingly compared settings, the content of the .ssh directory and what not. They are the same (modulo the different keys of course).
Both user have a valid home directory set as well as /bin/bash as default shell. Their public keys have been added to the respective ~/.ssh/authorized keys-files, the server's hosts.deny and host.allow files are empty (or rather contain only comments). sshd_config has neither an AllowUser/Group nor a DenyUser/Group section.
The password (for password authentication) is set and unlocked. But that user can not login!
After the login attempts of both "service sshd status" reports:
...
30:3d:c6:43:ee:3d:05:32:90:49:65:71:1a [MD5]
May 14 15:43:17 ksta-zhquest-int3 sshd[26223]: pam_unix(sshd:session): session opened for user <user> by (uid=0)
So - even that looks good. sshd has admitted the user. But then one user's command is executed while the other's session is immediately closed again and the command is NOT executed! And that happens for both, password as well as key authentication! Why is that user locked out? Any idea anyone?
I had a very similar issue, it turned out that the subnet that I had put the Debian VM on was not listed in Active Directory sites and services. Took me ages to find the answer and this question kept coming up in my searches, so I'm posting the answer here in case anyone is in the same boat in future.
Update: coming back to this answer because I've encountered other scenarios with similar or identical symptoms.
PasswordAuthentication=No was set in /etc/ssh/sshd_config. I was attempting authentication using a password.
The user had no homefolder. /var/log/auth.log showed the authentication succeeding but then the client side disconnected straight afterwards. I had forgotten to configure /etc/pam.d/common-session with session optional pam_mkhomedir.so
(Ansible) I had a conflicting variable set in the inventory file causing it to try and use ssh key authentication instead of password authentication. This was only visible with -vvv showing ansible using ssh -o PasswordAuthentication=no
Check if the user is not added to some nologin configuration, it also could have set its default shell to /bin/false or something alike
I had a look-alike problem once upgrading an openSUSE computer from a 15.3 release to Tumbleweed. It turned out that there was an old /etc/ssh/sshd_config configuration file left over in the file system which contained in the line for "Subsystem sftp" a binary file /usr/lib/ssh/sftp-server that does not exist. The problem was solved by removing (sic) that /etc/ssh/sshd_config file such that the file at the slightly different location /usr/etc/sshd_config took over, which contained an valid Subsystem sftp binary file in the /usr/libexec directory, then restarting the sshd .
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 3 years ago.
Improve this question
I'm trying to connect my server
and ssh show me: sh: 6000: command not found
blow is ssh verbose log and my sshd_config.
[~] # ssh -v admin#myserver -P 6000
OpenSSH_7.6p1, OpenSSL 1.0.2k 26 Jan 2017
debug1: Connecting to 192.168.50.21 [192.168.50.21] port 6000.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/id_rsa type 0
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ed25519-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_7.6
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.6
debug1: match: OpenSSH_7.6 pat OpenSSH* compat 0x04000000
debug1: Authenticating to 192.168.50.216000 as 'admin'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: rsa-sha2-512
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: ssh-rsa SHA256:XTuaKA/5nJd1wol9+Ckp0or8XCx3Rd/0NGMIdT9lrro
debug1: Host '192.168.50.21' is known and matches the RSA host key.
debug1: Found key in /root/.ssh/known_hosts:2
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 134217728 blocks
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-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering public key: RSA SHA256:XTuaKA/5nJd1wol9+Ckp0or8XCx3Rd/0NGMIdT9lrro /root/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Trying private key: /root/.ssh/id_dsa
debug1: Trying private key: /root/.ssh/id_ecdsa
debug1: Trying private key: /root/.ssh/id_ed25519
debug1: Next authentication method: keyboard-interactive
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: password
admin#192.168.50.21's password:
debug1: Authentication succeeded (password).
Authenticated to 192.168.50.21 ([192.168.50.21]6000).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions#openssh.com
debug1: Entering interactive session.
debug1: pledge: network
debug1: client_input_global_request: rtype hostkeys-00#openssh.com want_reply 0
debug1: Sending command: 6000
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: client_input_channel_req: channel 0 rtype eow#openssh.com reply 0
sh: 6000: command not found
debug1: channel 0: free: client-session, nchannels 1
Transferred: sent 2248, received 3052 bytes, in 0.2 seconds
Bytes per second: sent 14674.8, received 19923.2
debug1: Exit status 127
this is my sshd config
# $OpenBSD: sshd_config,v 1.74 2006/07/19 13:07:10 dtucker Exp $
# This is the sshd server system-wide configuration file. See
# sshd_config(5) for more information.
# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/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 change a
# default value.
#Port 22
#Protocol 2,1
Protocol 2
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::
# HostKey for protocol version 1
#HostKey /etc/ssh/ssh_host_key
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
# Lifetime and size of ephemeral version 1 server key
#KeyRegenerationInterval 1h
#ServerKeyBits 768
# Logging
# obsoletes QuietMode and FascistLogging
#SyslogFacility AUTH
#LogLevel INFO
# Authentication:
#LoginGraceTime 2m
PermitRootLogin yes
#StrictModes yes
#MaxAuthTries 6
#RSAAuthentication yes
#PubkeyAuthentication yes
#AuthorizedKeysFile .ssh/authorized_keys
# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#RhostsRSAAuthentication no
# similar for protocol version 2
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# RhostsRSAAuthentication and 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
#AllowTcpForwarding yes
#GatewayPorts no
#X11Forwarding no
#X11DisplayOffset 10
#X11UseLocalhost yes
#PrintMotd yes
#PrintLastLog yes
#TCPKeepAlive yes
#UseLogin no
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
UseDNS no
#PidFile /var/run/sshd.pid
#MaxStartups 10
#PermitTunnel no
# no default banner path
#Banner /some/path
# override default of no subsystems
Subsystem sftp /usr/libexec/sftp-server
AllowUsers admin
# Example of overriding settings on a per-user basis
#Match User anoncvs
# X11Forwarding no
# AllowTcpForwarding no
# ForceCommand cvs server
I don't know why this error show here.
And I use a mac software called ssh shell it can connect to my server.
I'm pretty sure the password is right.
Your commandline doesn't do what you think it does.
ssh -v admin#myserver -P 6000
-v enables some debug information
admin#myserver provides the remote user and remote host
-P 6000 does NOT attempt to connect to port 6000
The command you probably intended was:
ssh -v admin#myserver -p 6000
However, it turns out that -P is an undocumented argument that is accepted by ssh.
This leaves an unaccounted for argument 6000. ssh assumes this is a command that you want to run on the remote server. It doesn't exist, which results in the error shown:
sh: 6000: command not found
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.