SSH, SSH2 .... wo speichert ihr die Keys?

[Gulliver03]

Ich setze mich gerade mit SSH bzw. SSH2 auseinander und stoße auf verschiedene Angaben bzgl. des Speicherorts der Schlüssel (Public Key für die Authentifikation).

Teils liest man der Ordner ".ssh2" soll im Home eines jeden Users angelegt werden, andere Stellen sagen man solle es unter "/" anlegen ........

Wo habt ihr denn eure Schlüssel so abgelegt?

Danke für ein paar Tips.

[KBDCALLS]

Brrauchst du dich normalerweise garnicht drum kümmern. Wenn ein User ein Schlüssel gerneriert landet der in .ssh im Homeverzeichnis. Serverschlüssel die bei der Installation generiert werden landen ind /etc/ssh. Ist aber abhängig von der Software. Für ssh1 und ssh2 sind die Namen durchaus anders.

[Gulliver03]

Das bedeutet aber, dass der Schlüssel vom User auf dem Server generiert werden muss, dann würde das .ssh oder .ssh2 Verzeichnis automatisch angelegt .... wenn der Schlüssel aber auf einem Client erstellt wird, dann muss das Verzeichnis irgendwo "händisch" auf dem Server erstellt werden, denn auch der Pub-Key muss dann dorthin kopiert werden.

Stimmt das, was ich da sage?

[QT]

Um den public Key auf einen Server zu kopieren, gibt es das ssh-copy-id Kommando:

Code: Alles auswählen

$ ssh-copy-id
Usage: /usr/bin/ssh-copy-id [-i [identity_file]] [user@]machine

[mistersixt]

@Gulliver03:

Ganz unrecht hast Du nicht, das ssh2 von http://www.ssh.com (ich gehe jetzt mal davon aus, dass Du das mit "ssh2" meinst) verhält sich teilweise anders als OpenSSH. Du solltest vielleicht nur auf OpenSSH setzen und da Dein Ding durchziehen - ich bin da bei der Benutzung von beidem teilweise in grosse Probleme geschliddert ...

Gruss, mistersixt.

[Gulliver03]

@Gulliver03:

Ganz unrecht hast Du nicht, das ssh2 von http://www.ssh.com (ich gehe jetzt mal davon aus, dass Du das mit "ssh2" meinst) verhält sich teilweise anders als OpenSSH. Du solltest vielleicht nur auf OpenSSH setzen und da Dein Ding durchziehen - ich bin da bei der Benutzung von beidem teilweise in grosse Probleme geschliddert ...

Gruss, mistersixt.

Selbst wenn ich OpenSSH nehme, dann ist die Generierung der Keys server-seitig durchzuführen, denn dann ist sichergestellt, dass die Keys sofort ins Home gespeichert werden. Sage ich jetzt mal so!

[KBDCALLS]

Wenn du als User ein Key generiest landen die im jeweiligen Home an der richtigen Stelle. Egal ob jetzt Openssh SSH1 oder SSH2.

[Gulliver03]

Wenn du als User ein Key generiest landen die im jeweiligen Home an der richtigen Stelle. Egal ob jetzt Openssh SSH1 oder SSH2.

Der Ordner SSH ist jetzt erstellt, die Keys ebenfalls ... jetzt wollte ich die Dinger vom Client rüberkopieren und habe das "fsftp" verwendet, was auch bis zum Punkt "put user.pub" gut funktioniert hat. Dann kam aber der Hinweis, dass ich keinen Zugriff auf /home/user/.ssh habe ......

Hier mal der Auszug aus dem Ablauf:

Code: Alles auswählen

psftp> cd .ssh
Remote directory is now /home/user/.ssh
psftp> lcd keys
New local directory is I:\Putty\keys
psftp> put user.pub
/home/user/.ssh/user.pub: permission denied
psftp> exit

Was sollte ich denn jetzt für Zugriffsrechte setzen, damit User auf .SSH Zugriff hat und den Key kopieren kann ...... chmod ??????

Über "ls" im /home/user habe ich mal geschaut, was .SSH für Rechte hat

drwxr-xr-x 18 user users 4096 Jan 16 13:11 .
drwxrwsr-x 8 root staff 4096 Dec 28 16:29 ..
-rw------- 1 user users 383 Jan 16 13:54 .bash_history
drwxrwx--- 2 user users 4096 Jan 4 21:46 .java
drwx------ 2 user users 4096 Jan 16 13:34 .ssh

Wenn ich es richtig vestehe, dann hat User zwar RWX-Rechte für die Datei, aber der Gruppe, der User angehört fehlen diese, oder? ...... ist das normal, dass wenn ich dann als User in dieses Verzeichnis kopieren möchte, die fehlende Berechtigung für die Gruppe dies verhindert?


Dann habe ich noch eine Frage. Ich habe heute ein bisschen probieren müssen, bis das Ganze so eingerichtet war, dass ich auch kopieren konnte. Das habe ich so oft probiert, dass irgendwann die folgende Meldung kam:

Code: Alles auswählen

I:\Putty>psftp_0-56 user
Using username "user".
Server refused our key
Password:
Access denied
No supported authentication methods left to try!
ssh_init: error during SSH connection setup

Ist da jetzt irgendwas grundsätzlich blockiert, oder macht SSH nach einer Reihe von Fehlversuchen automatisch dicht.

Danke für Hilfe

[mistersixt]

Starte mal den sshd (sshd -d -d) und ssh (ssh -v -v) mit mehr Geblubber, dann solltest Du (hoffentlich) recht schnell auf die Spur kommen, wo es klemmt (mehr -d oder -v bedeuten höheren Debuglevel).

Gruss, mistersixt.

[KBDCALLS]

Wenn die ssh im Debugmodus läuft , dann läßt sie eine Verbindung zu und beendet sich dann, von selbst. Und läuft nicht im Hintergrund.

[Gulliver03]

Der Fehler lag bei mir (wo auch sonst) .... ich habe einen Satz Keys unter SSH erstellt und nicht ins Putty-Format konvertiert ...... jetzt funktioniert es ..... Webmin kann ich jetzt auch kicken (da ewig langsam), denn jetzt funzt WinSCP und das mit toller Geschwindigkeit.

Danke an Alle!


Jetzt habe ich nur noch eine Frage zur Authentifizierung OHNE Passwort ... das muss ich doch in der /etc/ssh/sshd_config regeln, über den Eintrag

Code: Alles auswählen

#disable password authentication
PasswordAuthenticationNO
PAMAuthenticationViaKbInt no

Kann ich diesen Eintrag einfach anlegen, wenn er dort nicht vorhanden ist?

Danke für Info.

[Gulliver03]

Kann es sein, dass die beiden Zeilen unbedingt zusammen genannt werden müssen, sonst funktioniert der passphrase-lose Zugang trotz "PasswordAuthentication No" nicht.

Code: Alles auswählen

#disable password authentication 
PasswordAuthentication no 
PAMAuthenticationViaKbInt no 

Die PAM-zeile muss auch dastehen, oder?

[Gulliver03]

Der passphrase-lose Zugang geht leider nicht. Die Zeile "PAMAuthenticationViaKbdInt no" führt zu einer Fehlermeldung beim Restart von SSH "deprecated option PAMAuthentication".

Worn könnte es liegen, dass die Passphrase trotz Einstellung "PasswordAuthentication no" immer noch abgefragt wird. Der einzige eintrag mit "yes" ist "PubkeyAuthentication yes".

Danke für ein Tipp.

[KBDCALLS]

Code: Alles auswählen

ChallengeResponseAuthentication no 

Muß auch noch rein

[Gulliver03]

Code: Alles auswählen

ChallengeResponseAuthentication no 

Muß auch noch rein

Das ist drin ....

... hier mal die sshd_config

Code: Alles auswählen

# Package generated configuration file
# See the sshd(8) manpage for details

# What ports, IPs and protocols we listen for
Port 22
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes

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

# Logging
SyslogFacility AUTH
LogLevel INFO

# Authentication:
LoginGraceTime 600
PermitRootLogin yes
StrictModes yes

RSAAuthentication no
PubkeyAuthentication yes
#AuthorizedKeysFile	%h/.ssh/authorized_keys

# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes

# For this to work you will also need host keys in /etc/ssh_known_hosts
RhostsRSAAuthentication no

# similar for protocol version 2
HostbasedAuthentication no

# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
#IgnoreUserKnownHosts yes

# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no

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

# Change to yes to enable tunnelled clear text passwords
PasswordAuthentication no


# To change Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#AFSTokenPassing no
#KerberosTicketCleanup no

# Kerberos TGT Passing does only work with the AFS kaserver
#KerberosTgtPassing yes

X11Forwarding no
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
KeepAlive yes
#UseLogin no

#MaxStartups 10:30:60
#Banner /etc/issue.net

Subsystem	sftp	/usr/lib/sftp-server

UsePAM yes

Danke für 'nen Tipp.

[axel1973]

Bist du inzw. damit weiter gekommen?

Du sagst es kommt noch immer die Abfrage der "PAssphrase". Ist das wirklich die PAssphrase welche abgefragt wird oder das User-Passwort?`

Das eine hat mit dem anderen nichts zu tun! es sei denn du hast für beides den gleichen Inhalt gewählt.

Bei entsprechender Konfiguration von SSHD , SSH und den Schlüsseln sollte ein login/Consolen Zugang ohne Benutzername und Passwort (!) möglich sein. ABER...

falls du bei der Schlüsselerzeugung deinen Private-Key mit einer PAssphrase geschützt hast wird immer bei Zugriff auf diesen Schlüssel zur Sicherheit die Passphrase abgefragt. d.h. in dem Fall hättest du ein PAsswort mit einem anderem Passwort ersetzt was glaube ich nicht dein Ziel war.

Hier sollte aber der SSH-Agent abhilfe schaffen. Dieser speichert nach einmaliger eingabe deine passphrase und ermöglicht so den SSH client programmen immer wieder den zugriff auf deinen private key ohne das du immer und immer wieder die passphrase eingeben musst.

teste das mal aus.



Anbei.. ich habe aktuell noch das gleiche Problem wie du es einst mal hattest (glaube ich).
ich möchte eigentlich das gleiche Szenario einrichten wie hier gezeigt. Habe aber ein Problem mit den Schlüsselparen zwischen Debian Sarges SSHD und Putty. Nachdem die Schlüsselpare von PuttyGen nicht funktioniert haben, habe ich es auch nochmal mit ssh-keygen versucht und den public key auf die windows/putty installation kopiert. auch hier erhalten ich noch die info das putty mit dem schlüssel nix anfangen kann.

Du schreibst allerdings das du den schlüssel "nach Putty konvertiert" hast. Wie hast du das gemacht?

MfG
Axel

[Gulliver03]

Ich war immer der Annahme, dass man trotz bei der Schlüsselgenerierung vergebener Passphrase diese bei der Anmeldung umgehen konnte ...... sobald das aber der Fall ist, muss ich sie bei der Anmeldung eingeben und selbst wenn mit Agent gearbeitet wird, braucht dieser die Passphrase um den Key zu laden ........ irgendwie habe ich mit der "erzwungenen" Eingabe der Passphrase auch ein besseres Gefühl, als wenn alles ohne Rückmeldung abläuft.

Jetzt zum Format von SSH, mit Putty originär nichts anfangen kann. Über "Puttygen" kannst Du dir den erstellten Key in ein Format (ausgehend von OpenSSH oder SSH) konvertieren lassen (Menüpunkt "Conversions"), mit dem Putty was anfangen kann; must nur aufpassen dass in den Verzeichnissen dann der richtige Schlüssel im richtigen Format liegt.

Gruß

[KBDCALLS]

Wenn der ssh-agent geladen ist braucht die Passphrase nur einmal und dann nicht mehr. Wenn doch dann iläuft was falsch. Wie startest denn du den ssh-agenten?

[Gulliver03]

Wenn der ssh-agent geladen ist braucht die Passphrase nur einmal und dann nicht mehr. Wenn doch dann iläuft was falsch. Wie startest denn du den ssh-agenten?

Du hast schon Recht! ..... was ich meinte, auch beim Agent muss einmal die Passphrase eingegeben werden ........ dann funzt es ohne Pphrase solange der Agent aktiv ist.

[axel1973]

...Jetzt zum Format von SSH, mit Putty originär nichts anfangen kann. Über "Puttygen" kannst Du dir den erstellten Key in ein Format (ausgehend von OpenSSH oder SSH) konvertieren lassen (Menüpunkt "Conversions"), mit dem Putty was anfangen kann; must nur aufpassen dass in den Verzeichnissen dann der richtige Schlüssel im richtigen Format liegt.
Gruß

Ha! Danke für die Antwort! Wies halt so is hab ich inzw. doch noch rausgefunden wie man den privaten schlüssel konvertieren kann. Hier anbei nochmal die Lösung:

1. schlüsselpar auf der Linux box mit "ssh-keygen -b 1024 -t rsa" erzeugen
2. privaten schlüssel im OpenSSH Format (standard auf Debian Linux) auf die Windows Box kopieren und mit PuttyGen LADEN - hierbei wird der Schlüssel automatisch konvertiert
3. den nun konvertierten privaten schlüssel über den Button "Speichern" im PuttyGen Schlüsselformat wieder auf die Windows Platte speichern und mit Putty verwenden

funktioniert so herum nun sauber!

Danke für eure Hilfe!
MfG
Axel

[Gulliver03]

Genau so habe ich es auch gemacht! .....