2

Я недавно установил последнюю Ubuntu 12.04 64bit alpha (2?) на виртуальную машину VMware, чтобы проверить вещи.

Одна странная вещь, с которой я столкнулся, заключается в том, что я могу успешно войти в систему только по ssh, если я вошел в консоль. Если я выйду из консоли, я получу отказано в разрешении.

Это довольно сложно, так что я надеюсь, что кто-то еще видел это.

Ниже приводится вывод.

OpenSSH_5.6p1, OpenSSL 0.9.8r 8 Feb 2011
debug1: Reading configuration data /Users/foo/.ssh/config
debug1: Applying options for b06
debug1: Applying options for *
debug1: Reading configuration data /etc/ssh_config
debug1: Applying options for *
debug1: auto-mux: Trying existing master
debug1: Control socket "/Users/foo/.ssh/mux/ssh_mux_foo" does not exist
debug1: Connecting to foo [xx.xx.xx.xx] port 22.
debug1: Connection established.
debug1: identity file /Users/foo/.ssh/id_rsa-4096 type 1
debug1: identity file /Users/foo/.ssh/id_rsa-4096-cert type -1
debug1: identity file /Users/foo/.ssh/id_rsa type 1
debug1: identity file /Users/foo/.ssh/id_rsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9p1 Debian-2ubuntu2
debug1: match: OpenSSH_5.9p1 Debian-2ubuntu2 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.6
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host '[foo]:22' is known and matches the RSA host key.
debug1: Found key in /Users/foo/.ssh/known_hosts:1
Host key fingerprint is 

debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/foo/.ssh/id_rsa-4096
debug1: Authentications that can continue: publickey
debug1: Offering RSA public key: /Users/foo/.ssh/id_rsa
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
Permission denied (publickey).
|источник

3 ответа3

6

Это всего лишь предположение, но, насколько мне известно, Ubuntu по умолчанию шифрует домашние папки пользователя. Когда вы не вошли в систему, ~/.ssh/authorized_keys не будет доступен для чтения с помощью sshd на хост-компьютере, и, следовательно, ваша аутентификация pubkey не пройдёт.

|источник
0

Так что после еще нескольких копаний у меня есть решение моей проблемы. Я не упомянул, что мой домашний каталог зашифрован, поэтому, подумав об этом, становится понятно, что все не работает.

Вот исправление:

  • Следуйте инструкциям на этом URL
  • Вы можете войти после этого, но все равно не увидите свой домашний каталог
  • Вам нужно запустить «ecryptfs-mount-private» и указать свой пароль
  • Наконец, сделайте "CD", чтобы добраться до вашего каталога

Это действительно своего рода боль в заднице, но я понимаю, почему это было сделано так. Я открыт для предложений, которые запрещают мне вводить пароль в "ecryptfs-mount-private". Но это лучшее, что у меня есть на данный момент.

|источник
0

Из того, что он говорит, я могу думать об одном:

  1. Вы добавили старый ключ rsa_key в файл known_hosts на новом компьютере. Затем по какой-то причине в конфигурации ssh были разрешены только ключи, которые были добавлены в known_hosts.

Я не знаю, почему они перешли на новую версию Ubuntu. Файл конфигурации ssh должен быть в /etc /sshd_config

Надеюсь, что это поможет, или, по крайней мере, внесет лучшую идею в чей-то разум.

|источник

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