SSH ohne Passwort funktioniert nicht

M

mausi

Registered User
Hi!

Jetzt sitze ich seit 3 Tagen an dem Problem:

Ich möchte Nachts per Script Daten von einem Server zum anderen schieben. Das ganze soll u.a. über SSH laufen, allerdings ohne Passphrase und SSH-Agent. Geplant ist dann ein Abgleich per "rsync".

Folgendes habe ich bis jetzt getan (Suse 9.1):

- dsa-Keys generiert (privat/öffentlich)
- Den öffentlichen auf dem anderen Server unter "authorized_keys" gespeichert
- Client & Server sshd_config angepasst (siehe weiter unten)
- sshd "gerestartet"
- per Putty ssh aufgerufen
ZAPP
- der entfernte Server fragt mich nach dem Passwort für der Login
- gebe ich es ein, funktioniert alles bestens

Habe alles bereits probiert, aber nichts hat geholfen (auch stundenlange Google- und Foren-Recherche).

Hat da jemand eine Lösung? Bin langsam total ange... von dieser Sache, aber es muss laufen, da es wichtige Backups sind :/

Gruss,
Eure Mausi
 
Last edited by a moderator:
Nenne mal die Datei authorized_keys in authorized_keys2 um.
Dann wird es eventl. funktionieren.
 
- auch mit -v


OpenSSH_3.8p1, SSH protocols 1.5/2.0, OpenSSL 0.9.7d 17 Mar 2004
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to xx.xx.xx.xx[x.x.x.x] port 22.
debug1: Connection established.
debug1: identity file /home/backup/.ssh/identity type -1
debug1: identity file /home/backup/.ssh/id_rsa type -1
debug1: identity file /home/backup/.ssh/id_dsa type 2
debug1: Remote protocol version 2.0, remote software version OpenSSH_3.8p1
debug1: match: OpenSSH_3.8p1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.8p1
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: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'xx.xx.xx.xx' is known and matches the RSA host key.
debug1: Found key in /home/backup/.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: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,keyboard-interactive,hostbased
debug1: Next authentication method: publickey
debug1: Trying private key: /home/backup/.ssh/identity
debug1: Trying private key: /home/backup/.ssh/id_rsa
debug1: Offering public key: /home/backup/.ssh/id_dsa
debug1: Authentications that can continue: publickey,keyboard-interactive,hostbased
debug1: Next authentication method: keyboard-interactive
 
hier meine ssh_config:

Code: 
#	$OpenBSD: sshd_config,v 1.68 2003/12/29 16:39:50 millert 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
#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:
AllowUsers root backup
#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 yes
# 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 yes
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 (via challenge-response)
# and session processing. Depending on your PAM configuration, this may
# bypass the setting of 'PasswordAuthentication' and 'PermitEmptyPasswords'
UsePAM yes 

#AllowTcpForwarding yes
#GatewayPorts no
X11Forwarding yes 
#X11DisplayOffset 10
#X11UseLocalhost yes
#PrintMotd yes
#PrintLastLog yes
#TCPKeepAlive yes
#UseLogin no
#UsePrivilegeSeparation yes
#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
 
Last edited by a moderator:
Das mit der angewängten Datei kannste dir sparen.
Somit kannst du nie mehr Root werden!!! z.B. wenn man sich mit einem andere User einloggt und per su sich zum root machen will.

Wenn du Root nicht einloggen lassen willst schauste dir leiber mal die SSHd_config genauer an. Das gibts nen Parameter dafür..
 
... dank Dir. Aber da steht leider nur der Weg "Windows-Client" -> "Linux-Server".
Habe den per dieser Anleitung kopierten privaten Key einfach in das .ssh des Userverzeichnisses auf dem Client kopiert und ssh aufgerufen:

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

Nach Eingabe von "yes" kamen ganz viele "y" und liefen so durch. Nach Abbruch und erneutem Versuch kam:

The authenticity of host '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
Warning: Permanently added 'xx.xx.xx.xx' (RSA) to the list of known hosts.
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: UNPROTECTED PRIVATE KEY FILE! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/home/backup/.ssh/id_dsa' are too open.
It is recommended that your private key files are NOT accessible by others.
This private key will be ignored.
bad permissions: ignore key: /home/backup/.ssh/id_dsa

Enter passphrase for key '/home/backup/.ssh/id_dsa': <Return>
ZAPP
Password:

Ok, jetzt bin ich etwas weiter und weiß, dass das System eine Passphrase haben will. Aber wie gebe ich das in der sshd_config an?
 
Noch einmal erläutert: Es sind beides Linux Server (Suse 9.1), also nichts mit Windows Clients usw. ;)
 
... oder könnte ich die Passphrase per "expect" übergeben? Bin ein wenig überarbeitet und wüsste nicht wie ...
 
... mit oder ohne Passphrase: Ich werde anschließend immer nach dem Passwort für den Login gefragt :/
 
Wenn das ganze unter root laufen soll, dann setzt mal in der sshd.config

#PermitRootLogin yes

auf

PermitRootLogin yes
 
Last edited by a moderator:
... jiip. Auch das habe ich gemacht. Habe die ganze Aktion immer mit dem Backup-Account durchgeführt (allein schon wegen der Rechtevergabe).

*snief*
 
society said:
Das mit der angewängten Datei kannste dir sparen.
Somit kannst du nie mehr Root werden!!! z.B. wenn man sich mit einem andere User einloggt und per su sich zum root machen will.
Click to expand...
Klar geht das ;) Man muss es nur wollen. Und wie auch dabei steht, ist das nur für den User 'root' ... den passwort-hash kann man neusetzen, in dem man über passwd als root ein neues Passwort setzt. Oder den gelöschten Hash wieder dort einträgt. Ich arbeite auf allen Servern mit deaktivierten Root-Passwort..
 
You must log in or register to reply here.
Back
Top