FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > CentOS > CentOS

 
 
LinkBack Thread Tools
 
Old 10-22-2010, 06:38 PM
Tim Dunphy
 
Default ssh with shared home dir

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!!
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 10-22-2010, 07:14 PM
Gordon Messmer
 
Default ssh with shared home dir

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@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 10-22-2010, 07:30 PM
Tim Dunphy
 
Default ssh with shared home dir

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


[bluethundr@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@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@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@LCENT01 ~]$ ssh virt1
bluethundr@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 <yinyang@eburg.com> 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@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!!
[bluethundr@LCENT01 ~]$ ssh virt1
bluethundr@virt1's password:

[bluethundr@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@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@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: none,zlib@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@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@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: none,zlib@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@virt1's password:
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 10-22-2010, 07:53 PM
JohnS
 
Default ssh with shared home dir

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

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 10-22-2010, 08:08 PM
Todd Denniston
 
Default ssh with shared home dir

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@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@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@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@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 10-22-2010, 08:25 PM
Brian Mathis
 
Default ssh with shared home dir

On Fri, Oct 22, 2010 at 3:53 PM, JohnS <jses27@gmail.com> 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.
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 10-22-2010, 08:52 PM
Tim Dunphy
 
Default ssh with shared home dir

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
<Todd.Denniston@tsb.cranrdte.navy.mil> 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@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@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@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@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!!
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 10-22-2010, 09:21 PM
JohnS
 
Default ssh with shared home dir

On Fri, 2010-10-22 at 16:25 -0400, Brian Mathis wrote:
> On Fri, Oct 22, 2010 at 3:53 PM, JohnS <jses27@gmail.com> 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

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 10-23-2010, 12:42 AM
Robert Heller
 
Default ssh with shared home dir

At Fri, 22 Oct 2010 15:30:03 -0400 CentOS mailing list <centos@centos.org> wrote:

>
>
> hmm.. ok then gordon thanks for the input! how do these permissions grab ya?
>
>
> [bluethundr@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@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@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@LCENT01 ~]$ ssh virt1
> bluethundr@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 <yinyang@eburg.com> 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@centos.org
> > http://lists.centos.org/mailman/listinfo/centos
> >
>
>
>

--
Robert Heller -- 978-544-6933 / heller@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@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 10-23-2010, 12:42 AM
Robert Heller
 
Default ssh with shared home dir

At Fri, 22 Oct 2010 14:38:37 -0400 CentOS mailing list <centos@centos.org> 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@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@centos.org
http://lists.centos.org/mailman/listinfo/centos
 

Thread Tools




All times are GMT. The time now is 04:39 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org