# [OT] SSH Passwortloser Login

## manuels

Hallo,

ich will mich von jedem beliebigen Rechner aus auf einem Rechner im Rechenzentrum unserer Uni anmelden.

Ich hab schon versucht, das Passwort über eine Pipe aus einer Datei auszulesen und diese in SSH umzuleiten, funktioniert aber nicht.

Danach kam ich auch die Idee es mit diesen id_dsa*-File zu versuchen. Das funktioniert aber auch nicht, da ich vom System von dem ich mich einloggen will keine statische IP-Adresse habe, geschweige denn eine Domain.

Habt ihr sonst noch eine Idee, wie es laufen könnte?

Tschö

Manuel

----------

## gabelhonz

ssh RSA Key generieren. Keine Passphrase eingeben und auf dem Rechner wo du dich einloggen möchtest unter .ssh/authorized_keys2 den key eintragen.

Dann einfach von jedem Rechner per ssh den Schlüssel mitgeben...fertig.

gruß

----------

## manuels

Moin,

ob ich DSA oder RSA nutze, dürfte doch eigentlich das selbe sein, oder?

Wie gesagt, dabei habe ich doch eine DNS-Überprüfung. Ich habe schon versucht in die .ssh/authorized_keys2 nach dem Fingerprint meinekennung@meinedyndns.domain anzugeben, klappt aber auch nicht.

Tschö mit ö

Manuel

----------

## gabelhonz

hi,

nee nee es spielt keine rolle welche ip der rechner hat. es geht dabei um den "Hostname" nicht die "HostIP"

also user@host, deswegen klappts auch nicht!

müsstest dann halt alle hosts adden von denen du dich einloggen willst, eventuell kann man auch nen asterisk machen. weiss ich aber nicht.

wäre auch ziemlich unsicher.

was mir auch grad eingefallen ist: http://www.gentoo.org/proj/en/keychain/

vielleicht ist das ja was für dich !

bye bye

----------

## manuels

alles komisch,

wenn ich es von einem Rechner aus dem Rechenzentrum auf einen Rechner im Rechenzentrum versuche klappt es auch nicht.

Hier mein Versuch (Home-Dirs auf beiden Rechnern ist identisch (Netzwerk-FS). OS: AIX):

```

# cd ~/.ssh

# ssh-keygen -t rsa 

Generating public/private rsa key pair.

Enter file in which to save the key (~/.ssh/id_rsa): 

~/.ssh/id_rsa already exists.

Overwrite (yes/no)? y

Enter passphrase (empty for no passphrase): 

Enter same passphrase again: 

Your identification has been saved in ~/.ssh/id_rsa.

Your public key has been saved in ~/.ssh/id_rsa.pub.

The key fingerprint is:

FF:FF:FF:FF:MO:DI:FI:ED:FF:FF:FF:FF:FF:FF:FF:FF kennung@client

# cp id_rsa.pub authorized_keys

# cp id_rsa.pub authorized_keys2

# ssh -v server

OpenSSH_3.8.1p1, OpenSSL 0.9.7d 17 Mar 2004

debug1: Reading configuration data /etc/ssh/ssh_config

debug1: Failed dlopen: /usr/krb5/lib/libkrb5.a(libkrb5.a.so): A file or directory in the path name does not exist.

debug1: Error loading Kerberos, disabling Kerberos auth.

debug1: Connecting to server [111.111.111.111] port 22.

debug1: Connection established.

debug1: identity file ~/.ssh/identity type -1

debug1: identity file ~/.ssh/id_rsa type 1

debug1: identity file ~/.ssh/id_dsa type 2

debug1: Remote protocol version 2.0, remote software version 3.2.5 SSH Secure Shell (non-commercial)

debug1: no match: 3.2.5 SSH Secure Shell (non-commercial)

debug1: Enabling compatibility mode for protocol 2.0

debug1: Local version string SSH-2.0-OpenSSH_3.8.1p1

debug1: SSH2_MSG_KEXINIT sent

debug1: SSH2_MSG_KEXINIT received

debug1: kex: server->client aes128-cbc hmac-md5 none

debug1: kex: client->server aes128-cbc hmac-md5 none

debug1: sending SSH2_MSG_KEXDH_INIT

debug1: expecting SSH2_MSG_KEXDH_REPLY

debug1: Host 'fastfix' is known and matches the DSA host key.

debug1: Found key in ~/.ssh/known_hosts:2

debug1: ssh_dss_verify: signature correct

debug1: SSH2_MSG_NEWKEYS sent

debug1: expecting SSH2_MSG_NEWKEYS

debug1: SSH2_MSG_NEWKEYS received

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: ~/.ssh/identity

debug1: Offering public key: ~/.ssh/id_rsa

debug1: Authentications that can continue: publickey,password

debug1: Offering public key: ~/.ssh/id_dsa

debug1: Authentications that can continue: publickey,password

debug1: Next authentication method: password

kennung@server's password: 

```

Was läuft das schief?

Tschö mit ö

Manuel

----------

## amne

id_Xsa.pub muss auf dem Rechner, auf dem du dich einloggen willst ins ~/.ssh/authorized keys während id_Xsa bei dir lokal liegen sollte.

----------

## manuels

jo, aber ich habe ein Home-Verzeichnis, das auf beiden Rechnern das selbe ist. Das ganze ist so in etwa NFS mäßig, heisst hier aber DFS.

----------

## SinoTech

 *manuels wrote:*   

> jo, aber ich habe ein Home-Verzeichnis, das auf beiden Rechnern das selbe ist. Das ganze ist so in etwa NFS mäßig, heisst hier aber DFS.

 

Hast du dort die ".pub" file nur in das ".ssh" Verzeichniss kopiert (falsch), oder hast du deinen öffentlichen Schlüssel in die Datei "~.ssh/authorized_keys" eingetragen (richtig)?

```

$ cat filename.pub >> ~/.ssh/authorized_keys

```

Der private Schlüssel liegt dann in deinem Homeverzeichniss unter ".ssh" (Also jeder private Schlüssel in einer extra Datei).

Solltest du nicht den Standartdateinamen benutzen (Also beim generieren des Schlüssels einen extra Dateinamen angeben), dann musst beim connecten per ssh den Dateinamen angeben.

Mfg

Sino

----------

## manuels

 *SinoTech wrote:*   

> Hast du dort die ".pub" file nur in das ".ssh" Verzeichniss kopiert (falsch)
> 
> 

 

nee

 *SinoTech wrote:*   

> 
> 
> oder hast du deinen öffentlichen Schlüssel in die Datei "~.ssh/authorized_keys" eingetragen (richtig)?
> 
> 

 

jo. nur nicht 

```

$ cat filename.pub >> ~/.ssh/authorized_keys

```

sondern

```

$ cp filename.pub ~/.ssh/authorized_keys

```

 *SinoTech wrote:*   

> Der private Schlüssel liegt dann in deinem Homeverzeichniss unter ".ssh" (Also jeder private Schlüssel in einer extra Datei).
> 
> Solltest du nicht den Standartdateinamen benutzen (Also beim generieren des Schlüssels einen extra Dateinamen angeben), dann musst beim connecten per ssh den Dateinamen angeben.
> 
> 

 

jo, hab ich als Standarddateinamen (id_rsa).

Gibt es sonst noch Fehlerquellen?

----------

## SinoTech

 *manuels wrote:*   

> 
> 
> [...]
> 
> jo. nur nicht 
> ...

 

Das macht nichts. Die "cat" Methode solltest du nur machen wenn du mehrere Schlüssel hast (Also wenn du von mehreren Rechnern auf den Sever zugreifen willst. Denn in der Regel sollte man für jeden einen eigenen Schlüssel verwenden). Bei deiner "cp" Methode würde der bereits enthaltene Schlüssel überschrieben werden.

 *manuels wrote:*   

> 
> 
> [...]
> 
> Gibt es sonst noch Fehlerquellen?

 

Das ".ssh" Verzeichniss (In deinem Home) darf nur von deinem Benutzer zugreifbar sein (Also leserecht etc. für alle anderen entfern).

Mfg

Sino

----------

## manuels

 *SinoTech wrote:*   

> 
> 
> Das ".ssh" Verzeichniss (In deinem Home) darf nur von deinem Benutzer zugreifbar sein (Also leserecht etc. für alle anderen entfern).
> 
> 

 

Das hab ich geprüft. Es sind nur rw für mich gesetzt. Gruppe & Others haben keine Rechte...   :Crying or Very sad: 

----------

## Fibbs

Bei manchen Distributionen muss auch das File authorized_keys die Rechte 400 aufweisen, das Verzeichnis .ssh 600.

Wenn das immer noch nicht klappen sollte, ist die Pubkey-Authentifizierung evtl. am Server abgeschalten, musst Du in der /etc/ssh/sshd_config des Servers nachsehen.

Viel Erfolg

Fibbs

----------

## manuels

 *Fibbs wrote:*   

> Bei manchen Distributionen muss auch das File authorized_keys die Rechte 400 aufweisen, das Verzeichnis .ssh 600.
> 
> 

 

das läuft leider auch nicht

 *Quote:*   

> 
> 
> Wenn das immer noch nicht klappen sollte, ist die Pubkey-Authentifizierung evtl. am Server abgeschalten, musst Du in der /etc/ssh/sshd_config des Servers nachsehen.

 

Aber dann würde mir ssh doch nicht

```
Authentications that can continue: publickey,password 
```

melden, oder?

naja, in der sshd2_config steht nur:

```

AllowHosts ....

subsystem-sftp sftp-server

SettableEnvironmentVars ...

```

So ein blödes Protokoll...  :Sad: 

----------

## amne

Handelt es sich bei irgendeinem der beteiligten Rechner um einen Gentoo Rechner?

----------

## tuam

 *manuels wrote:*   

> [code]
> 
> # ssh -v server

 

Hast Du mal versucht, ihm mit Parametern beizubringen, welchen User und welche Datei für den private key zu verwenden sind? Du kannst auch noch ein paar v's anhängen für noch mehr Verbosität.

FF,

 Daniel

----------

## manuels

amne:

nee, ist wohl eher mal offtopic. Kannst du den thread ins diskussionsforum verschieben?

mit mehr -v's krieg ich auch keine fehlermeldung...   :Sad: 

----------

## amne

Eben, drum hab ich gefragt.  :Wink: 

Verschoben.

----------

## think4urs11

mal so ins Blaue getippt würde ich sagen du mußt deinen Publickey erstmal in das Format (secsh) umwandeln das der SSH-Server auch verdauen kann.

Der unfreie SSH-Server von ssh.com  *manuels wrote:*   

> 
> 
> ```
> debug1: Remote protocol version 2.0, remote software version 3.2.5 SSH Secure Shell (non-commercial)
> ```
> ...

 kann mit openssh-keys nämlich erstmal nix anfangen.

----------

## manuels

nun sagt er sowas wie:

```

PEM_read_PrivateKey failed

read PEM private key done: type <unknown>

```

und fragt mich nach nem passwort für dieses PublicKeyFile. Ich habe aber garkeinen gesetzt.

also drück ich nur enter und er sagt: "nagut, kein passwort angegeben, dann gib dein 'normales' passwort ein"

grrrr...

----------

## manuels

mir ist gerade noch ein gedanke gekommen.

ich habe das folgende problem:

ich komme an server A nicht direkt über ssh dran. also will ich über Server B mich per ssh verbinden und von da aus auf server A.

Ich will das Dateisystem von Server A mit shfs mounten. Dies klappt aber mit shfs nicht, wenn man sich über server B erst verbinden muss.

habe ich mir gedacht: mit diesen id_?sa files müsste es klappen, wenn ich shfs als ssh kommando 

```
ssh serverB 'ssh serverA'
```

 angebe.

wie es aussieht kappt das ja wohl nicht.

wenn ich das ohne id_?sa files machen würde, sollte mich der ssh prozess auf server B (welcher zu server A verbindet) nach einem Passwort für den Server A fragen.

macht er aber nicht. ich bekomm einfach nur die aussage

```
Pseudo-terminal will not be allocated because stdin is not a terminal
```

kann ich denn irgendwie das stdin terminal auf server B so umbiegen, dass ich da daten rein schreiben kann?

(hoffe, das war einigermaßen verständlich)

----------

