Re: [git-users] Confusion about Key-based SSH authentication

2014-09-03 Thread Dale R. Worley
 From: Xavier Yin wonderera2...@gmail.com
 
 Hi, every one!
 
 I recently read Git on the Server - Setting Up the Server 
 http://git-scm.com/book/en/Git-on-the-Server-Setting-Up-the-Server, I 
 have a confusion about this paragraph as below:
 
 
 Key-based SSH authentication usually enforces security by requiring 
 restricted rights on the involved files. To prevent SSH from refusing to 
 work, type this:
 
 $ chmod -R go= ~/.ssh
 ---

I don't know exactly what causes your issue, and I am not an expert in
SSH.  But I do know that the SSH server daemon enforces certain
restrictions on the permissions of the files in ~user/.ssh.  For
security it is important that no-one other than the user can read any
of the private key files.  Similarly, it is important that no-one
other than the user can modify any of the files in .ssh.  When a
client tries to authenticate as the user, the SSH daemon verifies that
the files in ~user/.ssh meet these requirements, and if they do not,
the daemon refuses the connection.  Probably the easiest way to ensure
that the .ssh directory meets these requirements is the chmod command
listed above.

Dale

-- 
You received this message because you are subscribed to the Google Groups Git 
for human beings group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [git-users] Confusion about Key-based SSH authentication

2014-09-03 Thread Konstantin Khomoutov
On Wed, 3 Sep 2014 09:09:39 -0400
wor...@alum.mit.edu (Dale R. Worley) wrote:

  Key-based SSH authentication usually enforces security by requiring 
  restricted rights on the involved files. To prevent SSH from
  refusing to work, type this:
  
  $ chmod -R go= ~/.ssh
  ---
 
 I don't know exactly what causes your issue, and I am not an expert in
 SSH.  But I do know that the SSH server daemon enforces certain
 restrictions on the permissions of the files in ~user/.ssh.  For
 security it is important that no-one other than the user can read any
 of the private key files.  Similarly, it is important that no-one
 other than the user can modify any of the files in .ssh.  When a
 client tries to authenticate as the user, the SSH daemon verifies that
 the files in ~user/.ssh meet these requirements, and if they do not,
 the daemon refuses the connection.

You're absolutely correct.  One more point is that ~/.ssh on a server
also typically contains a file named authorized_keys which is crucial
for functioning of the pubkey-based authentication: this file contains
fingerprints of the keys the account trusts to authenticate remote
parties as the owner of this account and authorize them as such.
Obviously, no one but the account's owner must have write access to
this file, and this is also checked by the server.

Directory/file insecurities related to SSH on the server are typically
logged appropriately (on a stock Debian-based system that will
be /var/log/auth.log).

-- 
You received this message because you are subscribed to the Google Groups Git 
for human beings group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [git-users] Confusion about Key-based SSH authentication

2014-09-03 Thread Dale R. Worley
 From: Konstantin Khomoutov flatw...@users.sourceforge.net

 Directory/file insecurities related to SSH on the server are typically
 logged appropriately (on a stock Debian-based system that will
 be /var/log/auth.log).

On Fedora, it looks like they go into either /var/log/messages or
/var/log/secure.

Dale

-- 
You received this message because you are subscribed to the Google Groups Git 
for human beings group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.