SSH ohne Passwort funktioniert nicht

... naja, was man(n) macht oder nicht sei dahin gestellt ;)
Fakt ist, dass ich bereits alles unternommen habe, aber ich trotzdem nach dem Passwort gefragt werde :/
 
Du hast bestimmt nur nen kleinen Fehler drin.

Also nochmal alles durch.
1) Keys erstellt?
2) Identfile im ssh Verzeichnis beim User (HOSTDERCONNECTED)?
3) Publickey auf dem zugreifenden Server in das Authorized file gesetzt?
4) Wirklich eine Zeile ohne Umbruch Pro Eintrag?? Ist Wichtig?
5) Getestet via ssh user@HOSTZUMCONNECTEN?

@h75: Der ist dazu da um besondere Rechte zu haben. Die bekommste dann mit su oder sudo... Aber das ist wieder viel zu weit Off-Topic... deshalb wieder zurück zum Thema.
 
Nach einer frischen Generierung usw. sagt es mir bei eingabe von "ssh xx.xx.xx.xx.xx" (oder auch ... backup@xx.xx.xx.xx.xx)

The authenticity of host 'xx.xx.xx.xx (xx.xx.xx.xx.xx)' can't be established.
RSA key fingerprint is 5c:b9:56:92:e3:a5:5f:7d:d0:3f:db:b7:5a:5e:fa:73.
Are you sure you want to continue connecting (yes/no)? yes

-> yes

eingegeben und dann kommen lauter y:

y
y
y
y
y
y
y
y
...

Nur per Control+c abzubrechen.

Das ganze nun wiederholt, kommt nach dem yes:


Enter passphrase for key '/home/backup/.ssh/id_dsa':

klar

und dann:

Password:

nicht klar :/
 
Last edited by a moderator:
Erstell mal neue Keys so;
ssh-keygen -t dsa

Gib keine Passphrase ein!
Kopiere den Inhalt von id_dsa.pub in das authorized_keys file auf dem zu konnekteten Server.. Denke daran das kein Umbruch vorhanden sein darf

Beim Connecten musst du den User eingeben also user@xxxx sonst Versucht er es mit dem User bei dem du auf der anderen Kiste eingeloggt bist.
 
Last edited by a moderator:
... Your identification has been saved in /home/backup/.ssh/id_dsa.
Your public key has been saved in /home/backup/.ssh/id_dsa.pub.
The key fingerprint is:
bla bla

Der Schriit geht!
 
... nun den .pub Inhalt in die authorized_keys-Datei auf dem anderen Server unter .ssh des Homeverzeiochnisses kopiert. Ohne Zeilenumbruch
 
Mögliches Problem gefunden: Auf dem anderen Rechner zeigt er mir bei:

Last login: Tue Aug 16 16:48:07 2005 from XXX

unter XXX einen Namen an, den ich bei meinen ersten Versuchen in einer config-Datei angeben hatte. Die existiert aber schon lange nicht mehr und seitdem habe ich mich schon ein paarmal ohne diese datei eingeloggt.
 
Probiere mal meine sshd_config. Also bei mir gehts

Code: 
#	   $OpenBSD: sshd_config,v 1.65 2003/08/28 12:54:34 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 22
#Protocol 2,1
Protocol 2
#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 2m
#PermitRootLogin yes
#StrictModes yes

#RSAAuthentication yes
#PubkeyAuthentication yes
#AuthorizedKeysFile	 .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

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCreds yes

# Set this to 'yes' to enable PAM authentication (via challenge-response)
# and session processing. Depending on your PAM configuration, this may
# bypass the setting of 'PasswordAuthentication'
UsePAM yes

#AllowTcpForwarding yes
#GatewayPorts no
X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes
#PrintMotd yes
#PrintLastLog yes
#KeepAlive yes
#UseLogin no
UsePrivilegeSeparation no
#PermitUserEnvironment no
#Compression yes
#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/lib/ssh/sftp-server
 
... the same procedure as ...

Aber - hier meine ssh_config - evt. liegt es an ihr:

# $OpenBSD: ssh_config,v 1.19 2003/08/13 08:46:31 markus Exp $

# This is the ssh client system-wide configuration file. See
# ssh_config(5) for more information. This file provides defaults for
# users, and the values can be changed in per-user configuration files
# or on the command line.

# Configuration data is parsed as follows:
# 1. command line options
# 2. user-specific file
# 3. system-wide file
# Any configuration value is only changed the first time it is set.
# Thus, host-specific definitions should be at the beginning of the
# configuration file, and defaults at the end.

# Site-wide defaults for various options

Host *
# ForwardAgent no
# ForwardX11 no

# If you do not trust your remote host (or its administrator), you
# should not forward X11 connections to your local X11-display for
# security reasons: Someone stealing the authentification data on the
# remote side (the "spoofed" X-server by the remote sshd) can read your
# keystrokes as you type, just like any other X11 client could do.
# Set this to "no" here for global effect or in your own ~/.ssh/config
# file if you want to have the remote X11 authentification data to
# expire after two minutes after remote login.
ForwardX11Trusted yes

# RhostsRSAAuthentication no
# RSAAuthentication yes
# PasswordAuthentication yes
# HostbasedAuthentication no
# BatchMode no
# CheckHostIP yes
# AddressFamily any
# ConnectTimeout 0
# StrictHostKeyChecking ask
# IdentityFile ~/.ssh/identity
# IdentityFile ~/.ssh/id_rsa
# IdentityFile ~/.ssh/id_dsa
# Port 22
# Protocol 2,1
# Cipher 3des
# Ciphers aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc
# EscapeChar ~
# GSSAPIAuthentication no
# GSSAPIDelegateCredentials no

# 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
 
... habe ich gemacht ;)

Evt. liegt es an "BatchMode=no". Manuell mal -o BatchMode=yes versucht - Ergebnis: Permission denied. OK. Jetzt schalte ich den BatchMode=yes im ssh-config File ein. Sekunde ... nix. Als ob die Änderung ihn nicht interessieren würde ...
 
Last edited by a moderator:
... Fehler nun gefunden: Ein Bekannter hat sich die Sache noch einmal angeschaut. Lag irgendwie an der sshdconfig und Verzeichnisrechten :/
 
Ich hatte auch schonmal so ein Problem,
check mal ob du dich mit den richtigen User am zum anderen Server verbindest:

ssh username@serverhost.com

Ich hab da oft den falschen Benutzer angegeben, das war mein Problem.
Zur Info: Der Key muss in ./ssh/authorized_keys des jeweiligen Users eingespielt werden der sich verbinden darf/soll

Vielleicht hilfts?

lg franzi
 
You must log in or register to reply here.
Back
Top