RE: SSH version 2 "Server refused our key" error

• Previous message: Marc W.: "RE: SSH version 2 "Server refused our key" error"
• Maybe in reply to: Shahrizal Shaari: "SSH version 2 "Server refused our key" error"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

Date: Thu, 21 Aug 2003 11:17:17 -0500
To: <marc@packetfilter.org>, <secureshell@securityfocus.com>

The users dir can be 755 and still not allow ANYONE to read the key. Just make sure you have your permissions set correctly. Best practice here is...
        chmod -R go-rwx ~/.ssh
As for the User bit, it's up to the user(or admin) if they want to risk overwriting and loosing their keys. I myself go with u+r,u-wx,go-rwx (400) for my auth file(s) and private keys. This way I know I'm not going to overwrite them.
All of this is good practice, however you can force this upon the users or their key transfers won't work. In your sshd config, set 'StrictModes' to 'yes' (stop/start sshd of course). This will check if group and other permissions for ~/ssh (and everything under it) as well as the users home dir are disabled.

Back on dirs permissions being set to 755. This does NOT mean the files under this dir are readable by anyone (that depends on the permissions set on the actual file wanting to be read). It just means they can do a directory listing. This is normal, but if you don't want to allow this, go with 700 for ~/ (this is how I've constructed user additions on any heavy user traffic systems I've setup (ISP's, web hosting, etc.). Not sure why you would want the hassle of adding a group per user (why does Multics pop in my head?... or was that c2. heh). That is just too much work. Groups in *nix were created to allow the sharing of files, not isolation of files. That's what permissions(chmod) is for.

-Carl

-----Original Message-----
From: Marc W. [mailto:marc@packetfilter.org]
Sent: Wednesday, August 20, 2003 5:14 PM
To: secureshell@securityfocus.com
Subject: RE: SSH version 2 "Server refused our key" error

Well, the main problem with 755 is that it allows ANYONE (the last 5
there) to read your key. By ANYONE I mean anyone that has access to the
system. Most of the time this is negated by the system being set up so
users are all in seperate groups (joe:joe) and their homedirs are
0750'd, meaning that unless the other person is also in the joe group,
they can't access your homedir. On some systems though, all users are
dumped into the same group (:users mostly) which would mean any other
user could just jump in your homedir. Anyway, back to the problem...if
they can read it, they can copy it, and if they can copy it, they can
brute force it, and ....you see where this is going hopefully.

The reason I mentioned using 0400 is because this would also set it as
read only to even the owner, which really has no need to be editing the
file usually (unless adding in another public key that would allow
access to that user, not a good idea) so at the least you'll get a nag
pop up asking "override read only on authorized_hosts?" and either know
somethings up or whatever app trying to do this business would puke.

In the end it really comes down to what you're willing to risk/accept.
I prefer the "give the least access necissary to ensure acceptable
usage" way. SSH works fine with it set as read-only, so that's all it
gets.

Marc
On Wed, 2003-08-20 at 11:25, Schubert, John [NTWK SVCS] wrote:
> You are correct, the key should be appended to the $HOME/.ssh/authorized_keys file. A couple people disagreed, but I set the permissions to 755 for that dir...no one really explained what was wrong with read and execute priv.
>
> Here's the short version of the install method I've used on a few hundred servers, and had no problems:
>
> Secure copy $HOME/.ssh/id_rsa.pub OTHERHOST:near.id_rsa.pub (OTHERHOST will be the hostname for the new server being set up. I also prepend the rsa with a descriptive name, in this case "near" so I don't confuse who generated the key...if you're doing a few hundred servers it can become confusing)
> ssh OTHERHOST
> ssh-keygen -t rsa (just hit enter to get through passphrase, etc)
> cat near.id_rsa.pub >> $HOME/.ssh/authorized_keys (you want >> because you might be adding multiple keys, this appends)
> chmod 755 . .ssh .ssh/authorized_keys (Note: some don't like the 755, it works for me..I might change it if someone can demonstrate why this is a problem)
>
>
> After doing this a few dozen times, I just created an EXPECT script to do the remaining. Shell scripting had problems waiting for the key generation.
>
> HTH,
> John Schubert
>
> -----Original Message-----
> From: Marc W. [mailto:marc@packetfilter.org]
> Sent: Tuesday, August 19, 2003 11:43 AM
> To: Shahrizal Shaari
> Cc: secureshell@securityfocus.com
> Subject: Re: SSH version 2 "Server refused our key" error
>
>
> AFAIK, the public key should be copied to $HOME/.ssh/authorized_keys ,
> _not_ authorized_keys2. Try renaming it to just authorized_keys. Also
> verify the ownership of the key is set to the user, and that it is at
> least readable by that user (`chmod 0400 authorized_keys` would do the
> trick)
>
>
> On Tue, 2003-08-19 at 02:58, Shahrizal Shaari wrote:
> > Hi everybody,
> >
> > I really need help on how to configure correctly in order to use SSH
> > version 2.
> > SSH version 1 works fine but when i try to use SSH version 2 i kept getting
> > the
> > "Server refused our key" error.
> > I have been looking for the cause of the error but I could't find any.
> > The key that i use is generated with "-t rsa -b 1024" command line option
> > of the ssh-keygen command,and I copied the public key to the
> > HOME/.ssh/authorized_keys2.
> >
> > Here is my server configuration file:
> >
> > # $OpenBSD: sshd_config,v 1.38 2001/04/15 21:41:29 deraadt Exp $
> >
> > # This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin
> >
> > # This is the sshd server system-wide configuration file. See sshd(8)
> > # for more information.
> >
> > Port 22
> > Protocol 2,1
> > #ListenAddress 0.0.0.0
> > #ListenAddress ::
> > HostKey /etc/ssh/ssh_host_key
> > HostKey /etc/ssh/ssh_host_rsa_key
> > HostKey /etc/ssh/ssh_host_dsa_key
> > ServerKeyBits 768
> > LoginGraceTime 600
> > KeyRegenerationInterval 3600
> > PermitRootLogin yes
> > #
> > # Don't read ~/.rhosts and ~/.shosts files
> > IgnoreRhosts yes
> > # Uncomment if you don't trust ~/.ssh/known_hosts for
> > RhostsRSAAuthentication
> > #IgnoreUserKnownHosts yes
> > StrictModes yes
> > X11Forwarding yes
> > X11DisplayOffset 10
> > PrintMotd yes
> > #PrintLastLog no
> > KeepAlive yes
> >
> > # Logging
> > SyslogFacility AUTHPRIV
> > LogLevel INFO
> > #obsoletes QuietMode and FascistLogging
> >
> > RhostsAuthentication no
> > #
> > # 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
> > #
> > RSAAuthentication yes
> >
> > # To disable tunneled clear text passwords, change to no here!
> > PasswordAuthentication no
> > PermitEmptyPasswords no
> >
> > # Uncomment to disable s/key passwords
> > #ChallengeResponseAuthentication no
> >
> > # Uncomment to enable PAM keyboard-interactive authentication
> > # Warning: enabling this may bypass the setting of 'PasswordAuthentication'
> > #PAMAuthenticationViaKbdInt yes
> >
> > # To change Kerberos options
> > #KerberosAuthentication no
> > #KerberosOrLocalPasswd yes
> > #AFSTokenPassing no
> > #KerberosTicketCleanup no
> >
> > # Kerberos TGT Passing does only work with the AFS kaserver
> > #KerberosTgtPassing yes
> >
> > #CheckMail yes
> > #UseLogin no
> >
> > #MaxStartups 10:30:60
> > #Banner /etc/issue.net
> > #ReverseMappingCheck yes
> >
> > Subsystem sftp /usr/libexec/openssh/sftp-server

-- 
Marc W. <marc@packetfilter.org>
Fathorse LTD.

• Previous message: Marc W.: "RE: SSH version 2 "Server refused our key" error"
• Maybe in reply to: Shahrizal Shaari: "SSH version 2 "Server refused our key" error"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]