[solved] ssh als USER A auf Server A zu USER B auf SERVER B

[funon]

Hilfe Jungs,
ich habe da ein Problem und bekomme die Krise
Ich suche und bastele nun schon seid 72 Stunden an diesem *"§$"§%%/$* Problem rum.

Zur Situation:
Ich möchte von System A, als usersystema, eine Datei per scp auf System B, ins /home/userbvonb, kopieren, und danach auf System B mit dem uservonb ein script aufrufen. Ich kann da aber kein Kennwort mitgeben, da ich das Per Script machen muss.

Als root kann ich sowohl ssh und scp ohne kennwort machen.
Auf beiden Systemen, gibts beide User, ich habe auch beide id_rsa.pub in die jeweils andere authorized_keys bei den usern getan, aber ich werde immer nach dem Kennwort des Zielservers gefragt?

Ich raffe das nicht *scheißkonsole*

thx und gutes gelingen

Dirk

 

[Leviathan]

bei ssh mit -I den private key mitgeben.
ssh mit -vv starten
key forwarding (falls du mit putty drauf bist) ausschalten.
auf zeilenumbrüche in der authorized keys achten.
ggf. mal einzelne ssh versionen durchprobieren mit -v2 (? bin nicht sicher)

Viel Glück

Gruß Dominik

 

[funon]

Hi Dominik,
danke für die Antwort. Ich habe das mit dem -l und mit -1 bzw -2 für die Versionen versucht, bin da aber nicht sicher, wessen Private Key ich dazu brauche? Also den vom Server A oder B?
Ich bin in der Lage direkt an der Konsole zu arbeiten, kann da also Putty ausschließen. Zeilenumbrüche schließe ich auch mal aus, da ich unter

/home/usera/.ssh/authorized_keys

die Datei schon direkt aus dem Jeweiligen Key neu gemacht habe.
In den manpages zu ssh stand auch was mit ner

config

diese scheint er bei mir auch nicht zu nehmen, wenn ich sie mit Mask 600 unter

/home/usera/.ssh/config

ablege.

Ist es denn richtig die ssh keys in den Userverzeichnissen abzulegen oder müssen die unter

/root/.ssh/

liegen?
Muss ich evtl. noch wo anders erlauben, dass er "persönliche" configs zieht?

 

[Leviathan]

Hi Dominik,
danke für die Antwort. Ich habe das mit dem -l und mit -1 bzw -2 für die Versionen versucht, bin da aber nicht sicher, wessen Private Key ich dazu brauche? Also den vom Server A oder B?

Nicht den vom Server, den vom User.
also z.B.
ssh -v -2 -I /home/usera/.ssh/id_rsa.pub [user]@host

diese Option -i (kleines i , sry!) ist nicht zwingend notwendig und stetht per default (siehe man ssh) auf #

# IdentityFile ~/.ssh/identity
# IdentityFile ~/.ssh/id_rsa
# IdentityFile ~/.ssh/id_dsa


> In den manpages zu ssh stand auch was mit ner

config

diese scheint er bei mir auch nicht zu nehmen, wenn ich sie mit Mask 600 unter

/home/usera/.ssh/config

ablege.

config kenne ich nicht.


> Ist es denn richtig die ssh keys in den Userverzeichnissen abzulegen oder müssen die unter

/root/.ssh/

liegen?

Jeder User hat seine keys im eigenen Verz. liegen.


> Muss ich evtl. noch wo anders erlauben, dass er "persönliche" configs zieht?

"eigentlich" nicht, per default guckt er jeweils im Home Verzeiochnis der User.

Starte das ssh mal mit der Otpion -v und poste die ausgabe.

Gruß Dominik

 

[funon]

Oki denn hier mal die Ausgabe von ServerA aus

bash-2.03$ /opt/SMAWPlus/bin/ssh -v svuser@liten
OpenSSH_3.5p1, SSH protocols 1.5/2.0, OpenSSL 0x0090605f
debug1: Reading configuration data /opt/SMAWPlus/etc/ssh_config
debug1: Rhosts Authentication disabled, originating port will not be trusted.
debug1: ssh_connect: needpriv 0
debug1: Connecting to liten [194.31.205.49] port 22.
debug1: Connection established.
debug1: identity file /home/ictadm/.ssh/identity type -1
debug1: identity file /home/ictadm/.ssh/id_rsa type 1
debug1: identity file /home/ictadm/.ssh/id_dsa type -1
debug1: Remote protocol version 1.99, remote software version OpenSSH_3.4p1
debug1: match: OpenSSH_3.4p1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.5p1
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 sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: dh_gen_key: priv key bits set: 116/256
debug1: bits set: 1588/3191
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'liten' is known and matches the RSA host key.
debug1: Found key in /home/ictadm/.ssh/known_hosts:3
debug1: bits set: 1614/3191
debug1: ssh_rsa_verify: signature correct
debug1: kex_derive_keys
debug1: newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: waiting for SSH2_MSG_NEWKEYS
debug1: newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: done: ssh_kex2.
debug1: send SSH2_MSG_SERVICE_REQUEST
debug1: service_accept: ssh-userauth
debug1: got SSH2_MSG_SERVICE_ACCEPT
debug1: authentications that can continue: publickey,password
debug1: next auth method to try is publickey
debug1: try privkey: /home/ictadm/.ssh/identity
debug1: try pubkey: /home/ictadm/.ssh/id_rsa
debug1: authentications that can continue: publickey,password
debug1: try privkey: /home/ictadm/.ssh/id_dsa
debug1: next auth method to try is password
svuser@liten's password:

dann muss ich das Password eingeben

debug1: ssh-userauth2 successful: method password
debug1: channel 0: new [client-session]
debug1: send channel open 0
debug1: Entering interactive session.
debug1: ssh_session2_setup: id 0
debug1: channel request 0: pty-req
debug1: channel request 0: shell
debug1: fd 4 setting TCP_NODELAY
debug1: channel 0: open confirm rwindow 0 rmax 32768
Last login: Thu Nov 16 16:30:02 2006 from prione.ic-zedach.de

Mit pwd funktioniert es, nur ich brauche es halt ohne pwd
es funktioniert wie gesagt auch als user root ohne Password

thx Dirk

 

[Leviathan]

Ok , bin ratlos.

paar ideen hab ich aber noch:
schreib mal vor den key in der authorized_keys ein ssh-rsa (wenns ein rsa key ist)

also so:
ssh-rsa AAAAB3Nz-....

Rechte der public keys dürfen weder zu eingeschränkt noch zu frei gesetzt sein (denke mit 644)

ggf. heisst dein key id_rsa.pub und er will id_rsa (ka, schuss ins blaue)

check mal sshd_config ob da
alles auf yes steht und nicht evtl auf no
#RSAAuthentication yes
#PubkeyAuthentication yes

Gruß Dominik

 

[funon]

Die Antwort war eigentlich recht einfach.
Ich habe für beide User neue keys generiert und diese dann ausgetauscht.
Danach hat es funktioniert, wieso kann ich nicht sagen...

Thx 4 your Help

Dirk