On Fri, Dec 30, 2011 at 2:47 PM, Werner Flamme <werner.fla...@ufz.de> wrote: > [25.12.2011 17:03] [Nico Kadel-Garcia]: >> On Sun, Dec 25, 2011 at 3:44 AM, Werner Flamme <werner.fla...@ufz.de> wrote: >>> Am 25.12.2011 04:37, schrieb Aurelin: >>> >>>>> I have this even without using rssh, so it may not be related. This >>>>> occurs when ~/.ssh and its contents have wrong owners or rights, or >>>>> when the shell profiles have wrong owner/rights, or whenever sshd >>>>> thinks something is wrong. At least the latter is my guess... >>>> This is a possibility. You may not have some of the files with 777 >>>> permissions in ~/.ssh/, and I _think_ it's the same for the directory. >>>> Can't tell it by heart now. It's also true that a wrong owner will make >>>> ssh go failing. >>> >>> There is no file with 777 permissions in .ssh. I am not mad, you know? >>> ;-) The rights of the directory itself, and most of its content, must be >>> 0600. Only the public keys should be world readable. And everything must >>> belong to the right owner. >> >> This is incorrect. flatly incorrect. >> >> The typical permissions are: >> >> $HOME/. 0700 (or possibly 0775, tastes vary and other settings can >> work, write permission is *optional*) >> $HOME/.ssh 0700 (or possibly 0750, again, tastes can vary and other >> settings in between can work, write permission is *optional*) >> "others" should not have access to this > > I wrote the last answer from a Loosedos sation an could not look > properly) seems suicidal to me. > >> $HOME/.ssh/authorized_keys 0600 (or possibly 0400, tastes vary) >> *No one else*, either group members or "other", should have access >> to this file. >> >> Private keys can be stored however the heck you want them. SSH clients >> *do not care*, and they can be anywhere you want with whatever >> permissions you want, including $HOME/.ssh/privatekey with permissions >> 7777 if you feel like it. > > >From my man page: > ---snip--- > ssh will simply ignore a private key file if it is accessible by others. > ---pins--- > > So, you obviously have another version of ssh in use than me. I use SLES > 11 SP1 and openSUSE 12.1 with their respective openssh versions at the > office. None of them permits access by other users than me.
I'd like to point you to CygWin. Windows file access gets..... *fascinating* when you have to re-interpret it inside CygWin. Also, Pageant has to deal with Windows permissions and could not care less about file ownership. So yes, it's a different client on a different filesystem, and I overshot. This is not the protocol that cares: this is intelligent default behavior written into the client. And there are some *HORRIBLE* clients out there. Ownership and permissions of the ".ssh" directory" are auto-built as 0700 when running SSH commands, but can be reset in quite open fashion. This includes 0777, allowing others to modify and replace your private keys or known_hosts file. It's the *daemon* that then gets picky about what it accepts for authorized_keys access. >>> There is no problem with that. But why doesn't sshd tell me in its log >>> the reason for closing the connection? Why do I have to resort to "ssh >>> -vvv" to discover it? >> >> Because some sone of a !@#$ can overwhelm your SSH log files with >> failed connections if it's too verbose, and the balance between useful >> information and log spew is a tricky one. > > Hm. Yes, it is. However, I do not speak of setting a high debug level on > a server that is accessible from the internet. I speak of the ssh > daemon of a server that is inside a special, isolated subrange inside my > comapny's network range. There are about 20 boxes in this range, and > there is nearly no chance to blow a log. And in that environment, you can crank up logging. >> Sorry if I seem a bit cranky about this, I've been dealing with SSH >> for a long time, and I get a bit touchy when errors get posted as "it >> has to be this way". > > Better watch this for your own post :-P - see the note about private > keys above. Fair enough. Note my followup. The permission checking is part of the particular client, not part of the protocol itself, and should be denoted accordingly. > > Have a nice 2012! > Werner > > ------------------------------------------------------------------------------ > Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex > infrastructure or vast IT resources to deliver seamless, secure access to > virtual desktops. With this all-in-one solution, easily deploy virtual > desktops for less than the cost of PCs and save 60% on VDI infrastructure > costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox > _______________________________________________ > rssh-discuss mailing list > rssh-discuss@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/rssh-discuss ------------------------------------------------------------------------------ Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox _______________________________________________ rssh-discuss mailing list rssh-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rssh-discuss
