OpenSSH 4.2 Zugriff unterschiedlicher Benutzer mit PublicKey

[Just Matt]

Hallo zusammen,

auf meinem Server läuft OpenSSH mit PublicKey-Authentifizierung. In der sshd_config habe ich PermitRootLogin auf "no" gesetzt, und als Benutzer meinen Account "matthias".

Jetzt soll ein neuer Account dazukommen. Also habe ich in der Zeile AllowUsers den Account "peter" durch einen Leerschritt getrennt dazugefügt. Der AuthorizedKeysFile /home/matthias/.ssh/authorized_keys wurde um den öffentlichen Schlüssel ergänzt (nachdem %H/.ssh/authorized_keys mit der entsprechenden Datei im /home/peter/.ssh/ auch keinen Erfolg hatte). Aber unter dem neuen Benutzer klappt die Anmeldung nicht: "Permission denied". Diverse Stunden und etliche rcsshd-Starts später funktioniert es nicht.

Hat von Euch jemand noch einen Tipp?


Die sshd_config sieht bei mir folgendermaßen aus:

# $OpenBSD: sshd_config,v 1.72 2005/07/25 11:59:40 markus Exp $

# This is the sshd server system-wide configuration file. See
# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented. Uncommented options change a
# default value.

Port 2247
Protocol 2
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::

# HostKey for protocol version 1
#HostKey /etc/ssh/ssh_host_key
# HostKeys for protocol version 2
#HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key

# Lifetime and size of ephemeral version 1 server key
#KeyRegenerationInterval 1h
#ServerKeyBits 768

# Logging
# obsoletes QuietMode and FascistLogging
SyslogFacility AUTH
LogLevel INFO

# Authentication:

LoginGraceTime 1M
PermitRootLogin no
AllowUsers matthias peter
StrictModes yes

#MaxAuthTries 6

RSAAuthentication no
PubkeyAuthentication yes
AuthorizedKeysFile /home/matthias/.ssh/authorized_keys

# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# RhostsRSAAuthentication and HostbasedAuthentication
IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes

# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication no
PermitEmptyPasswords no

# Change to no to disable s/key passwords
ChallengeResponseAuthentication yes

# Kerberos options
KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

# Set this to 'yes' to enable support for the deprecated 'gssapi' authentication
# mechanism to OpenSSH 3.8p1. The newer 'gssapi-with-mic' mechanism is included
# in this release. The use of 'gssapi' is deprecated due to the presence of
# potential man-in-the-middle attacks, which 'gssapi-with-mic' is not susceptible to.
#GSSAPIEnableMITMAttack no

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication mechanism.
# Depending on your PAM configuration, this may bypass the setting of
# PasswordAuthentication, PermitEmptyPasswords, and
# "PermitRootLogin without-password". If you just want the PAM account and
# session checks to run without PAM authentication, then enable this but set
# ChallengeResponseAuthentication=no
UsePAM no

#AllowTcpForwarding yes
#GatewayPorts no
X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes
PrintMotd no
#PrintLastLog yes
TCPKeepAlive yes
#UseLogin no
UsePrivilegeSeparation yes
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS yes
#PidFile /var/run/sshd.pid
#MaxStartups 10

# no default banner path
#Banner /some/path

# override default of no subsystems
Subsystem sftp /usr/lib64/ssh/sftp-server

# This enables accepting locale enviroment variables LC_* LANG, see sshd_config(5).

AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
AcceptEnv LC_IDENTIFICATION LC_ALL

Viele Grüße

Matthias

 

[HeadCrash]

Morgen,

hast du einmal versucht die Usernamen mit einem Komma zu trennen.
Hier widerspricht sich man sshd_conf und man ssh_conf.

sshd_conf (getrennt durch Leerzeichen) und für mehr infos was Muster angeht ssh_conf anschaun.
In der ssh_conf steht, dass solche Listen durch Kommas getrennt sind.

Wie siehts alternativ mit dem Einsatz von AllowGroup aus?
Rechte der authorized_keys und des keyfiles stimmen auch?
Der zweite User hat ne gültige shell in /etc/passwd eingetragen?

 

[Just Matt]

Nabend,

hast du einmal versucht die Usernamen mit einem Komma zu trennen.
Hier widerspricht sich man sshd_conf und man ssh_conf.

Ja, das hab ich gleich ausprobiert. Leider hat das nichts an dem Zugangs-Problem geändert.

Wie siehts alternativ mit dem Einsatz von AllowGroup aus?

Dafür muß man doch bestimmt den privaten Schlüssel nebst Passwort an die Gruppenmitglieder verteilen?! Wenn AllowUser nicht funktioniert wäre das dann die letzte Variante.

Rechte der authorized_keys und des keyfiles stimmen auch?

Beide Dateien stehen auf 600.

Der zweite User hat ne gültige shell in /etc/passwd eingetragen?

Jupp, habe ich gecheckt: Testhalber Login via SSH-Verbindung und dem regulären System-Passwort funktioniert aller erste Sahne.

Ein Unterschied ist mir heute noch aufgefallen: Wenn ich mich von meinem separaten Laptop mittels SSH auf dem Server einlogge, dann erscheinen da Hinweise bezgl. des Fingerprints und ob ich mich wirklich verbinden möchte (Are you sure youwant to continue connecting?...). Bei meinem Hauptrechner kommen solche Meldungen überhaupt nicht. Stattdessen kommt der gleich zur Sache "Enter passphrase...". Vielleicht liegt da der Hund begraben?

 

[Gast1]

Ein Unterschied ist mir heute noch aufgefallen: Wenn ich mich von meinem separaten Laptop mittels SSH auf dem Server einlogge, dann erscheinen da Hinweise bezgl. des Fingerprints und ob ich mich wirklich verbinden möchte (Are you sure youwant to continue connecting?...). Bei meinem Hauptrechner kommen solche Meldungen überhaupt nicht. Stattdessen kommt der gleich zur Sache "Enter passphrase...". Vielleicht liegt da der Hund begraben?

Nein, mit an Sicherheit grenzender Wahrscheinlichkeit nicht.

Führe doch mal spasseshalber vom Laptop das selbe noch mal aus, die Meldung ist zu > 99% "verschwunden" (sofern die Kiste unter Linux läuft und man einmal die genannte Frage mit Ja beantwortet hat).

//Edit:

So in etwa

 ssh localhost -pZZZZZ
The authenticity of host '[localhost]:ZZZZ ([127.0.0.1]:ZZZZZZ)' can't be established.
RSA key fingerprint is AA:BB:CC:DD:EE:FF:11:22:
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '[localhost]:ZZZZZ' (RSA) to the list of known hosts.
Enter passphrase for key '/home/XXXX/.ssh/id_rsa': 
Last login: Sat May 23 05:24:15 2009 from console
Have a lot of fun...

XXXX@YYYY:~> exit
logout
Connection to localhost closed.

Und jetzt das Ganze noch mal:

ssh localhost -pZZZZZZ
Enter passphrase for key '/home/XXXX/.ssh/id_rsa': 
Last login: Sat May 23 11:47:46 2009 from localhost
Have a lot of fun...

 

[HeadCrash]

Erzählen die Logfiles irgendwas?

Werd die Konfig jetzt mal zum Spaß hier einmal einspielen.

===EDIT===

hat bei mir wunderbar funktioniert.
Habe nur die Konfiguration für die Keyfiles und die AllowedUser geändert.

AuthorizedKeysFile /%h/.ssh/authorized_keys

 

[Just Matt]

Nein, mit an Sicherheit grenzender Wahrscheinlichkeit nicht.

Führe doch mal spasseshalber vom Laptop das selbe noch mal aus, die Meldung ist zu > 99% "verschwunden" (sofern die Kiste unter Linux läuft und man einmal die genannte Frage mit Ja beantwortet hat).

Jo, hat sich gerade aufgeklärt. Habe die Berechtigungen falsch gesetzt. Somit konnte OpenSSH nicht in das Verzeichnis schreiben. War aber generell einiges aufzuräumen: Die Zugriffsrechte von ~/.ssh/config habe ich abgeändert, so dass nur der Besitzer Lese- und Schreibrechte hat, alle anderen wird der Zugriff jetzt vollständig verwehrt.

Kurzum jetzt konnte auch die known_hosts geschrieben werden und ja Du hast Recht, es gibt jetzt nur noch die Rückfrage wegen dem Passwort und zack bin ich drauf
.
.
.
EDIT (autom. Beitragszusammenführung) :
.

Erzählen die Logfiles irgendwas?

Die SSH-Einträge in den Logfiles auf dem Server sind leider nicht sehr umfangreich. Erfolgreiche SSH-Anmeldungen lassen sich nachvollziehen. Genauso wenn derjenige zum Superuser gewechselt ist (su). Weitere Einträge konnte ich nicht finden.

Habe nur die Konfiguration für die Keyfiles und die AllowedUser geändert.

Nach meinen CHMOD, CHOWN und CHGRP-Änderungen habe ich die Server-Config auch noch mal auf %h geändert. Anschließend ein beherztes Löschen aller Dateien im .ssh-Verzeichnis des Clients und dann auf ein Neues.

Jetzt funktioniert's

Vermutlich liegt's an der Kombination aus dem %h bei AuthorizedKeysFile und der dadurch konsequenten Trennung per Benutzer. Find ich auch die elegantere (Wunsch-) Lösung, denn sollte der Benutzer hinfällig werden, brauche ich nur sein Home-Verzeichnis zu löschen und fertig ist der Lack.

Auf jedenfall kann ich meinen privaten Schlüssel jetzt weiterhin für mich allein behalten

Vielen Dank Euch allen für Eure Hilfe!!!