ssh login ohne Kennwort

[tsaenger]

Hallo zusammen,

Ich habe nach der Anleitung http://www.linux-fuer-alle.de/doc_show.php?docid=233 versucht einen SSH-Zugang einzurichten.
Leider werde ich trotzdem noch nach dem Kennwort gefragt. Verwendet werden Debian-OS.

Hat jemand von euch ein idee woran das liegen kann?

Vielen Dank.

Gruß

Tobias

[Joe User]

Auf beiden Servern in der /etc/ssh/sshd_config diese Einstellungen vornehmen (den Rest bitte auf den Defaults belassen) (wenn das Key-Auth wie gewünscht auf beiden Servern für alle Clients klappt, kannst Du PasswordAuthentication auf no setzen, dann ist ein Login nur noch mit Key möglich):

Code: Select all

PermitRootLogin yes
RSAAuthentication no
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
PasswordAuthentication yes
PermitEmptyPasswords no
ChallengeResponseAuthentication no
UsePAM no

Auf beiden Servern für Deinen Administrations-User und auch für root durchführen (Beispiel für den User admin):

Code: Select all

su - admin
umask 0077
mv .ssh .ssh_bak
mkdir .ssh
ssh-keygen -t rsa -b 2048
cat .ssh/id_rsa.pub >> .ssh/authorized_keys
exit

Dann auf Server2 den Login per Key beim backup-User für den admin-User von Server1 ermöglichen:

Code: Select all

su - backup
umask 0077
mv .ssh .ssh_bak
mkdir .ssh
scp admin@server1:.ssh/id_rsa.pub .ssh/server1_admin_id_rsa.pub
cat .ssh/server1_admin_id_rsa.pub >> .ssh/authorized_keys
exit

Der admin-User (Server1) kann sich nun beim backup-User (Server2) per Key einloggen.

Nun beide SSH-Server restarten und in einer neuen Session probieren ob es funktioniert.

Jetzt kann sich der admin-User (Server1) per Key-Auth also ohne Passwortabfrage per ssh, scp und sftp beim backup-User auf Server2 einloggen.

Zudem kannst und solltest Du Dich ab jetzt auch auf beiden Servern als admin-User oder root von aussen (ssh/PuTTY/WinSCP) per Key-Auth einloggen, statt Passworte zu verwenden.



Die von Dir genutzte Anleitung ist stark veraltet und leicht fehlerhaft:
Für sichere Keys verwendet man schon lange kein dsa mehr, sondern rsa mit mindestens 2048 Bit Schlüssellänge.
Die Reihenfolge von Schritt 2 und dem Übertragen des Keys ist falsch und kann so nicht funktionieren.

[ddm3ve]

Ich befürchte, der Kollege hat dem ssh client nicht mitgegeben, dass er den rivate key anziehen soll.
Bei ssh entweder mit -i <Pfad zur Datei> oder in der /etc/ssh/ssh_config die Identity richtig eintragen.

[rudelgurke]

Oder - um die Liste zu vervollständigen - in $HOME/.ssh/config eine entsprechende Konfiguration. Muss ja nicht jeder auf dem System wissen wo es per SSH hingeht.

[mcfly]

Hallo

Also ich ärgere mich nun schon seit 2 Tagen mit diesem Thema und komme leider nicht weiter. Ich habe die anleitung oben komplett befolgt aber leider kann ich mich nicht ohne Passwort einloggen. Könnt Ihr mir vielleicht helfen den Fehler bei mir zu finden?

Als benutzer habe ich einen zweiten root Account mit dem namen a.wilhelm und mit diesem möchte ich mich auch verbinden per ssh auf meinen Fileserver hier zu hause

ssh -v -p22223 a.wilhelm@10.0.20.1
OpenSSH_5.8p2, OpenSSL 1.0.0e 6 Sep 2011
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to 10.0.20.1 [10.0.20.1] port 22223.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/id_rsa type -1
debug1: identity file /root/.ssh/id_rsa-cert type -1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: identity file /root/.ssh/id_dsa-cert type -1
debug1: identity file /root/.ssh/id_ecdsa type -1
debug1: identity file /root/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.4
debug1: match: OpenSSH_5.4 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.8
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: Server host key: RSA d6:2b:96:d5:57:24:5c:35:4a:d4:ba:7e:92:48:5d:c3
debug1: Host '[10.0.20.1]:22223' is known and matches the RSA host key.
debug1: Found key in /root/.ssh/known_hosts:1
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,password
debug1: Next authentication method: publickey
debug1: Trying private key: /root/.ssh/id_rsa
debug1: Trying private key: /root/.ssh/id_dsa
debug1: Trying private key: /root/.ssh/id_ecdsa
debug1: Next authentication method: password

Die configurationen habe ich alle so angepasst wie oben beschrieben aber es wird einfach immer gefragt nach dem passwort.
Wenn ich dann zwischenzeitlich den wechsel zum manuellen passwort herausnehme dann kommt nur noch dieses am ende

debug1: No more authentication methods to try.
Permission denied (publickey).

[Joe User]

Funktioniert es denn mit dem "echten" root?

BTW: root einen Alias zu verpassen bringt keinerlei zusätzliche Sicherheit und birgt dafür jede Menge Stolperfallen wie diese hier. Sinnvoller ist ein regulärer Admin-Account und dann bei Bedarf per su zum root wechseln.

[mcfly]

nein mit dem normalen root und einem normalen user klappt das ganze auch nicht. Es erscheint immer die obrige fehlermeldung.

[Joe User]

Hast Du die SSH-Schlüsselpaare auch richtig erzeugt und den private Key zum Verbindungsaufbau genutzt?

[mcfly]

wieso den private key zum verbindungsaufbau? ich dachte ich kann nun einfach mit ssh user@10.0.20.1 -pPORT die verbindung erstellen. Oder verstehe ich da nun etwas falsch?

[daemotron]

Bitte prüfe auf dem Server noch mal folgendes:

• Das .ssh Verzeichnis muss dem zugehörigen User "gehören" (ggf. mit chown korrigieren)
• Das .ssh Verzeichnis darf nur für den jeweiligen User zugreifbar sein, ggf. mit chmod 0700 die Berechtigung korrigieren
• Die Datei .ssh/authorized_keys muss ebenfalls dem User gehören und sollte die Berechtigung 0600 haben

Auf Client-Seite kannst Du die zu verwendende Schlüsseldatei explizit angeben:

Code: Select all

ssh -l <user> -i ~/.ssh/id_rsa -p 22223 <host>

Wenn es damit nicht geht, poste doch bitte noch einmal folgende Informationen

• Inhalt des lokalen .ssh Verzeichnis
• Inhalte des remote .ssh Verzeichnis
• Die Ausgabe von sed '/^[[:space:]]*\([#;].*\)*$/d' /etc/ssh/sshd_config (auf dem Server)
• Den relevanten Auszug aus /var/log/auth.log (Server-seitig)