1

У меня есть сервер Ubuntu, работающий для моего SCM, и я делаю свою разработку на компьютере с Windows. Эта установка работала долгое время без каких-либо проблем. Но теперь у меня странная проблема.

Проблема началась, когда мне нужно было изменить права доступа к git-репозиторию на сервере (не говорите, что глупо было chmod весь домашний каталог ... Я уже знаю). После этого каждый раз, когда я пытаюсь получить доступ к серверу через ssh (включительно git), используя мой открытый ключ. Я получаю следующую ошибку:

$ ssh git@192.168.0.240
open log failed: Permission denied
Connection to 192.168.0.240 closed.

Однако, когда я пытаюсь подключиться к серверу, используя только пароль, все работает как положено:

Я попытался запустить sshcommand с -vvv. Это не дает мне никакой идеи, где искать проблему. Может быть, вы можете увидеть что-то из этого.

...
debug2: channel 0: request shell confirm 0
debug2: fd 3 setting TCP_NODELAY
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel 0: rcvd adjust 2097152
debug2: channel 0: rcvd ext data 35
debug2: channel 0: rcvd eof
debug2: channel 0: output open -> drain
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug2: channel 0: rcvd close
debug2: channel 0: close_read
debug2: channel 0: input open -> closed
debug3: channel 0: will not send data after close
debug2: channel 0: obuf_empty delayed efd 6/(35)
open log failed: Permission denied
debug2: channel 0: written 35 to efd 6
debug3: channel 0: will not send data after close
debug2: channel 0: obuf empty
debug2: channel 0: close_write
debug2: channel 0: output drain -> closed
debug2: channel 0: almost dead
debug2: channel 0: gc: notify user
debug2: channel 0: gc: user detached
debug2: channel 0: send close
debug2: channel 0: is dead
debug2: channel 0: garbage collecting
debug1: channel 0: free: client-session, nchannels 1
debug3: channel 0: status: The following connections are open:
  #0 client-session (t4 r0 i3/0 o3/0 fd -1/-1 cfd -1)

Есть идеи?

|источник

2 ответа2

1

Возможно, ваша проблема в том, что права вашего пользовательского ключа неверны. Попробуйте это на сервере Ubuntu:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_rsa ~/.ssh/authorized_keys
chmod 644 ~/.ssh/id_rsa.pub
|источник
1

В дополнение к ответу Тердонса также происходит некоторое странное поведение с ssh-ключами, если ~ доступно для записи другим.

Предположим, вы успешно настроили ssh для использования ключа входа в систему:

user@local:~> ssh remote
Last login: Thu Mar  7 17:39:18 2013 from local
user@remote:~>

Теперь сделайте ваш дом доступным для записи другим пользователем на удаленной машине:

user@remote:~> getfacl .
# file: .
# owner: user
# group: users
user::rwx
group::r-x
other::r-x
user@remote:~> setfacl -m u:coauthor:rwx .
user@remote:~> exit
user@local:~>

Хорошо, теперь попробуйте еще раз войти в удаленный:

user@local:~> ssh remote
user@remote's password:

ssh запрашивает пароль сейчас! Удалите ACL, и ключ voilà ssh снова работает.

[Тогда я мог использовать обходной путь для совместной работы.]

Крейг Сандерс знает причину, это поведение зависит от StrictModes yes в sshd_config. Цитирую man 5 sshd_config:

StrictModes Указывает, должен ли sshd(8) проверять режимы файлов и владение файлами пользователя и домашним каталогом, прежде чем принимать вход в систему. Обычно это желательно, потому что новички иногда случайно покидают свои каталоги или файлы, доступные для записи. По умолчанию «да».

|источник

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .