Merkwürdiges ssh bzw. scp Problem... [Archiv] - linuxforen.de -- User helfen Usern

Archiv verlassen und diese Seite im Standarddesign anzeigen : Merkwürdiges ssh bzw. scp Problem...

Neutrino_2003

07.01.12, 05:26

Hallo @ll :)

Wollte heute auf meiner Testumgebung ssh mit scp "scharf" machen, um mich näher in ssh und scp einzuarbeiten, doch das stellt sich gentoo anscheinend etwas komplizierter dar, als ichs aus meinen Anfangszeiten mit Ubuntu in Erinnerung glaubte... :/

Ich bin nach Anleitung:

http://de.gentoo-wiki.com/wiki/OpenSSH
sowie
http://www.gentoo.org/doc/de/keychain-guide.xml

vorgegangen...

Der einzige Unterschied besteht darin, das ich mir einen RSA-Schlüsselpaar und kein DSA (wie in der Anleitung) erzeugt habe, da derzeit noch nicht mehr als 1024bit bei DSA und 501bit bei ECDSA möglich ist...

Dennoch: Prinzip des Schlüsselkopierens (key.pub auf Server) ist ja identisch.

So, doch hierzu:

Den Server vorbereiten

Wir werden die Datei ~/.sshid_dsa.pub auf den Server übertragen, auf dem sshd betrieben wird. Wir werden diese Datei weiterhin zur ~/.ssh/authorized_keys Datei hinzufügen, die zu dem verbindenden Benutzer auf diesem Server gehört. Hier ist ein Beispiel, wie dies gemacht wird, wenn Sie bereits ssh-Zugang zum Server haben.

Befehlsauflistung 2.2: Öffentlichen Schlüssel auf den Server kopieren

$ scp ~/.ssh/id_dsa.pub server_user@server:~/myhost.pub
$ ssh server_user@server "cat ~/myhost.pub >> ~/.ssh/authorized_keys"
$ ssh server_user@server "cat ~/.ssh/authorized_keys"

kommt es schon nicht mehr, denn EGAL was ich auch versuche, mache, in der sshd_config unter /etc/ssh/sshd_config - ich bekomme Fehler wie:

Connection refused
Broken pipe
Password:
Password:
Password:
To many incorrect tries...
usw. usw...

Mit ssh einloggen geht jedoch ohne Probleme!!

Versucht habe ich das Kopieren mit folgender Syntax:

scp ~/.ssh/id_dsa.pub server_user@server:~/myhost.pub

und

scp benutzerx@server1:datei1 datei2 benutzery@server2:

wobei ich bei beiden natürlich die Pfade und Rechner(Host) Namen entsprechend angepasst habe:

Beispielsweise:

scp root@rechnername:/root/.ssh/id_rsa.pub root@rechnername:/root/.ssh/rechnername.pub

rechnername=(in meinem Fall)=rechnername - da das ja ein System ist. NOCH verbindet er ja nirgens ins Internet hin...

Woran ich auch schon gedacht habe, wäre die "interne" und "externe" Adressauflösung... also das ers über die externe versucht, also ins Inet raus geht und wieder reinkommt - dabei der Port 22 (zum Testen war er noch auf 22) nicht freigegeben ist und daher das Pass nicht mehr ankommt.

Das wär aber auch das absolut Einzige, was mir persönlich noch als Lösung einfallen mag...

In

/etc/hosts

stehen (allein wegen den vhosts) schon rechnername und lokale IP miteinander verknüpft. Werds nachher mal mit

scp root@localhost:/root/.ssh/id_rsa.pub root@localhost:/root/.ssh/rechnername.pub

probieren... Sollte das funktionieren, versuch ichs nochmal mit rechnername und öffne vorher temporär mal einen Port im Router und in sshd_config...

Sollte doch ein nicht verkehrter Lösungsansatz sein oder?

Nagut, versuche trotz alledem jetzt dennoch paar h zu schlafen... :rolleyes:

Wär schon net verkehrt, wenn ich mich wenigstens im Lösungsansatz net geirrt haben sollte... Ich weiss nicht (schlagt mich:rolleyes::rolleyes:) nicht mehr, aber ich hatte so ein ähnliches prob schonmal... Ich mein das war bei Ubuntu mit phpmyadmin... Naja - egal... Der tag wird vielleicht etwas mehr Aufschluss bringen als gestriger...

EDIT: Bevor ichs vergesse, hehe, gut das ich nicht direkt rausgegangen bin ... Die "known_host" Erstellung macht er bei den Fehlversuchen... Hatte auch mal mit

ssh-keygen -R hostname

aus known_hosts gelöscht. Beim nächsten Mal kommt wieder:

The authenticity of host 'server (192.168.x.x)' can't be established.
RSA key fingerprint is b5:0e:ec:b7:16:06:e6:24:a6:39:18:58:4e:ec:3b:d1. <- (Nur Beispiel)
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'server' (RSA) to the list of known hosts.
Password:

Doch die PW-Auth kam danach nicht mehr zustande...

Gruß
Neutrino_2003

Neutrino_2003

09.01.12, 02:17

Hallo Forum :)

Leider konnte ich das Problem bislang noch nicht lösen... Ich hänge Morgen (bzw. später wenn ich wieder am gentoo-Rechner bin) einmal den Inhalt der

/etc/ssh/sshd_config & /etc/ssh/ssh_config

hier an, bzw poste deren Inhalte... Ich werd echt noch verrückt :o

Habs sogar mit localhost probiert (obwohl es in Ubuntu damals problemlos mit Rechnernamen klappte).

Das Problem ist, das gentoo eine ganz andere sshd_config und ssh_config hat als Ubuntu und Debian. Das was man so im Inet findet, bezieht sich meistens auf entweder Debian oder Ubuntu. Aber was soll ich machen?

Debian stable unterstützt nicht mal die Hälfte meiner Hardware (Kernel 2.6.32-5)
Debian Testing ist sowas von verbuggt, das ich allein während der Avanced-Installation 3 Fehler entweder von "apt" oder sonst einem wichtigen Teil sehen muss. Darauf kann man doch nicht bauen...:mad:

Hatte testweise sogar port 22 mal geforwardet, weil ich halt dachte, das er beim Versuch den 'rechnernamen' als solches zu verwenden eine ext. Auflösung versucht und die RouterFW ihm dann 'im Weg' ist.

ssh geht problemlos (über PW-Auth aber nur, da gentoo mich ja per scp den dämlichen Pubkey nicht kopieren lässt). Wär das ein offizieller Root-Server, könnte ich meinen Pubkey nicht auf den Server kopieren... Dann kann ich gleich unverschlüsseltes Telnet nehmen :((((

Sorry, aber dieses Problem hält mich jetzt mittlerweile 5 Tage auf :(((

EDIT:

Inhalt /etc/ssh/ssh_config

# $OpenBSD: ssh_config,v 1.26 2010/01/11 01:39:46 dtucker 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 some commonly used options. For a comprehensive
# list of available options, their meanings and defaults, please see the
# ssh_config(5) man page.

# Host *
# ForwardAgent no
# ForwardX11 no
# RhostsRSAAuthentication no
# RSAAuthentication yes
# PasswordAuthentication yes
# HostbasedAuthentication no
# GSSAPIAuthentication no
# GSSAPIDelegateCredentials 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-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc
# MACs hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160
# EscapeChar ~
# Tunnel no
# TunnelDevice any:any
# PermitLocalCommand no
# VisualHostKey no
# ProxyCommand ssh -q -W %h:%p gateway.example.com

Inhalt Inhalt /etc/ssh/sshd_config

# $OpenBSD: sshd_config,v 1.82 2010/09/06 17:10:19 naddy 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
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::

# The default requires explicit activation of protocol 1
#Protocol 2

# 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
#HostKey /etc/ssh/ssh_host_ecdsa_key

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

# Logging
# obsoletes QuietMode and FascistLogging
#SyslogFacility AUTH
#LogLevel INFO

# Authentication:

#LoginGraceTime 2m
#PermitRootLogin yes
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10

#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
#KerberosGetAFSToken no

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

# 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 and
# PasswordAuthentication. Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM yes

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

# no default banner path
#Banner none

# here are the new patched ldap related tokens
# entries in your LDAP must have posixAccount & ldapPublicKey objectclass
#UseLPK yes
#LpkLdapConf /etc/ldap.conf
#LpkServers ldap://10.1.7.1/ ldap://10.1.7.2/
#LpkUserDN ou=users,dc=phear,dc=org
#LpkGroupDN ou=groups,dc=phear,dc=org
#LpkBindDN cn=Manager,dc=phear,dc=org
#LpkBindPw secret
#LpkServerGroup mail
#LpkFilter (hostAccess=master.phear.org)
#LpkForceTLS no
#LpkSearchTimelimit 3
#LpkBindTimelimit 3
#LpkPubKeyAttr sshPublicKey

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

# the following are HPN related configuration options
# tcp receive buffer polling. disable in non autotuning kernels
#TcpRcvBufPoll yes

# allow the use of the none cipher
#NoneEnabled no

# disable hpn performance boosts.
#HPNDisabled no

# buffer size for hpn to non-hpn connections
#HPNBufferSize 2048

# Example of overriding settings on a per-user basis
#Match User anoncvs
# X11Forwarding no
# AllowTcpForwarding no
# ForceCommand cvs server

(Sind die Roh-Zustand-Configs) Ich habe nur leider irgendwie den absoluten "Mega-Auf-demSchlauch-Stand" :/

/EDIT

Gruß
Neutrino_2003

just4uk

09.01.12, 11:54

Warum nicht einfach
ssh-copy-id ................

Gruß aus L.E.
Uwe

derRichard

09.01.12, 13:54

was genau ist nun eigentlich das problem?

openssh ist auf allen distributionen gleich.

//richard

Neutrino_2003

09.01.12, 18:33

Hallo just4uk und derRichard :)

Naja, das Problem ist, das ich die hostname.pub (id_{rsa,dsa,ecdsa} nicht kopiert bekomme. Normalerweise wäre die "id_x.pub" von einem auf den anderen Rechner (Server) zu kopieren. Ich wollte mich mit ssh etwas vertraut(er) machen, damit mir später die Befehle geläufiger sind.

Somit ging ich nach der gentoo-Anleitung zum Kopieren des Pub-Keys vor und alles was ich sehe - sind Fehler :(

scp ~/.ssh/id_dsa.pub server_user@server:~/myhost.pub

So, danach sollte dann der Inhalt des kopierten hostkey.pub in "authorized_keys" verschoben werden. Von

ssh-copy-id

steht in der gentoo Anleitung nichts. Nicht das ich es nicht kennen würde, aber ich kenne es von Ubuntu her. Ich wußte nicht, das ssh auf anderen Distris gleich sind, ich kann nur zu 100% sagen, das Ubuntu eine andere ssh_config und auch sshd_config hatte. Und auch, das es darauf Problemlos lief. Und ich weiß, das gentoo-How-Tos vor Fehlern klaffen, und das es mit der Methode:

$ scp ~/.ssh/id_dsa.pub server_user@server:~/myhost.pub
$ ssh server_user@server "cat ~/myhost.pub >> ~/.ssh/authorized_keys"
$ ssh server_user@server "cat ~/.ssh/authorized_keys"

sowie auch nach der Ubuntu-Methode

scp root@rechnername:/root/.ssh/id_rsa.pub root@rechnername:/root/.ssh/rechnername.pub

nicht geht. Bei Ubuntu hab ich es auch - wie gesagt, mit ssh-copy-id - gemacht, nur da dies in keiner gentoo-Anleitung stand, wollte ich es nicht testen bisher...

Anders gefragt: Den Pubkey zu kopieren ist -als solches auch nur- "eine Datei kopieren". Und das müsste ja eigentlich auch zu einer Zeit gehen, wenn noch KEINE Schlüssel ausgetauscht sind?! Oder?! Aber das geht NICHT! Und genau das, genau das ist mein Problem.

EDIT

scp root@rechnername:/root/.ssh/rechnername.pub root@rechnername:/root/.ssh/rechnername_server.pub
The authenticity of host 'rampage2extreme (127.0.0.1)' can't be established.
ECDSA key fingerprint is 11:22:33:44:55:66:77:88:99:10:11:12:13:14:15:16.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'rechnername' (ECDSA) to the list of known hosts.
Password:
Permission denied (publickey,keyboard-interactive).
lost connection

scp root@rechnername:/root/.ssh/rechnername.pub root@rechnername:/root/.ssh/rechnername_server.pub
Password:
Permission denied, please try again.
Permission denied, please try again.
Received disconnect from 127.0.0.1: 2: Too many authentication failures for root
lost connection

Seht Ihr? Sollte ich nicht auch NUR PER PASSWORT einen erfolgreichen Kopiervorgang schaffen? Aber alles was ich sehe, ist soeine Fehlerka**e

/EDIT

Gruß
Neutrino_2003

derRichard

09.01.12, 19:15

hmm, warum den hostkey kopieren?

wenn du als userX auf serverY ssh ohne passwort (also mit public key) machen willst, dann musst als userX ein key-pair haben und dessen public key in den server unter /home/userX/.ssh/authorized_keys schreiben.

//richard

Neutrino_2003

09.01.12, 19:22

Hallo Richard,

Ja, das versteh ich auch, nur erstmal muss der Schlüsselaustausch ja stattfinden können (was just4uk mit -ssh-copy-id- im Blick hatte).

Ich wollte so vogehen, den Pubkey (habe ein Paar erstellt) per scp auf den Server kopieren. (Der Server ist bei mir auch der Client - ist ja ein Übungssystem). Das ist das was ich da oben im letzten Beitrag die ganze Zeit mit 'scp...' probiere...

Der nächste Schritt wäre dann, per cat den Key aus dem pubkey.pub File auszulesen und in die Datei "authorized_keys" zu schreiben. Nur solange es keinen Schlüssel auf einem Server gibt, MUSS ja Passwort-Auth funktionieren, was es aber bei mir nicht tut.

derRichard

09.01.12, 19:50

wie schlüsseltausch?

du kopierst einfach deinen public auf den server...

//richard

Neutrino_2003

09.01.12, 19:55

Aääh, Richard?!

Das ist genau das, was bei mir nicht funktioniert?!

derRichard

09.01.12, 19:57

und was geht nicht?
du musst ja nur den inhalt von id_rsa.pub nach authorized_keys schreiben...

//richard

Neutrino_2003

09.01.12, 20:00

scp root@rechnername:/root/.ssh/rechnername.pub root@rechnername:/root/.ssh/rechnername_server.pub
Password:
Permission denied, please try again.
Permission denied, please try again.
Received disconnect from 127.0.0.1: 2: Too many authentication failures for root
lost connection

Bei scp nimmt er das Pass nicht an. ssh einloggen geht, aber das bringt mir ja nicht viel, solange das den Key beinhaltende File nicht auf dem Server ist.

Eigentlich ist es es ja, doch ich möchte mit der Funktion 'scp' zurechtkommen, weil ich ein mächtiges Problem habe, wenn das genauso problematisch wird, wenn das mal KEINE Übung mehr ist, sondern beim richtigen RootServer auch nicht funkt :(

derRichard

09.01.12, 20:03

Neutrino_2003

09.01.12, 20:07

Bevor ich anfing, habe ich die ssh_config und auch sshd_config an einen sicheren Ort (anderes Verzeichnis, in dem ich viele nicht konfigurierte Dateien schiebe, bevor ich sie erstmals benutze) kopiert.

Das habe ich aber auch schon versucht: Sogar habe ich es versucht eine komplett unbearbeitete zu verwenden. Und genau das ist es ja was ich von Ubuntu erzählt habe: 2 Einstellungen und es funktioniert. Wenn nun ssh auf alles Distris gleich ist, warum gehts dann mit den selben Einstellungen, wie sie auf Ubuntu erfolgreich waren, auf gentoo nicht? Ich weiss nicht was ich noch einstellen soll:((( Weisst was ich alles schon probiert hab in den letzten Tagen? Es war egal was ich auch in den Configs eingestellt habe - nur erfolglos.

EDIT

Ich kapier nicht warum ich per ssh Anmelden kann, aber scp geht nicht. Also ICH kapiere das nicht mehr, wahrhaftig nicht.

/Edit

derRichard

09.01.12, 20:09

das "Received disconnect from 127.0.0.1" ist schon mal sehr strange....

//richard

Neutrino_2003

09.01.12, 20:14

Ich hatte in der config schon:

127.0.0.1
192.168.x.x
externe IP

Bei der Verwendung von der lokalen Adresse also 192.168.x.x bekomme ich:

scp root@rechnername:/root/.ssh/rechnername.pub root@rechnername:/root/.ssh/rechnername_server.pub
The authenticity of host 'rechnername (127.0.0.1)' can't be established.
ECDSA key fingerprint is 11:22:33:44:55:66:77:88:99:10:11:12:13:14:15:16.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'rechnername' (ECDSA) to the list of known hosts.
Password:
Permission denied (publickey,keyboard-interactive).
lost connection

EDIT Es ist egal, was ich mache, es ist sch....egal, es geht nicht. Vielleicht hat die gentoo-Version von ssh einen Bug, ich weiß es nicht. Doch ich weiß und das zu 100%, das diese Version nie und nimmer die was, die ich vor paar Monaten bei Ubuntu hatte.

The authenticity of host '192.168.x.x (192.168.x.x)' can't be established.
ECDSA key fingerprint is ....
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.x.x' (ECDSA) to the list of known hosts.
Password:
Permission denied, please try again.
Permission denied, please try again.
Received disconnect from 192.168.x.x: 2: Too many authentication failures for root
lost connection

/EDIT

derRichard

09.01.12, 20:15

Neutrino_2003

09.01.12, 21:46

Es war eigentlich nur eine verzweifelte Lösungssuche, Richard.

Denn ich weiß weder, warum es nicht funktioniert, weniger noch, was ich noch machen kann. Die id_rsa.pub krieg ich nicht kopiert, also scp server1:datei1 server2:datei1 = ist egal mit was ich mache, nicht möglich... Wie gut es ist, das es noch auf meinem Rechner ist. Wäre das schon der Server, würd ich wahrscheinlich echt langsam Amok laufen :((((

EDIT

Ich Habe mein System in einem Image gesichert, ich mache es nochmal neu drauf und Probier dann dasgleiche nochmal, die configs bearbeite ich erst garnicht (denn es bringt nichts) und dann mit einem anderen Linux-Rechner im lokalen Netz von dortaus die id_rsa hierhin zu kopieren. Praktisch, als ob dies hier 'NUR' der Server wäre... Bei mir ist es ja eine Maschine.

Weißt Du, ich versteh eines nicht: Ich geb Dir Recht, warum ich "irgendwelche" IP-Adressen in die Config eintrage...
Das habe ich bei Ubuntu auch nicht gemusst. Doch war dort in der config etwas wie:

"root@host"

Das gibt es hier bei der config nicht. Das brachte mich zu der Idee, mit localhost bzw. 127.0.0.1 zu testen. Später wär das, dachte ich, eine gute Idee nur eine IP als zugelassene im Server zu erlauben. Dachte, das könnte auch einen gewissen Sicherheitsaspekt darstellen.

Nur, warum ssh problemlos geht, nicht aber scp... Richard, was kann das sein? Warum geht ssh, aber nicht scp? ssh und scp kommen von openssh. Oder nicht? Das MUSS doch ein bug sein. Oder?

/EDIT

pibi

10.01.12, 08:36

Das MUSS doch ein bug sein. Oder?Das glaube ich nicht.

Noch ein Tip zum Uebertragen des Public-Keys auf den Zielrechner:

- auf den Ausgangsrechner den Public-Key anzeigen ("cat id_dsa.pub") und mit der Maus markieren ("copy")
- mit ssh auf den Zielrechner wechseln
- mit einem Editor das File "authorized_keys" bzw. "authorized_keys2" oeffnen und den vorher markierten Key am Ende einfuegen ("paste").
- Rechte von "authorized_keys" bzw. "authorized_keys2" auf "read/write nur fuer owner" setzen

Gruss Pit.

just4uk

10.01.12, 13:59

Hm evtl. etwas blöd aber ............ du bist dir sicher das die Datei datei1 auch existiert?

........- mit einem Editor das File "authorized_keys" bzw. "authorized_keys2" oeffnen und den vorher markierten Key am Ende einfuegen ("paste")...........................Hab ich auch schon gemacht, aber ACHTUNG der Key MUSS in einer Zeile stehen!! D.h. auch wenn er über mehrere Zeilen geht darf kein manueller Zeilenumbuich drin sein!! Das klappt bei c/p nicht immer.
Was mich verwirrt
scp root@rechnername:/root/.ssh/rechnername.pub root@rechnername:/root/.ssh/rechnername_server.pubVersuchst du hier
1. wirklich per scp eine Datei umzubennen? Oder
2. steht '@rechnername' für einen Hostnamen den du hier nicht preis geben möchtest?
Wenn 2. dann wird das nur was wenn auf beiden Systemen der Key vorliegt!
Z.b.

root@server:~#scp root@client1:/opt/datei.txt root@client2:/opt/funktioniert nur wenn auf beiden Hosts der Key vorhanden ist!

root@server:~#scp /opt/datei.txt root@Client2:/tmp/funktioniert (sofern konfiguriert) auch mit Password.
Wenn 1. dann muss in der
authorized_keysvon Host rechnername der Key vom Host rechnername drin stehen.

Gruß aus L.E.
Uwe

Neutrino_2003

10.01.12, 15:31

Hallo pibi und just4uk :)

Danke Euch für Eure Posts :)) Bin auch grad erst dazu gekommen zu werkeln ;)

Ja, zuerst mal was zu Eure Fragen anbetraf:

Zitat von pibi

Noch ein Tip zum Uebertragen des Public-Keys auf den Zielrechner:

- auf den Ausgangsrechner den Public-Key anzeigen ("cat id_dsa.pub") und mit der Maus markieren ("copy")
- mit ssh auf den Zielrechner wechseln
- mit einem Editor das File "authorized_keys" bzw. "authorized_keys2" oeffnen und den vorher markierten Key am Ende einfuegen ("paste").
- Rechte von "authorized_keys" bzw. "authorized_keys2" auf "read/write nur fuer owner" setzen

Danke Dir für Deinen Vorschlag, ich werde das heute auch mal testen falls
ssh-copy-id auch nicht klappen sollte... :)

Zitat von just4uk

Was mich verwirrt

scp root@rechnername:/root/.ssh/rechnername.pub root@rechnername:/root/.ssh/rechnername_server.pubVersuchst du hier

1. wirklich per scp eine Datei umzubennen? Oder
2. steht '@rechnername' für einen Hostnamen den du hier nicht preis geben möchtest?
Wenn 2. dann wird das nur was wenn auf beiden Systemen der Key vorliegt!

Der Rechnername ist kein großes Geheimnis. Ich könnt auch 'rampage2extreme' sagen. Nur dachte ich das es zur Vereinheitlichung und des Verstehens besser ist, wenn dort ein unikater Name steht. Mir persönlich würds auch so besser gefallen, wenn ich sicher nicht nur einen user habe der was fragt wo Rechnernamen vorkommen. :)

EDIT

Noch ein Grund, nach Rechnernamen zu benennen ist, das dieser Rechner mit gentoo (um den es jetzt geht) der Steuerrechner" für den Root wird. Bedeutet, das es nochmal neue, hier zu erstellende Keys geben wird. Diesen würd ich evtl "Server und Server.pub" nennen. Somit schließe ich ein "Durcheinander" im Nachhinein aus :)

/EDIT

Zitat von just4uk

Wenn 2. dann wird das nur was wenn auf beiden Systemen der Key vorliegt!
Z.b.

root@server:~#scp root@client1:/opt/datei.txt root@client2:/opt/funktioniert nur wenn auf beiden Hosts der Key vorhanden ist!

root@server:~#scp /opt/datei.txt root@Client2:/tmp/

Ich habe ihn direkt bei der Erstellung:

ssh-keygen -b 4096 -t rsa so benannt. Einer heißt "rampage2extreme" (der private) und der öffentliche, mit *.pub "rampage2extreme.pub"

Mir ist gestern noch die Idee gekommen auf einem anderen meiner Rechner mal als vm testweise ein Ubuntu aufzusetzen. Mir brennts auf der Seele, zu sehen, ob es mit

scp root@rechnername:/root/.ssh/rechnername.pub root@rechnername:/root/.ssh/rechnername_server.pub

bei Ubuntu klappt. Dort hatte ich es immer mit copy-id gemacht. Das fiel mir gestern abend noch irgendwie ganz siedendheiß ein...

Gruß
Neutrino_2003

derRichard

10.01.12, 16:05

hi!

je öfter ich deine posts sehe, desto mehr komische sachen sehe ich.

scp root@rechnername:/root/.ssh/rechnername.pub root@rechnername:/root/.ssh/rechnername_server.pub

warum scp innerhalb der selben recher?
wo führst du das überhaupt aus?

//richard

Neutrino_2003

10.01.12, 16:43

Zitat von derRichard

hi!

je öfter ich deine posts sehe, desto mehr komische sachen sehe ich.

scp root@rechnername:/root/.ssh/rechnername.pub root@rechnername:/root/.ssh/rechnername_server.pub

warum scp innerhalb der selben recher?
wo führst du das überhaupt aus?

Hallo Richard :)

Das hört sich ja fast schon so an, als ob ich das mache, um Euch zu ärgern ;)

Dann erklär ichs nochmal:

Habe hier ein gentoo-Rechner auf dem ich ssh und scp SIMULIEREN will. Also zum lernen.

Heißt ich probiere ssh und scp aus, nur das ich dabei Dinge (wie halt den key jetzt) nicht zu einem Server im Inet kopiere, sondern zu mir selbst.

Natürlich könnte ich 'cp' verwenden um auf der Console zu kopieren, doch das wird mir beim Server nicht viel helfen. Dann werde ich auf ssh und scp angewiesen sein und möchte vorbereitet ans Werk gehen.

Du siehst an dem Post schon, das ich ssh und scp noch nicht so ganz beherrsche. Doch besser hier zu testen, als an einem Root, oder?

Gruß
Neutrino_2003

derRichard

10.01.12, 16:46

eine simulation sollte aber auch sinn machen.
und für simulierte probleme gibt es selten lösungen. :ugly:

//richard

Neutrino_2003

10.01.12, 17:51

Nunja, Richard, Probleme zu züchten war nicht meine Absicht bei dem ganzen Unterfangen... :o

Wahrscheinlich liegt es an diesem Code, de ich benutzt habe:

scp root@rechnername:/root/.ssh/rechnername.pub root@rechnername:/root/.ssh/rechnername_server.pub

Das dies eine remote2remote - Verbindung bedeutet, das habe ich nun auch begriffen. Ok, klar sieht für dich und die anderen der Code "schräg" aus. Nur wie soll man es lernen? Ich will nicht relativieren, nur 'fehlgeschlagene Simulationen' kann man eigentlich jeden Tag lesen.

Eindrucksvoller -klar- wärs natürlich gewesen, hätte ich einen anderen Linux-PC hier aufgesetzt (das hatte ich eigentlich heute als VM vor, aber habe ich dann doch gelassen) und von dort aus hierhin verbunden. Praktisch Maschine2Maschine - Simulation.

Es wär sowieso alles nicht dazu gekommen, könnte man sich mal auf die gentoo-How-To 's ein wenig mehr verlassen. Da habe ich gesucht, ob es diesen Befehl mit ssh-copy-id gibt... Damit hatte es bei Ubuntu problemlos funktioniert. Nur führe ich nicht irgendwelche Befehle aus, wenn ich offensichtlich sehe, das diese nicht zur besagten Distri gehören. Das OpenSSH (trotz unterschiedlichen Configs) überall gleich ist... Woher weiß ich das? Sitze die letzten 8 Monate und tu ausser lesen und lernen garnichts mehr. :(

Klar, wirst Du jetzt sagen "jetzt sind die How-To 's schuld"...
Doch weisst wieviele Fehler ich da schon bei der Installation gesehen und drauf reingefallen bin? Gentoo ist meiner Meinung nach ein wahnsinns-Linux. Ich habe vor gentoo Ubuntu, Debian, Fedora, CentOS, Arch, uvm (unterschiedliche Versionen) gehabt, doch gentoo stellt irgendwie sagen wir viel in den Schatten. Nur , ich denke Du kennst es noch besser als ich, installiert man gentoo auch nicht "einfach so mal". Und wenn man nach dem How-To vorgeht, dann fällt man schonmal gut auf die Nase...Ist eine Schande drum, echt.

Gut, Back2Topic...

Werds mit ssh-copy-id probieren... Das hat man mir mittlerweile noch woanders bestätigt, das es so geht und man es nutzen soll. Mal sehen.

Gruß
Neutrino_2003

Neutrino_2003

10.01.12, 21:02

Habs gelöst.

Danke für Eure Hilfe :) Hoffe, ich habe nicht zu sehr genervt :)

Gruß
Neutrino_2003

derRichard

10.01.12, 21:03

verrätst du uns auch die lösung?

//richard

Neutrino_2003

10.01.12, 21:15

/etc/ssh/sshd_config

RSAAuthentication yes
PasswordAuthentication yes
UsePAM yes

Dann

ssh-copy-id -i /root/.ssh/rechnername.pub root@rechnername

Das hat mir dann DEN WUNSCH der letzten Tage erfüllt ;)

Danach in

/etc/ssh/ssh_config und sshd_config

RSAAuthentication no
PasswordAuthentication no
UsePAM no

In ssh_config einen anderen Port als 22 (dasselbe in sshd_config)

und...

(kleiner Ausschnitt)

# IdentityFile ~/.ssh/identity
IdentityFile ~/.ssh/rechnername
# IdentityFile ~/.ssh/id_dsa
Port ***

EDIT

Der Fehler war wohl, das ich die IP oben eingetragen hatte (127.0.0.1) und auch das ich mit
scp root@rechnername:/root/.ssh/rechnername.pub root@rechnername:/root/.ssh/rechnername_server.pub - unwissend einen remote:remote Kopiervorgang zu starten versuchte :/

/EDIT

EDIT2

Unwichtig, dachte, den Scherz würde man hier verstehen, war aber leider nicht so :/

EDIT2/

Gruß
Neutrino_2003