Kann nur ssh in den Ubuntu 12.04 alpha-Rechner einbinden, wenn er an der Konsole angemeldet ist

1764
jnman

Ich habe kürzlich das neueste Ubuntu 12.04 64bit alpha (2?) Auf einer virtuellen VMware-Maschine installiert, um die Dinge zu überprüfen.

Eine seltsame Sache, die mir begegnet ist, ist, dass ich ssh nur erfolgreich in die Maschine einloggen kann, wenn ich an der Konsole angemeldet bin. Wenn ich mich von der Konsole abmelden, wird mir eine Berechtigung verweigert.

Das ist ziemlich verwirrend, also hoffe ich, dass jemand anderes dies gesehen hat.

Das Folgende ist die Ausgabe.

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 Antworten auf die Frage

6
WakiMiko

This is just a guess, but as far as I know Ubuntu encrypts the user home folders by default. When you are not logged in, ~/.ssh/authorized_keys will not be readable by sshd on the host machine and therefore your pubkey authentication fails.

0
Connor Ross

Aus dem, was es sagt, fällt mir eines ein:

  1. Sie haben der Datei known_hosts auf der neuen Maschine einen alten rsa_key hinzugefügt. Aus irgendeinem Grund wurde die ssh-Konfiguration so eingestellt, dass nur Schlüssel zugelassen werden, die zu den known_hosts hinzugefügt wurden.

Ich weiß nicht, warum sie die neue Version von Ubuntu einschalten würden. Die ssh-Konfigurationsdatei sollte sich unter / etc / sshd_config befinden

Hoffe, das hilft, oder zumindest bringt jemand eine bessere Idee in den Kopf.

0
jnman

Nach etwas mehr Graben habe ich also eine Lösung für mein Problem. Ich habe nicht erwähnt zu erwähnen, dass mein Home-Verzeichnis verschlüsselt ist. Wenn ich also mehr darüber nachdenke, macht es Sinn, dass die Dinge nicht funktionieren.

Hier ist der Fix:

  • Befolgen Sie die Schritte unter dieser URL
  • Sie können sich danach anmelden, Ihr Heimatverzeichnis wird jedoch nicht angezeigt
  • Sie müssen "ecryptfs-mount-private" ausführen und Ihr Kennwort angeben
  • Zum Abschluss führen Sie eine "CD" aus, um in Ihr Verzeichnis zu gelangen

Das ist wirklich eine Art Schmerz im Hintern, aber ich verstehe warum es so gemacht wurde. Ich bin offen für Vorschläge, die es mir unmöglich machen, das Passwort in "ecryptfs-mount-private" einzugeben. Aber das ist das Beste, was ich jetzt habe.

Im Grunde war meine Antwort richtig und die Verschlüsselung war das Problem. WakiMiko vor 12 Jahren 1
Wie ist es in irgendeiner Weise besser, als überhaupt das Passwort für die Anmeldung anzugeben? Imho dieses "Update" macht es viel umständlicher, es sei denn, Sie möchten den Zugriff auf die SSH durch ein Passwort vollständig verhindern. Es gibt keine Möglichkeit, das Kennwort einzugeben, um den Schlüssel _ecryptfs_ zu entsperren. Für mich ist das in der Praxis kein großes Problem, da normalerweise eine _tmux_-Sitzung läuft. kynan vor 12 Jahren 0

Verwandte Probleme