Re: Connection closed by server with exitcode 1
Brought to you by:
xystrus
From: Nico Kadel-G. <nk...@gm...> - 2011-12-25 16:03:31
|
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 $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. > 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. 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". >>> For me, when I try to authenticate via key, there is no chance to >>> enter a password if the key is wrong ("Server refused public key"). I >>> tried to debug with "ssh -vvv ...", and found the wrong owner of >>> ~/.bash_profile, but still have a problem with another user. >>> >> When you've got the wrong key, ssh will fail. It could be that, if you >> have 4 keys in your file and only the 4th is ok, ssh will fail to. There >> is a setting in sshd_conf (I suppose it's there) that tells the server >> how any times he shall try. If it's told to try 3 times, it will fail >> after figuring out that the first 3 keys used by the client are wrong, >> _even though the user had a password that would match_! >> Check this setting and change it or rearrange the order of the keys or >> unload them, if this thing is the case. > > I give one key. And I allow logon via password. I know from older > versions of ssh, that the password was asked after thze key failed. At > least with the RH 6 servers, this is not the case any more. > >> >> I had this problem when I had a user a wanting to log in as user b on a >> server. When user a connected to the server as b, the server said "Wrong >> public key" because the first 3 keys didn't match (since they were for >> different connections..). > > In my user a's ~./.ssh/config, there is exactly one key per server. And > this key is used. > >> It is the same with ESX where I had the problem that ESX found out I was >> using Private/Public-Key login in general. >> It then failed when I tried to log in via ILO, because I had 3 keys >> loaded and none of them was ok (obviously.. I never have a root-key for >> ILO-login..) >> Solution was to unload all keys (which made it possible to login with a >> password). > > Another possibility is to use a ~./.ssh/config with correct definitions ;-) And this is a very useful approach indeed, especially if you have multiple SSH access to one server. (One key for backups, one key for shell access is useful.) > And please don't PM me as a response to a list posting. Thank you. > > Best Regards, > Werner You too, and have a good holiday. |