[gelöst] SSH Kein Zugriff: ssh - ~/.ssh/authorized_keys

[xeroxed_yeti]

Hallo zusammen,

ich hoffe, dass ich die Frage in der richtigen Rubrik stelle. Es geht um den Befehl SSH.

Das Szenario:

- Server: SLE11 (sshd läuft)
- Client: Ubunutu (ssh vorhanden)
- id_rsa.pub erzeugt mit dem Befehl: "ssh-keygen -b 2048 -t rsa"
- scp ~/.ssh/id_rsa.pub root@server:~/.ssh/authorized_keys
- scp ~/.ssh/id_rsa.pub user@server:~/.ssh/authorized_keys

Das Problem:

- Logge ich mich nun per "ssh root@server" auf dem Server an bin ich direkt mit dem Server verbunden
- Logge ich mich nun per "ssh user@server" auf dem Server an erscheint die Passwortabfrage. (einloggen klappt mit Passwort)

Die Frage:

- Warum klappt der "root" Zugang ohne, aber der "user" Zugang ohne Passwort nicht?
- Liegt es daran, dass ich für beide (root, user) die gleich authorized_keys file habe? (diese file liegt in beiden home directorys unter /.ssh/ vor. Auch sind die Rechte richtig gesetzt)
- Kann es daran liegen, dass ich mich zuerst mit dem root eingelogt habe, SLE11 sich meinen lokalen User gemerkt hat und ihm immer root zuordenet
- Kann es daran liegen, dass man für einen User lokal nur einen Userprofil mit ssh anspricht?

Danke für eure Hilfe!

 

[framp]

Ich würde mal mit beiden Usern eine ssh Session aufbauen und dabei den verbose mode anschalten und die Ausgaben vergleichen. Also mal

ssh -v root@server
ssh -v user@server

(Siehe auch ssh troubleshooting an faq)

Danach bringt der verbose mode des ssh Daemons vielleicht auch was an weiterer Info.

 

[/dev/null]

Hi xeroxed_yeti,

hast du unter beiden Nutzern ein eigenes Schlüsselpaar erzeugt?
Damit müsste jetzt bei beiden Nutzern in ~/.ssh dieses Schlüsselpaar liegen. OK? (Zumindest muss für das Login der secret key dort vorhanden sein.)
Hast du überprüft, ob in der authorized_keys auf dem Server wirklich beide public keys eingetragen sind? (Ja, du kast kopiert, aber trotzdem ... .)
(Tipp: gleich nach der Erstellung der Schlüssel alle editieren und am Ende <Benutzer>@<Maschine>_<Datum> einfügen. Das schafft Übersicht ... .)

Wenn bei beiden Nutzern (Client) der secret key vorliegt und bei beiden Nutzern (Server) auch in der authorized_keys beide public keys enthalten sind, müsste es eigentlich funktionieren.

Trotzdem:
Du solltest die Regel einhalten, dass root keine ssh-Verbindung aufbauen darf.
Anmelden als user und dann "su -". Soviel Zeit sollte sein.
Und wenn sich user dann per key anmelden kann, solltest du die Anmeldung per Benutzername/Passwort deaktivieren.

MfG Peter

 

[xeroxed_yeti]

Danke für eure Hilfe!

Ich kann erst morgen die von euch vorgeschlagenen problemlösungen versuchen. für heute habe ich dem büro den rücken gekehrt.

an den verbose mode hätte ich natürlich auch mal denken sollen

das mit dem authorized_keys für den root login sollte aich nur temporär sein,peter setze die kiste ebem auf und permanent in zig konsolen das password einzutippern ist bei meinen passwd schon fleißarbeit =)

melde mich morgen von der "front"

 

[spoensche]

Einen Public Key überträgt man mit

ssh-copy-id user@host

 

[xeroxed_yeti]

Guten Morgen zusammen,

habe das ganze nun noch einmal durchgespielt. Aber noch immer ohne Erfolg.

Ich habe nun einen id_rsa.pub für meinen lokalen user erzeugen lassen und diesen mit auf den Server kopiert.

ssh-keygen -b 2048 -t rsa
ssh-copy-id root@server
ssh-copy-id user@server

Der root login klappt ohne Passwortabfrage, der user login nicht.

Der Verbose liefert folgendes für das einloggen mittels root (kein passwort wird benötigt):

debug1: Server host key:
debug1: Host ... is known and matches the RSA host key.
debug1: Found key in /home/tarzan/.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,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/tarzan/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 279
debug1: Authentication succeeded (publickey).
Authenticated to ... ([...]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
Last login: Thu Aug 25 08:10:56 2011 from ...

Für den user (Passwort abfrage):

debug1: Host '...' is known and matches the RSA host key.
debug1: Found key in /home/tarzan/.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,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/tarzan/.ssh/id_rsa
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Trying private key: /home/tarzan/.ssh/id_dsa
debug1: Trying private key: /home/tarzan/.ssh/id_ecdsa
debug1: Next authentication method: keyboard-interactive
Password:

Dem Anschein nach akzeptiert der Server nicht den public key "/home/tarzan/.ssh/id_rsa". Liegt es an evtl. daran, dass es nicht möglich ist mit einem lokalen user sich als zwei user auf einem ssh Server auszugeben?

 

[xeroxed_yeti]

Hmm ok ...

keine Ahnung was da passiert war.

Die Lösung meines Problem war wie folgt:

Habe den User auf dem Server gelöscht. Das Home Verzeichnis beibehalten und nichts verändert. Den gleichen User erneut angelegt und ihm dem alten Home Verzeichnis zugewissen.

...promt ging das Login ohne Passwort---



Danke für eure Hilfe.


BTW:

ssh -vvv user@server

ist auch sehr nett zum debuggen!

 

[framp]

War sicherlich was mit Zugriffsrechten. Deshalb ist

ssh-copy-id user@host

auch zu empfehlen.

ssh -vvv user@server

ist auch sehr zu empfehlen

Sicherlich kannst Du die Verbosity durch repeat des v erhöhen. I.d.R. reicht aber -v oder -vv. Wird sonst einfach zu viel an Info. Aber anyhow ist dieses immer ein hilfreicher Ansatz bei Problem mit ssh.