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
$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.
------------------------------------------------------------------------------
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create
new or port existing apps to sell to consumers worldwide. Explore the
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev
_______________________________________________
rssh-discuss mailing list
rssh-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rssh-discuss
