3

I got

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/Users/Cody/.ssh/blue_gum.pub' are too open.

I did

chmod 600 ~/.ssh/blue_gum.pub

and now I get the popup (using mac os x mavericks) to enter the password for the SSH key, I don't have one so I left blank and then I get

Permission denied (publickey).

The keys were copied to the authroized_keys file on the server using

scp ~/.ssh/blue_gum.pub cody@10.0.0.10:~/.ssh/authorized_keys

I have also tried chmod 600 before scp to the server and the same occurs.

I made sure that .ssh on client and server had 700 permissions and that all files inside had 600. Still same problem. I am going to try the troubleshooting method described below. Also here is my sshd_config if this helps at all:

# Package generated configuration file
# See the sshd_config(5) manpage for details

# What ports, IPs and protocols we listen for
Port 22
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes

# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 768

# Logging
SyslogFacility AUTH
LogLevel INFO

# Authentication:
LoginGraceTime 120
PermitRootLogin no
StrictModes yes

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile  %h/.ssh/authorized_keys

# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
IgnoreUserKnownHosts yes

# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no

# Change to no to disable tunnelled clear text passwords
PasswordAuthentication yes

# Kerberos options
#KerberosAuthentication no
#KerberosGetAFSToken no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
#UseLogin no

#MaxStartups 10:30:60
#Banner /etc/issue.net

# Allow client to pass locale environment variables
AcceptEnv LANG LC_*

Subsystem sftp /usr/lib/openssh/sftp-server

# 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 yes
IgnoreUserKnownHosts no
PasswordAuthentication no
  • 1
    use 0600 instead of 600 if you want to give read write permission to root only. 600 is decimal number and 0600 is octal number both permission are different. – Amit Chauhan Dec 24 '13 at 9:22
  • arent the permissions for the keys suppose to be 600 though? it gives me the proper -rw------- – cbalos Dec 24 '13 at 17:56
2

This is by far OpenSSH's stickiest point. It mixes with the fact that error messages are necessarily cryptic, which makes debugging more akin to voodoo than normal IT practice. At any rate:

  1. make sure that all files inside .ssh, on both server and client have permissions 600.

  2. make sure that the directories .ssh have permissions 700, again on both server and client.

If the problem persists, kill openssh on the server, and restart it with the command (to be issued as sudo)

   killall sshd && /usr/sbin/sshd -Dd

which enables debugging output on the server, then try to connect from the client with the command

  ssh me@my_remote_machine -vvv

which enables verbose output. Hopefully, a combination of these two outputs should allow to troubleshoot your problem.

  • kill openssh on the server, and restart it with the command.... Careful!. Make sure you keep access to the server while doing this. (No coffee breaks and a 'I'll relogin in 30 minutes and finish it'). – Hennes Dec 24 '13 at 12:26
  • @Hennes Yes, thank you, you are right, I changed my command to allow for this. – MariusMatutiae Dec 24 '13 at 15:05
  • Im going to try the debugging, I made sure the permissions were all good and still same issue – cbalos Dec 24 '13 at 17:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.