FAQ
hey listers!

silly quesion: if I generate an RSA key on an NFS shared home
directory, then cat >> it into the .ssh/authorized_keys file in the
same location, shouldn't I then be able to ssh into each host that
shares the NFS home directory without entering a passphrase (assuming
the key doesn't have one)? and assuming the permissions on the
authorized_keys file belong to the user with mode 600?

thanks!
tim

--
Here's my RSA Public key:
gpg --keyserver pgp.mit.edu --recv-keys 5A4873A9

Share and enjoy!!

Search Discussions

  • Gordon Messmer at Oct 22, 2010 at 3:14 pm

    On 10/22/2010 11:38 AM, Tim Dunphy wrote:
    silly quesion: if I generate an RSA key on an NFS shared home
    directory, then cat>> it into the .ssh/authorized_keys file in the
    same location, shouldn't I then be able to ssh into each host that
    shares the NFS home directory without entering a passphrase (assuming
    the key doesn't have one)? and assuming the permissions on the
    authorized_keys file belong to the user with mode 600?
    The permissions on the .ssh directory must also be correct. Otherwise, yes.
  • Tim Dunphy at Oct 22, 2010 at 3:30 pm
    hmm.. ok then gordon thanks for the input! how do these permissions grab ya?


    [bluethundr at LCENT01 ~]$ ls -alh | grep .ssh
    -rw------- 1 bluethundr summitnjops 70 Oct 17 14:04 .lesshst
    drwx------ 2 bluethundr summitnjops 512 Oct 22 14:06 .ssh


    [bluethundr at LCENT01 ~]$ ls -lah .ssh
    total 34K
    drwx------ 2 bluethundr summitnjops 512 Oct 22 14:06 .
    drwx------ 106 bluethundr summitnjops 5.5K Oct 22 14:44 ..
    -rw------- 1 bluethundr summitnjops 820 Oct 22 14:19 authorized_keys
    -rw------- 1 bluethundr summitnjops 1.7K Oct 22 14:18 id_rsa
    -rw-r--r-- 1 bluethundr summitnjops 403 Oct 22 14:18 id_rsa.pub
    -rw-r--r-- 1 bluethundr summitnjops 20K Oct 22 14:47 known_hosts
    [bluethundr at LCENT01 ~]$


    as is stands, currently, still not working!

    this is what it looks like when I ssh to another host that shares this
    home directory (and .ssh dir) as the one I am ssh'ing from.

    [bluethundr at LCENT01 ~]$ ssh virt1
    bluethundr at virt1's password:

    I've posted a -vvv version of the ssh session in an attachment.

    thanks!

    tim
    On Fri, Oct 22, 2010 at 3:14 PM, Gordon Messmer wrote:
    On 10/22/2010 11:38 AM, Tim Dunphy wrote:
    silly quesion: if I generate an RSA key on an NFS shared home
    directory, then cat>> ?it into the .ssh/authorized_keys file in the
    same location, shouldn't I then be able to ssh into each host that
    shares the NFS home directory without entering a passphrase (assuming
    the key doesn't have one)? and assuming the permissions on the
    authorized_keys file belong to the user with mode 600?
    The permissions on the .ssh directory must also be correct. ?Otherwise, yes.
    _______________________________________________
    CentOS mailing list
    CentOS at centos.org
    http://lists.centos.org/mailman/listinfo/centos


    --
    Here's my RSA Public key:
    gpg --keyserver pgp.mit.edu --recv-keys 5A4873A9

    Share and enjoy!!
    -------------- next part --------------
    [bluethundr at LCENT01 ~]$ ssh virt1
    bluethundr at virt1's password:

    [bluethundr at LCENT01 ~]$ ssh -vvv virt1
    OpenSSH_4.3p2, OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008
    debug1: Reading configuration data /etc/ssh/ssh_config
    debug1: Applying options for *
    debug2: ssh_connect: needpriv 0
    debug1: Connecting to virt1 [192.168.1.23] port 22.
    debug1: Connection established.
    debug1: identity file /home/bluethundr/.ssh/identity type -1
    debug3: Not a RSA1 key file /home/bluethundr/.ssh/id_rsa.
    debug2: key_type_from_name: unknown key type '-----BEGIN'
    debug3: key_read: missing keytype
    debug3: key_read: missing whitespace
    debug3: key_read: missing whitespace
    debug3: key_read: missing whitespace
    debug3: key_read: missing whitespace
    debug3: key_read: missing whitespace
    debug3: key_read: missing whitespace
    debug3: key_read: missing whitespace
    debug3: key_read: missing whitespace
    debug3: key_read: missing whitespace
    debug3: key_read: missing whitespace
    debug3: key_read: missing whitespace
    debug3: key_read: missing whitespace
    debug3: key_read: missing whitespace
    debug3: key_read: missing whitespace
    debug3: key_read: missing whitespace
    debug3: key_read: missing whitespace
    debug3: key_read: missing whitespace
    debug3: key_read: missing whitespace
    debug3: key_read: missing whitespace
    debug3: key_read: missing whitespace
    debug3: key_read: missing whitespace
    debug3: key_read: missing whitespace
    debug3: key_read: missing whitespace
    debug3: key_read: missing whitespace
    debug3: key_read: missing whitespace
    debug2: key_type_from_name: unknown key type '-----END'
    debug3: key_read: missing keytype
    debug1: identity file /home/bluethundr/.ssh/id_rsa type 1
    debug1: identity file /home/bluethundr/.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
    debug2: fd 4 setting O_NONBLOCK
    debug1: SSH2_MSG_KEXINIT sent
    debug1: SSH2_MSG_KEXINIT received
    debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
    debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
    debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
    debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
    debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96
    debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96
    debug2: kex_parse_kexinit: none,zlib at openssh.com,zlib
    debug2: kex_parse_kexinit: none,zlib at openssh.com,zlib
    debug2: kex_parse_kexinit:
    debug2: kex_parse_kexinit:
    debug2: kex_parse_kexinit: first_kex_follows 0
    debug2: kex_parse_kexinit: reserved 0
    debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
    debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
    debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
    debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
    debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96
    debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96
    debug2: kex_parse_kexinit: none,zlib at openssh.com
    debug2: kex_parse_kexinit: none,zlib at openssh.com
    debug2: kex_parse_kexinit:
    debug2: kex_parse_kexinit:
    debug2: kex_parse_kexinit: first_kex_follows 0
    debug2: kex_parse_kexinit: reserved 0
    debug2: mac_init: found hmac-md5
    debug1: kex: server->client aes128-cbc hmac-md5 none
    debug2: mac_init: found hmac-md5
    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
    debug2: dh_gen_key: priv key bits set: 113/256
    debug2: bits set: 538/1024
    debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
    debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
    debug3: check_host_in_hostfile: filename /home/bluethundr/.ssh/known_hosts
    debug3: check_host_in_hostfile: match line 3
    debug3: check_host_in_hostfile: filename /home/bluethundr/.ssh/known_hosts
    debug3: check_host_in_hostfile: match line 3
    debug1: Host 'virt1' is known and matches the RSA host key.
    debug1: Found key in /home/bluethundr/.ssh/known_hosts:3
    debug2: bits set: 516/1024
    debug1: ssh_rsa_verify: signature correct
    debug2: kex_derive_keys
    debug2: set_newkeys: mode 1
    debug1: SSH2_MSG_NEWKEYS sent
    debug1: expecting SSH2_MSG_NEWKEYS
    debug2: set_newkeys: mode 0
    debug1: SSH2_MSG_NEWKEYS received
    debug1: SSH2_MSG_SERVICE_REQUEST sent
    debug2: service_accept: ssh-userauth
    debug1: SSH2_MSG_SERVICE_ACCEPT received
    debug2: key: /home/bluethundr/.ssh/identity ((nil))
    debug2: key: /home/bluethundr/.ssh/id_rsa (0x9c43a88)
    debug2: key: /home/bluethundr/.ssh/id_dsa ((nil))
    debug1: Authentications that can continue: publickey,gssapi-with-mic,password
    debug3: start over, passed a different list publickey,gssapi-with-mic,password
    debug3: preferred gssapi-with-mic,publickey,keyboard-interactive,password
    debug3: authmethod_lookup gssapi-with-mic
    debug3: remaining preferred: publickey,keyboard-interactive,password
    debug3: authmethod_is_enabled gssapi-with-mic
    debug1: Next authentication method: gssapi-with-mic
    debug3: Trying to reverse map address 192.168.1.23.
    debug1: Unspecified GSS failure. Minor code may provide more information
    No credentials cache found

    debug1: Unspecified GSS failure. Minor code may provide more information
    No credentials cache found

    debug1: Unspecified GSS failure. Minor code may provide more information
    No credentials cache found

    debug2: we did not send a packet, disable method
    debug3: authmethod_lookup publickey
    debug3: remaining preferred: keyboard-interactive,password
    debug3: authmethod_is_enabled publickey
    debug1: Next authentication method: publickey
    debug1: Trying private key: /home/bluethundr/.ssh/identity
    debug3: no such identity: /home/bluethundr/.ssh/identity
    debug1: Offering public key: /home/bluethundr/.ssh/id_rsa
    debug3: send_pubkey_test
    debug2: we sent a publickey packet, wait for reply
    debug1: Authentications that can continue: publickey,gssapi-with-mic,password
    debug1: Trying private key: /home/bluethundr/.ssh/id_dsa
    debug3: no such identity: /home/bluethundr/.ssh/id_dsa
    debug2: we did not send a packet, disable method
    debug3: authmethod_lookup password
    debug3: remaining preferred: ,password
    debug3: authmethod_is_enabled password
    debug1: Next authentication method: password
    bluethundr at virt1's password:
  • JohnS at Oct 22, 2010 at 3:53 pm
    On Fri, 2010-10-22 at 15:30 -0400, Tim Dunphy wrote
    The permissions on the .ssh directory must also be correct. Otherwise, yes.
    ---
    chmod 755 ~/.ssh

    chmod 644 ~/.ssh/authorized_keys

    John

    drwxr-xr-x 2 ethan ethan 4096 Oct 10 17:16 .ssh
    -rw-r--r-- 1 ethan ethan 396 Oct 10 17:16 authorized_keys
  • Brian Mathis at Oct 22, 2010 at 4:25 pm

    On Fri, Oct 22, 2010 at 3:53 PM, JohnS wrote:
    On Fri, 2010-10-22 at 15:30 -0400, Tim Dunphy wrote
    The permissions on the .ssh directory must also be correct. ?Otherwise, yes.
    ---
    chmod 755 ~/.ssh

    chmod 644 ~/.ssh/authorized_keys

    John

    drwxr-xr-x ?2 ethan ethan ? ?4096 Oct 10 17:16 .ssh
    -rw-r--r-- ?1 ethan ethan ?396 Oct 10 17:16 authorized_keys
    No, that's the opposite of what you want. If that works for you then
    your sysadmin has disabled StrictModes and it may leave you open to
    some security issues.

    Directory should be 700. File should be 600.
  • JohnS at Oct 22, 2010 at 5:21 pm

    On Fri, 2010-10-22 at 16:25 -0400, Brian Mathis wrote:
    On Fri, Oct 22, 2010 at 3:53 PM, JohnS wrote:

    On Fri, 2010-10-22 at 15:30 -0400, Tim Dunphy wrote
    The permissions on the .ssh directory must also be correct. Otherwise, yes.
    ---
    chmod 755 ~/.ssh

    chmod 644 ~/.ssh/authorized_keys

    John

    drwxr-xr-x 2 ethan ethan 4096 Oct 10 17:16 .ssh
    -rw-r--r-- 1 ethan ethan 396 Oct 10 17:16 authorized_keys
    No, that's the opposite of what you want. If that works for you then
    your sysadmin has disabled StrictModes and it may leave you open to
    some security issues.

    Directory should be 700. File should be 600.
    ----
    Thats's is so damn funny tell Red Hat not me :-)

    1. It is default that is a WORK for ALL...

    hn
  • Todd Denniston at Oct 22, 2010 at 4:08 pm

    Tim Dunphy wrote, On 10/22/2010 03:30 PM:
    hmm.. ok then gordon thanks for the input! how do these permissions grab ya?


    [bluethundr at LCENT01 ~]$ ls -alh | grep .ssh
    -rw------- 1 bluethundr summitnjops 70 Oct 17 14:04 .lesshst
    drwx------ 2 bluethundr summitnjops 512 Oct 22 14:06 .ssh


    [bluethundr at LCENT01 ~]$ ls -lah .ssh
    total 34K
    drwx------ 2 bluethundr summitnjops 512 Oct 22 14:06 .
    drwx------ 106 bluethundr summitnjops 5.5K Oct 22 14:44 ..
    -rw------- 1 bluethundr summitnjops 820 Oct 22 14:19 authorized_keys
    -rw------- 1 bluethundr summitnjops 1.7K Oct 22 14:18 id_rsa
    -rw-r--r-- 1 bluethundr summitnjops 403 Oct 22 14:18 id_rsa.pub
    -rw-r--r-- 1 bluethundr summitnjops 20K Oct 22 14:47 known_hosts
    [bluethundr at LCENT01 ~]$
    An experiment for you...

    Assumptions:
    1) NFS v3
    2) on the NFS server the file system is named '/exportedfilesytem'
    3) have root on both machines
    4) on the NFS client the file system is mounted such that it contains bluethundr's home directory
    5) root_squash is in play

    On the NFS server
    MYNFSFS=/exportedfilesytem
    grep $MYNFSFS /etc/exports
    grep $MYNFSFS /etc/exports | grep -v no_root_squash
    #if you get a line back then root on the client machine is being squashed.
    man exports #search down for root_squash

    On the NFS client (virt1)
    ####
    login as root
    ####
    cd ~bluethundr/.ssh/
    #you may have just gotten an error.
    ls -lah ~bluethundr/.ssh/*
    #you may have just gotten an error.
    cat ~bluethundr/.ssh/authorized_keys
    #you _have_ just gotten an error, and this is the one that stops you IIRC.


    Suggestions:
    1) Consider tightening up perms on id_rsa.pub & known_hosts
    2) Open up the _read_ perms on authorized_keys
    3a) IIRC you _may_ also have to open up the _read_ perms on ~/.ssh
    3b) IIRC you _may_ also have to open up the exec perms on ~/.ssh
    If you have to do one of 3a or 3b, try each individually and only give as much as you have to.

    --
    Todd Denniston
    Crane Division, Naval Surface Warfare Center (NSWC Crane)
    Harnessing the Power of Technology for the Warfighter
  • Tim Dunphy at Oct 22, 2010 at 4:52 pm
    guys awesome advice!! I will try your suggestions sometime tonight, I
    am backing up the virtual network at the moment and it is therefore
    shutdown until the backup is done.

    thanks !!
    tim

    On Fri, Oct 22, 2010 at 4:08 PM, Todd Denniston
    wrote:
    Tim Dunphy wrote, On 10/22/2010 03:30 PM:
    hmm.. ok then gordon thanks for the input! how do these permissions grab ya?


    [bluethundr at LCENT01 ~]$ ls -alh | grep .ssh
    -rw------- ? 1 bluethundr summitnjops ? ?70 Oct 17 14:04 .lesshst
    drwx------ ? 2 bluethundr summitnjops ? 512 Oct 22 14:06 .ssh


    [bluethundr at LCENT01 ~]$ ls -lah .ssh
    total 34K
    drwx------ ? 2 bluethundr summitnjops ?512 Oct 22 14:06 .
    drwx------ 106 bluethundr summitnjops 5.5K Oct 22 14:44 ..
    -rw------- ? 1 bluethundr summitnjops ?820 Oct 22 14:19 authorized_keys
    -rw------- ? 1 bluethundr summitnjops 1.7K Oct 22 14:18 id_rsa
    -rw-r--r-- ? 1 bluethundr summitnjops ?403 Oct 22 14:18 id_rsa.pub
    -rw-r--r-- ? 1 bluethundr summitnjops ?20K Oct 22 14:47 known_hosts
    [bluethundr at LCENT01 ~]$
    An experiment for you...

    Assumptions:
    1) NFS v3
    2) on the NFS server the file system is named '/exportedfilesytem'
    3) have root on both machines
    4) on the NFS client the file system is mounted such that it contains bluethundr's home directory
    5) root_squash is in play

    On the NFS server
    MYNFSFS=/exportedfilesytem
    grep $MYNFSFS /etc/exports
    grep $MYNFSFS /etc/exports | grep -v no_root_squash
    #if you get a line back then root on the client machine is being squashed.
    man exports #search down for root_squash

    On the NFS client (virt1)
    ####
    login as root
    ####
    cd ~bluethundr/.ssh/
    #you may have just gotten an error.
    ls -lah ~bluethundr/.ssh/*
    #you may have just gotten an error.
    cat ~bluethundr/.ssh/authorized_keys
    #you _have_ just gotten an error, and this is the one that stops you IIRC.


    Suggestions:
    1) Consider tightening up perms on id_rsa.pub & known_hosts
    2) Open up the _read_ perms on authorized_keys
    3a) IIRC you _may_ also have to open up the _read_ perms on ~/.ssh
    3b) IIRC you _may_ also have to open up the exec perms on ~/.ssh
    If you have to do one of 3a or 3b, try each individually and only give as much as you have to.

    --
    Todd Denniston
    Crane Division, Naval Surface Warfare Center (NSWC Crane)
    Harnessing the Power of Technology for the Warfighter
    _______________________________________________
    CentOS mailing list
    CentOS at centos.org
    http://lists.centos.org/mailman/listinfo/centos


    --
    Here's my RSA Public key:
    gpg --keyserver pgp.mit.edu --recv-keys 5A4873A9

    Share and enjoy!!
  • Gordon Messmer at Oct 24, 2010 at 4:20 pm
    On 10/22/2010 01:08 PM, Todd Denniston wrote:
    ...
    5) root_squash is in play ...
    2) Open up the _read_ perms on authorized_keys
    3a) IIRC you _may_ also have to open up the _read_ perms on ~/.ssh
    3b) IIRC you _may_ also have to open up the exec perms on ~/.ssh
    root_squash doesn't affect ssh key authentication. The SSH server
    performs key authentication as the UID requested.
  • Todd Denniston at Oct 25, 2010 at 9:47 am

    Gordon Messmer wrote, On 10/24/2010 04:20 PM:
    On 10/22/2010 01:08 PM, Todd Denniston wrote:
    ...
    5) root_squash is in play ...
    2) Open up the _read_ perms on authorized_keys
    3a) IIRC you _may_ also have to open up the _read_ perms on ~/.ssh
    3b) IIRC you _may_ also have to open up the exec perms on ~/.ssh
    root_squash doesn't affect ssh key authentication. The SSH server
    performs key authentication as the UID requested.
    Thanks, I was not aware of that before.

    some more assumptions I don't think have been confirmed:
    a) does The OPs _current_ private key match any of the _current_
    .ssh/authorized_keys or .ssh/identity or .ssh/id_rsa
    from the perspective of the client machine?

    b) can the OP use the _current_ private key to ssh into 127.0.0.1 while logged into either of the
    machines? i.e. are the keys setup correctly at all?

    --
    Todd Denniston
    Crane Division, Naval Surface Warfare Center (NSWC Crane)
    Harnessing the Power of Technology for the Warfighter
  • Mike Hanby at Oct 28, 2010 at 7:18 pm
    Another thing to check is the permission for your $HOME, make sure you don't have group or other W permissions. Better yet:

    chmod 700 $HOME

    Mike

    -----Original Message-----
    From: centos-bounces at centos.org [mailto:centos-bounces at centos.org] On Behalf Of Todd Denniston
    Sent: Monday, October 25, 2010 8:47 AM
    To: CentOS mailing list
    Subject: Re: [CentOS] ssh with shared home dir

    Gordon Messmer wrote, On 10/24/2010 04:20 PM:
    On 10/22/2010 01:08 PM, Todd Denniston wrote:
    ...
    5) root_squash is in play ...
    2) Open up the _read_ perms on authorized_keys
    3a) IIRC you _may_ also have to open up the _read_ perms on ~/.ssh
    3b) IIRC you _may_ also have to open up the exec perms on ~/.ssh
    root_squash doesn't affect ssh key authentication. The SSH server
    performs key authentication as the UID requested.
    Thanks, I was not aware of that before.

    some more assumptions I don't think have been confirmed:
    a) does The OPs _current_ private key match any of the _current_
    .ssh/authorized_keys or .ssh/identity or .ssh/id_rsa
    from the perspective of the client machine?

    b) can the OP use the _current_ private key to ssh into 127.0.0.1 while logged into either of the
    machines? i.e. are the keys setup correctly at all?

    --
    Todd Denniston
    Crane Division, Naval Surface Warfare Center (NSWC Crane)
    Harnessing the Power of Technology for the Warfighter
    _______________________________________________
    CentOS mailing list
    CentOS at centos.org
    http://lists.centos.org/mailman/listinfo/centos
  • Robert Heller at Oct 22, 2010 at 8:42 pm

    At Fri, 22 Oct 2010 15:30:03 -0400 CentOS mailing list wrote:

    hmm.. ok then gordon thanks for the input! how do these permissions grab ya?


    [bluethundr at LCENT01 ~]$ ls -alh | grep .ssh
    -rw------- 1 bluethundr summitnjops 70 Oct 17 14:04 .lesshst
    drwx------ 2 bluethundr summitnjops 512 Oct 22 14:06 .ssh


    [bluethundr at LCENT01 ~]$ ls -lah .ssh
    total 34K
    drwx------ 2 bluethundr summitnjops 512 Oct 22 14:06 .
    drwx------ 106 bluethundr summitnjops 5.5K Oct 22 14:44 ..
    -rw------- 1 bluethundr summitnjops 820 Oct 22 14:19 authorized_keys
    -rw------- 1 bluethundr summitnjops 1.7K Oct 22 14:18 id_rsa
    -rw-r--r-- 1 bluethundr summitnjops 403 Oct 22 14:18 id_rsa.pub
    -rw-r--r-- 1 bluethundr summitnjops 20K Oct 22 14:47 known_hosts
    [bluethundr at LCENT01 ~]$


    as is stands, currently, still not working!
    You did copy id_rsa.pub to authorized_keys:

    cat .ssh/id_rsa.pub >> .ssh/authorized_keys

    ???

    Also check /etc/ssh/sshd_config an /etc/ssh/ssh_config. These files
    need to allow public key logins. Also, does /etc/ssh/sshd_config have
    anything set for AllowUsers and/or AllowGroups? All any/all of the
    machines in question?
    this is what it looks like when I ssh to another host that shares this
    home directory (and .ssh dir) as the one I am ssh'ing from.

    [bluethundr at LCENT01 ~]$ ssh virt1
    bluethundr at virt1's password:

    I've posted a -vvv version of the ssh session in an attachment.

    thanks!

    tim
    On Fri, Oct 22, 2010 at 3:14 PM, Gordon Messmer wrote:
    On 10/22/2010 11:38 AM, Tim Dunphy wrote:
    silly quesion: if I generate an RSA key on an NFS shared home
    directory, then cat>> ??it into the .ssh/authorized_keys file in the
    same location, shouldn't I then be able to ssh into each host that
    shares the NFS home directory without entering a passphrase (assuming
    the key doesn't have one)? and assuming the permissions on the
    authorized_keys file belong to the user with mode 600?
    The permissions on the .ssh directory must also be correct. ??Otherwise, yes.
    _______________________________________________
    CentOS mailing list
    CentOS at centos.org
    http://lists.centos.org/mailman/listinfo/centos
    --
    Robert Heller -- 978-544-6933 / heller at deepsoft.com
    Deepwoods Software -- http://www.deepsoft.com/
    () ascii ribbon campaign -- against html e-mail
    /\ www.asciiribbon.org -- against proprietary attachments
  • Robert Heller at Oct 22, 2010 at 8:42 pm

    At Fri, 22 Oct 2010 14:38:37 -0400 CentOS mailing list wrote:
    hey listers!

    silly quesion: if I generate an RSA key on an NFS shared home
    directory, then cat >> it into the .ssh/authorized_keys file in the
    same location, shouldn't I then be able to ssh into each host that
    shares the NFS home directory without entering a passphrase (assuming
    the key doesn't have one)? and assuming the permissions on the
    authorized_keys file belong to the user with mode 600?
    Yes. This works quite well.
    thanks!
    tim
    --
    Robert Heller -- 978-544-6933 / heller at deepsoft.com
    Deepwoods Software -- http://www.deepsoft.com/
    () ascii ribbon campaign -- against html e-mail
    /\ www.asciiribbon.org -- against proprietary attachments
  • Tim Dunphy at Oct 22, 2010 at 10:29 pm
    cd ~bluethundr/.ssh/

    [bluethundr at VIRTCENT01 ~]$ ls -al | grep .ssh
    -rw------- 1 bluethundr 1005 70 Oct 17 14:04 .lesshst
    drwxr-xr-x 2 bluethundr 1005 512 Oct 22 14:06 .ssh
    -rw-r--r-- 1 bluethundr 1005 1047 Sep 16 01:22 sshd-prop.txt
    [bluethundr at VIRTCENT01 ~]$ ls -lh .ssh
    total 28K
    -rw-r--r-- 1 bluethundr 1005 2.9K Oct 22 21:49 authorized_keys
    -rw------- 1 bluethundr 1005 1.7K Oct 22 21:48 id_rsa
    -rw-r--r-- 1 bluethundr 1005 400 Oct 22 21:48 id_rsa.pub
    -rw-r--r-- 1 bluethundr 1005 20K Oct 22 15:59 known_hosts

    [root at VIRTCENT01 ~]# cd ~bluethundr/.ssh/
    [root at VIRTCENT01 .ssh]# ls -lah ~bluethundr/.ssh/*
    -rw-r--r-- 1 bluethundr 1005 2.9K Oct 22 21:49
    /home/bluethundr/.ssh/authorized_keys
    -rw------- 1 bluethundr 1005 1.7K Oct 22 21:48 /home/bluethundr/.ssh/id_rsa
    -rw-r--r-- 1 bluethundr 1005 400 Oct 22 21:48 /home/bluethundr/.ssh/id_rsa.pub
    -rw-r--r-- 1 bluethundr 1005 20K Oct 22 15:59 /home/bluethundr/.ssh/known_hosts
    [root at VIRTCENT01 .ssh]# cat ~bluethundr/.ssh/authorized_keys
    ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA1vQJFa+RDUrqzcnQrzTR7wm3bPGI7cnAX3crAj9KFM3sxuSTP18ZE1V3N7aQ7dju0BJli1PfR/EnlKM/xAybvn4N2yH0bxiKuQwx7M0SvhXy3PUAJu8AuRBGag9yyG0fqJ0lWhcbrKbGwFxYsfpfpLp501Fs5pqqKRSJl4IM5Kv11QcM0ZXLEiJwByiz6vLSBgBxZG3MSgF03F2+gRZbQkPVECAg7e3mValoiZB0K5m3tjMFCr8FZoVVbz4J16fKgIc4WfRFcKTuGEDt3I0agDhosFMVpAvZV4WRYIIpg7nkYpKkIlqSX+GYH+7RPlh2QNQyvS+I0+XOXSdqkP62aQ==
    bluethundr at LCENT01.summitnjhome.com
    ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAtLqML4TD+qE+L544ofOPFPnSUjnG/XIet66K1vvPot+sH81zxeZQgJeREcsOjYUrnApzigd+QudfCGRsNgQ7nFAPUX3edp0Ssi7GCeVTRiBcxYIcVMXm6Fgt2ERyAy0GPdpZCS+R2iKTBgESUo0kQXglm8Jkvlbc8/MDOOEAUiyHBKfOpUPe30qMtYtByNorNWjJz+v1jnGV+T2PVhsHIVpfT501YkHmRVspPy765nEoF9HKQtxc5UOClMCbYrd8R/J7mgtr2RAhFr3lj0dRfVM75hPhI/5qONmomoAoMSdz/c4pjrNlu6MbZV9m8tFi89AviyRkdu0kZt8F6QeJOQ==
    bluethundr at VIRTCENT02
    ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEApnUSYyrM96qIBZKjwSNYycgeSv/BVQTjK7EHqPE1Lv3LLs0ixV9pOXvHMq3YCZHHmgyxwizShnt7MKWFcYPI02ywGHFPawvCM2hIqSwn7kH0KfraHO1Vt+zfcPVsqSo2Mw79cYezVvFYzbSSxCY6O00mZ5PWReyVuOn9Fb/uH/xCzKk9OsCpfCEmNF2YrLCfZvfAATgv7QmIRfsAa+ttLzUELGrfn/n+Xj8K/xqV8C71KPuf8s1OSf/19PLZedv2xSA2KU/OUekAc0gu1HNsC23gLTO7DSasW9y1LStWRryTbpn3UHcwQXlCuw2VtWGkrBCAaLEyG2rE8NIcBOsfHQ==
    bluethundr at lbsd8-2.summitnjhome.com
    -----BEGIN RSA PRIVATE KEY-----
    MIIEoQIBAAKCAQEAvidMglwWPpVBS5DQn983zpDX4HJl9ENErG6mL5bz1BHTv89i
    CrnjwCCHWwZAGTlYqzH/u0+s96CS0LrrZTyJRYBbG4770IZIHN5GEk3Yj867qGcv
    hBA3GLVBVgaH3MSdZU/EByXOANOxVtDq2OOtkfTRZHxYReNxSZtZCUO3dhiMYKPs
    sISCGHDgyUBzqQJP+RtHrPvtS+GzkBfH7y6ilhlCi8Z7Cs9jef6NKiiMeSyv5x2r
    QhMFwM0T+Ny2AO0kcA1up3zZ7OnTU28KhO5E9XvK82hnPA6uKWJvyDTsIZn27XPu
    /KuAG7V+xgbd3VH4NCAKn8ZJ+DRAIxQEX41IjQIBIwKCAQAVu1kzeD0Od3UtNR8o
    NsSMotbX0o9PHaFyytEqAp+F82ioNPVDDe4klgDXM+oRguWP6HT/dtHwah9oT+Bj
    V2AlMz2cv+JDt5M2f81+b0vzLZHKGmvUlCONy5JwO0K6JRlNaDOpC6KDwGwJ6/2V
    IVWqR91qkd4z33qpU5UloVbLqtYVj3Pr98N0UjDy/b+aaNSQH8QxB8GV8HinY8yX
    fhw/IIOq4rrJDR4oN937t2w+5ikUhAyO75ZkkOUq7m8/7k25/X81aAHydaOCUy9X
    mxVuFrBKR8b1lmxX0hsUlkR+hREv8+RcWcxumQmHYVajm8i4MA262sVQdLCWoTfv
    +NBbAoGBAPHraRn5TWirlr0CN/W67z7lYRFqiaNVdQLi1DBDYMj/txN99G2BB8br
    KE/YHsRsEED60Dq6gKfHzZC3atGR3GR16UbFM51bj89myuCoL3EPitIZcmXgP+lW
    W54GjLqYwXPVTvDUJCYue3hAyiWLNguJ4GQvfIRWNC9G68XIDtZ/AoGBAMk4k5xm
    fyszCvd43DFm/c0mpEGVbmwWdJD0mll+PmJuBa72kisqlNSu7Wb3hNTmvod4ygKk
    4foJC64Jy5b/q5feug7O+yuH1K04TEueMdhiqnJQAfR26pDSmGTNhVo1zCy0jvAA
    dZ0lfvMkqQI6iNBemy5NT4ciAwe2JZUjvVLzAoGAfGpwkQPeqtvnH2A6CVjSz+Ou
    Q3iejoO4hSQynHpsSh0cUyrVeiUZ8UW89dzcn4gIW+60O3XbxABbFznB6B8g4zVT
    ZjmIQkxYloyi2fAYZgf+QCpYFyLfCkmrddd7kyn9Fv/8tl54/bGBU8mMiFY5DT+X
    +QJ6jTOlzyvJtixfZv8CgYEAmzpF/E8RpPt9fRQXk9Mbj6F3ZcsMCj01WeFD3qM3
    cIDCjkku7hmIwVO+dADFjkuaSz/sSy689BWbS75p2uJ9DsHCuvdxTXdpjPDqZjg1
    FKPikrK/rfVV3W9CXGQHyT9xntRuRB2cjyuN0YKuQ4w9qA53tgEgF8nH0r+2l586
    R00CgYBMiwcYZxf7aWNd4eUaVSuGPu6bVG/epyKvc5NIVbEGkcx3XOu0Ly0i8K4j
    HeEiztRlp1dJ9231KBKtsRCjZNlwh6NGY+DOU8IGXZMRDYTYbFHJ5yAoAqAeVGrn
    NQO4VuDMKI6u5ZxwuvmP8f8lG1F9EWukp++Rt3FXy0qy9d4TrQ==
    -----END RSA PRIVATE KEY-----


    [bluethundr at nas ~]$ grep $MYNFSFS /etc/exports
    /mnt/nas -alldirs -mapall=root -network 192.168.1.0 -mask 255.255.255.0

    [bluethundr at nas2 /]$ grep $MYNFSFS /etc/exports
    /mnt/store -alldirs -mapall=root -network 192.168.1.0 -mask 255.255.255.0

    [bluethundr at nas2 /]$ grep $MYNFSFS /etc/exports
    /mnt/home -mapall=root -network 192.168.1.0 -mask 255.255.255.0


    yes I did cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys...

    I enabled IdentityFile ~/.ssh/id_rsa and RSAAuthentication yes

    in /etc/ssh/ssh_config and

    RSAAuthentication yes
    PubkeyAuthentication yes
    AuthorizedKeysFile .ssh/authorized_keys


    in /etc/ssh/sshd_config

    still failed... :(

    [bluethundr at VIRTCENT02 ~]$ cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
    [bluethundr at VIRTCENT02 ~]$ ssh virt1
    bluethundr at virt1's password:
    Last login: Fri Oct 22 22:31:41 2010 from 192.168.1.2

    the only thing left I can think of is that bluethundr is an LDAP user.
    can THAT prevent the user from logging in with keys? Also, the root
    user key has been exported across the network and can login without a
    password...


    this is mighty puzzling!!
    On Fri, Oct 22, 2010 at 8:42 PM, Robert Heller wrote:
    At Fri, 22 Oct 2010 14:38:37 -0400 CentOS mailing list wrote:


    hey listers!

    silly quesion: if I generate an RSA key on an NFS shared home
    directory, then cat >> it into the .ssh/authorized_keys file in the
    same location, shouldn't I then be able to ssh into each host that
    shares the NFS home directory without entering a passphrase (assuming
    the key doesn't have one)? and assuming the permissions on the
    authorized_keys file belong to the user with mode 600?
    Yes. ?This works quite well.
    thanks!
    tim
    --
    Robert Heller ? ? ? ? ? ? -- 978-544-6933 / heller at deepsoft.com
    Deepwoods Software ? ? ? ?-- http://www.deepsoft.com/
    () ?ascii ribbon campaign -- against html e-mail
    /\ ?www.asciiribbon.org ? -- against proprietary attachments



    _______________________________________________
    CentOS mailing list
    CentOS at centos.org
    http://lists.centos.org/mailman/listinfo/centos


    --
    Here's my RSA Public key:
    gpg --keyserver pgp.mit.edu --recv-keys 5A4873A9

    Share and enjoy!!
  • JohnS at Oct 22, 2010 at 11:09 pm
    On Fri, 2010-10-22 at 22:29 -0400, Tim Dunphy wrote:


    in /etc/ssh/sshd_config

    still failed... :(

    [bluethundr at VIRTCENT02 ~]$ cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
    [bluethundr at VIRTCENT02 ~]$ ssh virt1
    bluethundr at virt1's password:
    Last login: Fri Oct 22 22:31:41 2010 from 192.168.1.2

    the only thing left I can think of is that bluethundr is an LDAP user.
    can THAT prevent the user from logging in with keys? Also, the root
    user key has been exported across the network and can login without a
    password...
    ----
    PermitEmptyPasswords no ???? In sshd_config on the server ??? That
    would work for keys that do not have a password. You created the key
    without a password right?

    John
  • JohnS at Oct 22, 2010 at 11:13 pm
    On Fri, 2010-10-22 at 22:29 -0400, Tim Dunphy wrote:
    Would someone @ mail dot centos dot org delete this email expung it
    from public view???

    """"http://lists.centos.org/pipermail/centos/2010-October/100563.html""""
  • Tim Dunphy at Oct 22, 2010 at 11:17 pm
    PermitEmptyPasswords no ???? In sshd_config on the server ??? That
    would work for keys that do not have a password. You created the key
    without a password right?


    yes I created it without a key.. and enabled PermitEmptyPasswords yes
    in sshd_config
    Would someone @ mail dot centos dot org delete this email expung it
    from public view???


    uhm.. what's your problem, dude?


    On Fri, Oct 22, 2010 at 11:13 PM, JohnS wrote:

    On Fri, 2010-10-22 at 22:29 -0400, Tim Dunphy wrote:
    ?Would someone @ mail ?dot centos dot org delete this email expung it
    from public view???

    """"http://lists.centos.org/pipermail/centos/2010-October/100563.html""""

    _______________________________________________
    CentOS mailing list
    CentOS at centos.org
    http://lists.centos.org/mailman/listinfo/centos


    --
    Here's my RSA Public key:
    gpg --keyserver pgp.mit.edu --recv-keys 5A4873A9

    Share and enjoy!!
  • Ben McGinnes at Oct 22, 2010 at 11:25 pm

    On 23/10/10 2:17 PM, Tim Dunphy wrote:
    Would someone @ mail dot centos dot org delete this email expung it
    from public view???
    uhm.. what's your problem, dude?
    He's probably referring to the private RSA SSH key that has been posted
    in that message. Actually, that would be *your* private key. Time to
    make a new one.


    Regards,
    Ben

    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: signature.asc
    Type: application/pgp-signature
    Size: 259 bytes
    Desc: OpenPGP digital signature
    Url : http://lists.centos.org/pipermail/centos/attachments/20101023/f68c5b7a/attachment.bin
  • JohnS at Oct 22, 2010 at 11:25 pm

    On Fri, 2010-10-22 at 23:17 -0400, Tim Dunphy wrote:
    uhm.. what's your problem, dude?

    My problem is you Private Key is Wide Open to the whole World so now go
    and create a new one, unless you the world to have it.

    :-)

    John
  • Tim Dunphy at Oct 23, 2010 at 8:38 am
    hahah.. thanks john! :) fortunately that key was in existence for only
    a few hours, and has now been deleted. it was behind a firewall. just
    sayin! but good catch!!!

    thanks!! :-)
    On Fri, Oct 22, 2010 at 11:25 PM, JohnS wrote:
    On Fri, 2010-10-22 at 23:17 -0400, Tim Dunphy wrote:
    uhm.. what's your problem, dude?

    My problem is you Private Key is Wide Open to the whole World so now go
    and create a new one, unless you the world to have it.

    :-)

    John

    _______________________________________________
    CentOS mailing list
    CentOS at centos.org
    http://lists.centos.org/mailman/listinfo/centos


    --
    Here's my RSA Public key:
    gpg --keyserver pgp.mit.edu --recv-keys 5A4873A9

    Share and enjoy!!
  • Gordon Messmer at Oct 24, 2010 at 4:12 pm

    On 10/22/2010 08:17 PM, Tim Dunphy wrote:
    PermitEmptyPasswords no ???? In sshd_config on the server ??? That
    would work for keys that do not have a password. You created the key
    without a password right?
    The server does not know whether the client's key has a passphrase.
    PermitEmptyPasswords has no effect on key authentication.
  • JohnS at Oct 24, 2010 at 5:25 pm

    On Sun, 2010-10-24 at 13:12 -0700, Gordon Messmer wrote:
    On 10/22/2010 08:17 PM, Tim Dunphy wrote:
    PermitEmptyPasswords no ???? In sshd_config on the server ??? That
    would work for keys that do not have a password. You created the key
    without a password right?
    The server does not know whether the client's key has a passphrase.
    PermitEmptyPasswords has no effect on key authentication.
    _______________________________________________
    Had to go back and try it I thought it did. I think what I meant was
    PasswordAuthentication no ?

    John
  • Gordon Messmer at Oct 25, 2010 at 4:47 am

    On 10/24/2010 02:25 PM, JohnS wrote:
    On Sun, 2010-10-24 at 13:12 -0700, Gordon Messmer wrote:
    On 10/22/2010 08:17 PM, Tim Dunphy wrote:
    PermitEmptyPasswords no ???? In sshd_config on the server ??? That
    would work for keys that do not have a password. You created the key
    without a password right?
    The server does not know whether the client's key has a passphrase.
    PermitEmptyPasswords has no effect on key authentication.
    Had to go back and try it I thought it did. I think what I meant was
    PasswordAuthentication no ?
    Doesn't matter... That setting won't interact with keys whether they
    have a passphrase or not.
  • JohnS at Oct 25, 2010 at 6:19 am

    On Mon, 2010-10-25 at 01:47 -0700, Gordon Messmer wrote:
    On 10/24/2010 02:25 PM, JohnS wrote:
    On Sun, 2010-10-24 at 13:12 -0700, Gordon Messmer wrote:
    On 10/22/2010 08:17 PM, Tim Dunphy wrote:
    PermitEmptyPasswords no ???? In sshd_config on the server ??? That
    would work for keys that do not have a password. You created the key
    without a password right?
    The server does not know whether the client's key has a passphrase.
    PermitEmptyPasswords has no effect on key authentication.
    Had to go back and try it I thought it did. I think what I meant was
    PasswordAuthentication no ?
    Doesn't matter... That setting won't interact with keys whether they
    have a passphrase or not.
    ---
    Well this is why it did :0
    It did so because the permissions on the know_hosts file were wrong that
    is why I it did. I went back and checked the logs to see why because I
    knew it did. So it fooled me (-...

    John
  • John R Pierce at Oct 22, 2010 at 11:25 pm

    On 10/22/10 8:13 PM, JohnS wrote:
    On Fri, 2010-10-22 at 22:29 -0400, Tim Dunphy wrote:
    Would someone @ mail dot centos dot org delete this email expung it
    from public view???

    """"http://lists.centos.org/pipermail/centos/2010-October/100563.html""""
    it wouldn't matter. those keys are now sitting in 1000s of inboxes, and
    probably numerous web archives.


    every one of those hosts needs its keys revoked and replaced.
  • Michael Semcheski at Oct 22, 2010 at 11:27 pm

    On Fri, Oct 22, 2010 at 10:29 PM, Tim Dunphy wrote:
    this is mighty puzzling!!
    Have you investigated whether SELinux is stopping this?

    If so, this will probably fix it:

    chcon -RP /home/user/.ssh
  • Gordon Messmer at Oct 24, 2010 at 4:17 pm

    On 10/22/2010 07:29 PM, Tim Dunphy wrote:
    the only thing left I can think of is that bluethundr is an LDAP user.
    can THAT prevent the user from logging in with keys?
    No. LDAP users work fine. Have you tried looking at /var/log/secure?
    Typically the cause for failed authentication is logged there, including
    bad permissions.

    I didn't mention it the first time because it seemed ridiculous, but
    your home directory may be at fault, too. Your home directory, .ssh,
    and .ssh/authorized_keys must all restrict group and others from
    writing. That is, none of those three can have permissions greater than
    0755.
  • John Doe at Oct 25, 2010 at 5:59 am
    From: Tim Dunphy [bluethundr at VIRTCENT02 ~]$ ssh virt1
    bluethundr at virt1's password:
    Tried ssh -vv or -vvv?

    JD

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcentos @
categoriescentos
postedOct 22, '10 at 2:38p
activeOct 28, '10 at 7:18p
posts28
users11
websitecentos.org
irc#centos

People

Translate

site design / logo © 2021 Grokbase