Может только ssh в альфа-машину Ubuntu 12.04 при входе в консоль

1398
jnman

Недавно я установил новейшую 64-битную альфа-версию Ubuntu 12.04 на виртуальную машину 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).
2

3 ответа на вопрос

6
WakiMiko

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

0
Connor Ross

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

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

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

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

0
jnman

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

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

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

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

В общем, мой ответ был правильным, и проблема была в шифровании. WakiMiko 12 лет назад 1
Чем это лучше, чем вводить пароль для входа? imho это «исправление» делает его гораздо более громоздким, если вы не хотите полностью запретить доступ по SSH по паролю. Невозможно обойти ввод пароля, чтобы все равно разблокировать _ecryptfs_ ключ. На практике это не большая проблема для меня, так как у меня обычно все равно работает сеанс _tmux_. kynan 11 лет назад 0

Похожие вопросы