Re: Connection closed by server with exitcode 1
Brought to you by:
xystrus
From: Werner F. <wer...@uf...> - 2011-12-30 19:47:56
|
[25.12.2011 17:03] [Nico Kadel-Garcia]: > On Sun, Dec 25, 2011 at 3:44 AM, Werner Flamme <wer...@uf...> 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. > >> 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. The speciality with the problem is, that there are 22 virtual servers with one user each that are allowed to log in via ssh key. This works fine for 21, but does not work for the 22nd. As far as I can see, all parameters (files, rights, ...) are identical. Where can I start to search? Even "ssh -vvv" at the client side only tells me that the server closes the connection. But why it does so is not given (that's OK, since I might use the given reason for creating an exploit). But why isn't this reason in the server's log? > 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. Have a nice 2012! Werner |