CentOS - Jan 2011 - SSH Automatic Log-on Failure - Centos 5.5

Hallo,

I wanted to avoid typing-in my password every occasion I remotely
logged-on to a server.

I created my SSH keys and copied the public part to the server and
renamed it authorized_keys.

My command line is: ssh root at xxxxxx.com -p 1234

The output shows the logging-on routine wants 3 types of authentication.
Surely one successful authentication is sufficient ? 


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 xxxxxx [123.123.123.123] port 1234.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/identity type -1
debug1: identity file /root/.ssh/id_rsa type 1
debug1: identity file /root/.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 'xxxxxx' is known and matches the RSA host key.
debug1: Found key in /root/.ssh/known_hosts:4
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: /root/.ssh/identity
debug1: Offering public key: /root/.ssh/id_rsa
debug1: Authentications that can continue:
publickey,gssapi-with-mic,password
debug1: Trying private key: /root/.ssh/id_dsa
debug1: Next authentication method: password

-------------------

files in client /root/.ssh are:-

-rw-------  1 root root 1675 Jan 27 03:11 id_rsa
-rw-r--r--  1 root root  403 Jan 27 03:11 id_rsa.pub
-rw-r--r--  1 root root 2022 Jan 27 03:07 known_hosts

---------------------------------------------

server /root/.ssh

id_rsa.authorized_keys  -rw--------

--------------------------------------------

The only active lines in /etc/ssh/ssh_config are

Host *
GSSAPIAuthentication yes

SendEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY
LC_MESSAGES 
SendEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT 
SendEnv LC_IDENTIFICATION LC_ALL

--------------------------------------------

After commenting-out

GSSAPIAuthentication yes

in /etc/ssh/ssh_config

the remainder of a new debug report is:-

...
debug1: Authentications that can continue:
publickey,gssapi-with-mic,password
debug1: Next authentication method: publickey
debug1: Trying private key: /root/.ssh/identity
debug1: Offering public key: /root/.ssh/id_rsa
debug1: Authentications that can continue:
publickey,gssapi-with-mic,password
debug1: Trying private key: /root/.ssh/id_dsa
debug1: Next authentication method: password





All advice most gratefully received.

-- 

With best regards,

Paul.
England,
EU.

On Thu, Jan 27, 2011 at 12:15 PM, Always Learning <centos at g7.u22.net>
wrote:
> Hallo,
>
> I wanted to avoid typing-in my password every occasion I remotely
> logged-on to a server.
>


you expect Passwordless SSH. If so,


On your PC

# ssh-keygen -t rsa       ( passphrase should be empty )

Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:

then,

# cd /root/.ssh/

Pls scp id_rsa.pub to the Server

# scp id_rsa.pub root at server:/root/.ssh/authorized_keys
 <root at 192.1.54.63>

then, finally ssh to the server from your PC. it would be passwordless.
pls see below

# ssh server



Pls try


>
>
-- 
Thank you
Indunil Jayasooriya
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.centos.org/pipermail/centos/attachments/20110127/c1252d01/attachment-0002.html>

On 27/01/2011, at 7:45 PM, Always Learning wrote:
> Hallo,
> 
> I wanted to avoid typing-in my password every occasion I remotely
> logged-on to a server.
> 
> I created my SSH keys and copied the public part to the server and
> renamed it authorized_keys.
> ---------------------------------------------
> 
> server /root/.ssh
> 
> id_rsa.authorized_keys  -rw--------
> 
> --------------------------------------------
Your ~/.ssh/authorized_keys needs to be readable by sshd, your permissions on it
are too restrictive (typically, this should be 0644)

Also, it should be named authorized_keys, not id_rsa.authorized_keys

PS. Coming from a background in other distributions, I find it disturbing that
Centos ships with allow_root_login defaulting to yes. If you really need this,
ensure that you also restrict access from where people can log in, consider
employing dynamic banning, and harden your sshd_config (which, oddly enough, you
didn't post).

PPS. When diagnosing such faults, it can be useful to run the sshd (ie. the
server process) in debugging mode, although this would generally require the
server to be temporarily disabled so it can be started in debugging mode.

On Thu, Jan 27, 2011 at 2:03 AM, Indunil Jayasooriya
<indunil75 at gmail.com> wrote:
>
>
> On Thu, Jan 27, 2011 at 12:15 PM, Always Learning <centos at
g7.u22.net> wrote:
>>
>> Hallo,
>>
>> I wanted to avoid typing-in my password every occasion I remotely
>> logged-on to a server.
>
>
>
> you expect Passwordless SSH. If so,
>
>
> On your PC
>
> # ssh-keygen -t rsa?????? ( passphrase should be empty )
NO!!! NO!!! NO!!! NO!!!

I'm sorry, but this is a far too comon and very, very bad practice.
You may as well tape a Post-It note with your password on it under
your keyboard, because anyone who can get this un-passphrase protected
key will be able to automatically log in as you.
The normal approach is to investigate how to use ssh-agent to store
your unlocked key in an active session, not use a passphrase-less key.
The "keychain" utiliti is very handy for just this purpose, and
it's
available in the RPMforge repositories for RHEL 5 and CentOS 5.

Far too many people say "but you have to trust your own machine!!!"
and leave these passphrase-less keys lying around, and they're a
popular vulnerability for crackers to steal if they can gain *any*
access to your systems. It's particularly bad in environments that use
NFS and allow local hosts to be run by local users: any such local
admin can then "su" to become other users and access their private
keys.

Also, there's a stack of reasons that DSA is preferred to RSA for SSH
keys these days. When you generate your private keys, use "ssh-keygen
-t dsa", not rsa.
> Generating public/private rsa key pair.
> Enter file in which to save the key (/root/.ssh/id_rsa):
> Enter passphrase (empty for no passphrase):
> Enter same passphrase again:
>
> then,
>
> # cd /root/.ssh/
>
> Pls scp id_rsa.pub to the Server
>
> # scp id_rsa.pub root at server:/root/.ssh/authorized_keys
Wrong again. Never use public key access for root accounts, it simply
compounds the security risks. Passphrase protected SSH keys can be
used, reasonably, for account access on other hosts, but should be
avoided for root access. If you *HAVE* to use an SSH key for root, for
example for "rsync" based backup operations, use rssh to restrict its
operations or designate a permitted command associated with that key
in the target's authorized_keys.
>
> then, finally ssh to the server from your PC. it would be passwordless.
> pls see below
Sadly, this will *work*, but so does tying your car keys to your car
door so you don't lose them. It's a security issue.

Please, read the manual pages on "ssh-agent" which was designed and
built into SSH deployments for just such use.

Hello all,

I've been reading this thread and have a question. I would like to set up
passwordless ssh between two servers for some automated tasks but I don't
like the paswordless key's option. How can I supply a passphrase when
generating my keys but still have this process automated?

--James. (This email was sent from a mobile device)
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.centos.org/pipermail/centos/attachments/20110127/a10b324b/attachment-0002.html>

On Thu, Jan 27, 2011 at 12:33:31PM +0530, Indunil Jayasooriya
wrote:
> # ssh-keygen -t rsa       ( passphrase should be empty )
Don't use passphraseless keys unless you're using it for an automated
tool (eg rsync kicked off from cron).  If this is for human interactive
work then learn how to use ssh-agent.

(If it's for programmatic use then also learn the from= and command= options
on the public key to restrict what the key can do)

-- 

rgds
Stephen

On Thu, 2011-01-27 at 12:33 +0530, Indunil Jayasooriya wrote:

> you expect Passwordless SSH. If so, 
I wanted a quick effortless automated log-on.
> # ssh-keygen -t rsa       ( passphrase should be empty )
Yes I did exactly that but following advice from this mailing list have
changed to DSA and imposed a passphrase.
> # cd /root/.ssh/
> 
> Pls scp id_rsa.pub to the Server
> 
> # scp id_rsa.pub root at server:/root/.ssh/authorized_keys
I used Nautilus to transfer the files. Copied the file from my machine
and pasted it into the server's directory. I have the servers as
bookmarks in Nautilus.  After entering the password for my machine's
keyring, only once per session, entering the remote server is instant
and easy. However terminal access is still needed sometimes for
re-starting services, iptables and changing ownership - hence my need
for SSH command line access to the servers.

-- 

With best regards,

Paul.
England,
EU.