[SOLVED] SSH issue when logging as Root with key

JayMatthew · 05-10-2017, 04:09 PM

Hi,

I am unable to ssh as root to a slack14.0 machine using a public key. The root user continues to prompt me for a password. I have no issue when logging in as a normal user. I am attaching my ssh_config and sshd_config. They seem to look the same as other machines where I have no problem.

Thanks in advance for any advice.

Jay

ssh_config:
# Host *
# ForwardAgent no
ForwardX11 yes
# RhostsRSAAuthentication no
# RSAAuthentication yes
# PasswordAuthentication yes
# HostbasedAuthentication no
# GSSAPIAuthentication no
# GSSAPIDelegateCredentials no
# BatchMode no
# CheckHostIP yes
# AddressFamily any
# ConnectTimeout 0
# StrictHostKeyChecking ask
# IdentityFile ~/.ssh/identity
# IdentityFile ~/.ssh/id_rsa
# IdentityFile ~/.ssh/id_dsa
# IdentityFile ~/.ssh/id_ecdsa
# IdentityFile ~/.ssh/id_ed25519
# Port 22
# Protocol 2
# Cipher 3des
# Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc
# MACs hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160
# EscapeChar ~
# Tunnel no
# TunnelDevice any:any
# PermitLocalCommand no
# VisualHostKey no
# ProxyCommand ssh -q -W %h:%p gateway.example.com
# RekeyLimit 1G 1h

sshd_config:
#Port 22
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::

#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_dsa_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 prohibit-password
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
#AllowTcpForwarding yes
#GatewayPorts no
X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes
#PermitTTY yes
#PrintMotd yes
#PrintLastLog yes
#TCPKeepAlive yes
#UseLogin no
#UsePrivilegeSeparation sandbox
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS no
#PidFile /var/run/sshd.pid
#MaxStartups 10:30:100#Banner none

# override default of no subsystems
Subsystem sftp /usr/libexec/sftp-server

# Example of overriding settings on a per-user basis
#Match User anoncvs
# X11Forwarding no
# AllowTcpForwarding no
# PermitTTY no
# ForceCommand cvs server
#PermitTunnel no
#ChrootDirectory none
#VersionAddendum none

# no default banner path

.ssh directory info:
drwx------ 2 root root 4096 May 4 18:43 .ssh

-rw------- 1 root root 796 Apr 27 16:27 authorized_keys
-rw------- 1 root root 1679 Apr 27 15:49 id_rsa
-rw------- 1 root root 399 Apr 27 15:49 id_rsa.pub
-rw-r--r-- 1 root root 771 May 8 18:09 known_hosts

When I run ssh -v:
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Connecting to server6 [ip address] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/id_rsa type 1
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: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.4
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.4
debug1: match: OpenSSH_7.4 pat OpenSSH* compat 0x04000000
debug1: Authenticating to server6:22 as 'root'
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:Z+dpuAdRlJvoMhfJPSx78JxFnGT//uVfkhVCEqORLjg
debug1: Host 'server6' is known and matches the ECDSA host key.
debug1: Found key in /root/.ssh/known_hosts:4
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,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 RSA public key: /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

spongetron · 05-11-2017, 07:18 AM

Did you copy the public key (id_rsa.pub) to the remote machine you want to login to?

JayMatthew · 05-11-2017, 08:00 AM

Quote:

Originally Posted by spongetron

Did you copy the public key (id_rsa.pub) to the remote machine you want to login to?

Yes. I used ssh-copy-id. I then removed the authorized_keys and copied it again, but still no joy.

zrdc28 · 05-11-2017, 08:25 AM

Is this what you need to change #PermitRootLogin prohibit-password to
PermitRootLogin yes

JayMatthew · 05-11-2017, 08:29 AM

Quote:

Originally Posted by zrdc28

Is this what you need to change #PermitRootLogin prohibit-password to
PermitRootLogin yes

I do have that set in the sshd_config. I'm wondering if it has anything to do with the Cipher?

spongetron · 05-11-2017, 08:39 AM

My first thought is that there are some kind of permission problems. At the moment I have no machine to check the proper permissions. You could rename/delete the .ssh direcotry on the server and use ssh-copy-id again to copy the public key to the authorized_key file. I think it automatically generates the .ssh direcotry again.

You could alos check what the ssh daemon logs (I think it logs to /var/log/secure) when you try to connect to it.

kjhambrick · 05-12-2017, 07:09 AM

JayMatthew --

Maybe this:

Code:

-rw------- 1 root root 399 Apr 27 15:49 id_rsa.pub

I believe the permissions on /root/.ssh/id_*.pub need to be like this:

Code:

-rw-r--r-- 1 root root 399 Apr 27 15:49 id_rsa.pub

HTH.

-- kjh

Turbocapitalist · 05-12-2017, 11:46 AM

Quote:

Originally Posted by JayMatthew

.ssh directory info:
drwx------ 2 root root 4096 May 4 18:43 .ssh

-rw------- 1 root root 796 Apr 27 16:27 authorized_keys
-rw------- 1 root root 1679 Apr 27 15:49 id_rsa
-rw------- 1 root root 399 Apr 27 15:49 id_rsa.pub
-rw-r--r-- 1 root root 771 May 8 18:09 known_hosts

Which machine is that on? Those should be the settings over at server6, minus the private key of course.

Turbocapitalist · 05-12-2017, 11:56 AM

Quote:

Originally Posted by kjhambrick

I believe the permissions on /root/.ssh/id_*.pub need to be like this:

Actually, the public key is quite flexible about permissions. From the manual page for the client:

"~/.ssh/identity.pub
~/.ssh/id_dsa.pub
~/.ssh/id_ecdsa.pub
~/.ssh/id_ed25519.pub
~/.ssh/id_rsa.pub
Contains the public key for authentication. These files are not sensitive and can (but need not) be readable by anyone."

However, that file is not needed anywhere. The private key, whatever its actual name, is needed on the client machine and authorized_keys is needed over on the server.

JayMatthew · 05-12-2017, 12:24 PM

Quote:

Originally Posted by kjhambrick

JayMatthew --

Maybe this:

Code:

-rw------- 1 root root 399 Apr 27 15:49 id_rsa.pub

I believe the permissions on /root/.ssh/id_*.pub need to be like this:

Code:

-rw-r--r-- 1 root root 399 Apr 27 15:49 id_rsa.pub

-

HTH.

-- kjh

Both machines have the same permissions for id_rsa.pub: -rw-r--r--

JayMatthew · 05-12-2017, 12:25 PM

Quote:

Originally Posted by Turbocapitalist

Actually, the public key is quite flexible about permissions. From the manual page for the client:

"~/.ssh/identity.pub
~/.ssh/id_dsa.pub
~/.ssh/id_ecdsa.pub
~/.ssh/id_ed25519.pub
~/.ssh/id_rsa.pub
Contains the public key for authentication. These files are not sensitive and can (but need not) be readable by anyone."

However, that file is not needed anywhere. The private key, whatever its actual name, is needed on the client machine and authorized_keys is needed over on the server.

Yes, I copied the private key into the server's authorized_keys.

JayMatthew · 05-12-2017, 12:27 PM

Quote:

Originally Posted by Turbocapitalist

Which machine is that on? Those should be the settings over at server6, minus the private key of course.

Those were the settings on server6. I did change the id_rsa.pub to kjhambrick's recommendation. Still no joy.

astrogeek · 05-12-2017, 12:30 PM

Quote:

Originally Posted by JayMatthew

Yes, I copied the private key into the server's authorized_keys.

That is not correct. You must copy the public key into authorized_keys n the remote machine.

The private key must be 600 perms (local machine) and the public key may be 644. On the remote (server) authorized keys must be 600.

So, on local machine:

Code:

-rw------- 1 user user  1766 Jan 30  2015 id_rsa
-rw-r--r-- 1 user user   396 Jan 30  2015 id_rsa.pub

And on the remote machine:

Code:

-rw------- 1 user user  791 Jan 30  2015 authorized_keys

JayMatthew · 05-12-2017, 12:32 PM

Here are some errors I'm getting in /var/log/messages:

sshd[23059]: Authentication refused: bad ownership or modes for directory /root

Turbocapitalist · 05-12-2017, 12:32 PM

Quote:

Originally Posted by JayMatthew

Yes, I copied the private key into the server's authorized_keys.

There's the problem. The public key must go into the server's authorized_keys file. The private key stays on the client.