Hello, I'm losing my sanity! I cannot get this to work and it seems so simple! I am running CentOS 5.4 and trying to SSH to localhost with the user called hadoop. I do the following logged in as "hadoop":

# ssh-keygen -t rsa -f ~/.ssh/id_rsa (doesn't matter if I create a passphrase or not)
# cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
# ssh localhost
hadoop@localhost's password: (It should not prompt right?)

Here is the contents of the .ssh directory:

# ls -la
total 48
drwx------ 2 hadoop hadoop 4096 Oct 8 21:38 .
drwx------ 6 hadoop hadoop 4096 Oct 8 21:32 ..
-rw-rw-r-- 1 hadoop hadoop 392 Oct 8 21:34 authorized_keys
-rw------- 1 hadoop hadoop 1675 Oct 8 21:32 id_rsa
-rw-r--r-- 1 hadoop hadoop 392 Oct 8 21:32 id_rsa.pub
-rw-r--r-- 1 hadoop hadoop 776 Oct 8 21:41 known_hosts

Here is the output of "# ssh -v localhost"

# ssh -v localhost
OpenSSH_4.3p2, OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to localhost [127.0.0.1] port 22.
debug1: Connection established.
debug1: identity file /home/hadoop/.ssh/identity type -1
debug1: identity file /home/hadoop/.ssh/id_rsa type 1
debug1: identity file /home/hadoop/.ssh/id_dsa type -1
debug1: loaded 3 keys
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3
debug1: match: OpenSSH_4.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.3
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'localhost' is known and matches the RSA host key.
debug1: Found key in /home/hadoop/.ssh/known_hosts:1
debug1: ssh_rsa_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,gssapi-with-mic,password
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure. Minor code may provide more information
Unknown code krb5 195

debug1: Unspecified GSS failure. Minor code may provide more information
Unknown code krb5 195

debug1: Unspecified GSS failure. Minor code may provide more information
Unknown code krb5 195

debug1: Next authentication method: publickey
debug1: Trying private key: /home/hadoop/.ssh/identity
debug1: Offering public key: /home/hadoop/.ssh/id_rsa
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Trying private key: /home/hadoop/.ssh/id_dsa
debug1: Next authentication method: password
hadoop@localhost's password:

Please help!

Try '.ssh/authorized_keys2' ... there's also a utility in openssh-clients now called 'ssh-copy-id' which will propagate the keys for you.

cheers

authorized_keys2 has been deprecated for quite some time now...

In sshd_config do you have the following?:

Here is my sshd_config:

# $OpenBSD: sshd_config,v 1.73 2005/12/06 22:38:28 reyk Exp $

# This is the sshd server system-wide configuration file. See
# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/local/bin:/bin:/usr/bin

# 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
SyslogFacility AUTHPRIV
#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
PasswordAuthentication yes

# Change to no to disable s/key passwords
#ChallengeResponseAuthentication yes
ChallengeResponseAuthentication no

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

# GSSAPI options
#GSSAPIAuthentication no
GSSAPIAuthentication yes
#GSSAPICleanupCredentials yes
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 mechanism.
# Depending on your PAM configuration, this may bypass the setting of
# PasswordAuthentication, PermitEmptyPasswords, and
# "PermitRootLogin without-password". If you just want the PAM account and
# session checks to run without PAM authentication, then enable this but set
# ChallengeResponseAuthentication=no
#UsePAM no
UsePAM yes

# Accept locale-related environment variables
AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
AcceptEnv LC_IDENTIFICATION LC_ALL
#AllowTcpForwarding yes
#GatewayPorts no
#X11Forwarding no
X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes
#PrintMotd yes
#PrintLastLog yes
#TCPKeepAlive yes
#UseLogin no
#UsePrivilegeSeparation yes
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#ShowPatchLevel no
#UseDNS yes
#PidFile /var/run/sshd.pid
#MaxStartups 10
#PermitTunnel no
#ChrootDirectory none

# no default banner path
#Banner /some/path

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

Ok, try disabling PasswordAuthentication by setting it to "no", and enabling HostbasedAuthentication by uncommenting it and setting it to "yes". Judging from your ssh -v output host based authentication should work, and disabling password authentication will ensure that it doesn't try that method first.

Check permissions on all files in ~/.ssh.
They should be 600, not 644.

that said, the very topic of your post suggests that you're asking the
wrong question. You asked "how to ssh to localhost" - I can't imagine
any scenario where that would be useful, or at least where it would be
the right way to do anything. What are you actually trying to do?

SSHing to localhost can be useful at times, but I think raymor is right about permissions. This one in particular might be your problem.

1 members found this post helpful.

Wow I must have been really sleepy last night and not thinking straight -
sitting here GUESSING as to what the problem might be. I learned better
than that a decade ago. USE THE LOGS.

In one terminal, su or sudo an run:
tail -f /var/log/secure

Then in another terminal try the SSH and watch for the new message(s)
in the log. This is the message I GUESSED you would get:

Apr 15 08:25:27 raydesk1 sshd[3226]: Authentication refused: bad ownership or modes for file /home/raymorris/.ssh/authorized_keys

It tells you straight out the problem is "bad ownership or modes for
file home/raymorris/.ssh/authorized_keys". If the problem is something
else, it'll probably tell you what the problem is.

I was really silly to sit there and throw out a likely cause rather
than telling you to check the log. I think that's the important thing
to learn from this, not about SSH, but about troubleshooting in general.

Can you give an example or two? In fifteen years, being involved with the
administration of hundreds of Linux boxen, I've never seen anyone do or
recommend that. I'm always up to learn a new trick, though. I can see
typing a command AS IF you were connecting to localhost, but it's really
port forwarded, but even that wouldn't apply to SSH - that would be POP3,
IMAP, or most likely VNC. The port would be forwarded over SSH to start with.
I can also see TESTING your SSH by connecting to localhost, but then you
wouldn't post about "how to ssh to localhost", you'd be dealing with a SSH
problem in general. That is, the real aim would be to SSH to and from different
machines, with a localhost connection as just one quick debugging step.
Anyway, I'd love to see an example. I'm thinking there probably isn't one,
but I love to be proven wrong because that means I learn something.
Note too the OPs command is just "ssh localhost" - nothing fancy, so it
has exactly the same result as running "bash".

In addition to the permissions on authorized_keys, you don't
indicate if you added your key to your ssh-agent.

It's possible that your ssh-agent is holding your old key
in memory, and offering it.

ssh-add -l <-- list keys held by ssh-agent
ssh-add ~/.ssh/id_dsa <-- add new key

Leo

Permissions were the problem!
# chmod 600 ~/.ssh/authorized_keys (as hadoop user) fixed it. I don't really understand why that was a problem because that file was create by the hadoop user, but oh well.

Just FYI, the reason for "SSH localhost" is I am attempting to set up a Hadoop cluster, and SSH to localhost on the "master" is a pre-requisite before attempting SSH from master to slave nodes. I was getting the same error when attempting "SSH slave01", but the chmod fix it!

Sorry if the post was confusing, I'm learning as I go and probably don't use the correct terminology sometimes.

The reason the file needs slightly different permissions to prevent anyone except the file owner, reading or writing to that file. Hence 600 rather than 644. If this is not the case ssh will ignore the file, as its considered unsafe.

Just came across this via google and thought I'd add a couple notes:

1) PredictionIO installation docs ( http://docs.prediction.io/current/in...-on-linux.html ) say : "Please check that you can ssh to localhost without a passphrase:"

Please don't tell people they shouldn't want to do what they want to do. If the request is for something that's actually dangerous, warn of the danger. But otherwise it's more polite to assume they have a legitimate reason to want to do that.

2) I got frustrated with perms and got it right after a few hits & misses. Here's the magic bullet (for me)
#this fails: the directory .ssh needs to be +x , but the files inside it need to not be
chmod -R 600 ~/.ssh

#this works (for me)
chmod 644 ~/.ssh
chmod 600 ~/.ssh/*

This, of course was after cat ~/.ssh/id_dsa.pub >> ~/.ssh/authorized_keys and all that stuff

Will take care of all perm issues.

It's pretty common in clustered applications to be able to send commands to all boxes in the
cluster, including localhost. You don't want to have to write a different method for accessing
the local box than the other boxes in the cluster, and lo is a very fast interface.

One system I worked on recently was a load-balanced web server. Administration ran on one node
and sent commands to all, including itself, via ssh.