ssh in ein ShellScript ausfuehren

[nomad]

hi,
also
abgeaendertes no 5
ssh 192.168.100.1 "chmod 644 .ssh/authorized_keys2"
ergebnis:
root(at)192.168.100.1 password
linux:~ #
mein versuch ohne password
-- muss es angeben
also nichts gewesen.
frage: was meinst du mit:
Fall das nicht geht benennst du die dann auch mal nach
authorized_keys um????
):>
moecht jetzt nicht umbedingt was falsches machen,
weil ich in den letzten 3 stunden
fasst folgendes gemacht haette den inhalt aus/root/.ssh
einfach in anderen leeren .ssh,s kopieren,was
vermutlich saubloede gewesen waere.
also lieber vorsichtig...
mfg nomad

[peschmae]

ssh 192.168.100.1 "mv .ssh/authorized_keys2 .ssh/authorized_keys"
meinte ich damit.

Du machst das ganze als root? Dann musst du wohl noch auf dem Ziehlrechner (falls nicht schon eingestellt) in der /etc/ssh/sshd_config
PermitRootLogin yes
setzen und auch gleich noch:
RSAAuthentication yes
PubkeyAuthentication yes

MfG Peschmä

[nomad]

hi,
ja als root,
gut, ich setzt dass mal in /etc/ssh/sshd_config
auf die noetigen werte.

nur den befehl mv versteh ich nicht ganz,
also wuerd ich ja mit mv .ssh/authorized_keys2 .ssh/
authorized_keys verschieben.
also: _keys2 in ein neues file .ssh/authorized_keys
verschieben, wobei _keys2 geloescht wuerde.
stimmt das dann???
denn im zielrechner unter /root/.ssh/ sind nur
zwei files vorhanden authorized_keys2 und known_hosts??
_keys2 hat folgende berechtigungen:

klasse lesen schreiben ausfuehren

benutzer lesen & schreiben not ausfuehren
gruppe lesen
sonstige lesen

eigentuemer root
gruppe root

hab das mit nfs rausgefunden
pc90 client, pc64 server

so, hoffentlich nimmt die ganze choose noch ein gutes
ende,
danke, dass du mich noch nicht aufgegeben hast
mfg nomad

[nomad]

hi,
also berechtigungen auf PC64(zielrechner) in
/etc/ssh/sshd_config
PermitRootLogin yes ok
RSAAuthentication yes ok
PubkeyAuthentication == kein eintrag vorhanden.

frage: eintrag ergaenzen ?

folgendes ist mir bei PC90 (quellrechner)
in /etc/ssh/sshd_config
sind obige eintraege ausdokumentiert

frage: aendern ?

nun zu: ssh 192.168.100.1 "mv .ssh/authorized_keys2
.ssh/authorized_keys
hab in meinen netzwerk-buch folgendes gefunden:

ssh liest ja von authorized_keys und nicht von _keys2.
stimmt meine ueberlegung ?

also jetzt zur ausfuehrung:
1.) vorsichtshalber _keys2 auf disk gesichert.

2,) ssh 192.168.100.1 "mv .ssh/authorized_keys2 .ssh/authorized_keys

ergebnis: >

- grosses fragezeichen, ist jetzt ssh in irgendeinen
befehls-modus.
- keine aenderung auf zielrechner (kein _keys vorhanden)
falls, obiger befehl das ueberhaupt bewirkt
(remove file).
- keine reaktion auf exit or quit, blieb einfach dort
stehen.
- erscheint auch nicht auf ps -a
- musste dann das consolenfenster loeschen

- test mit ssh 192.....
- ergebnis immernoch password abfrage.

- ueberlegung, du hast in einer deiner antworten,
ungefaehr folgendes gesagt:
ein abstellen der password-abfrage waere schlecht...
da meine entwicklungsrechner keinen zugang zum web
haben und kein mensch an die maschinen kommen,
waere das ja eine gangbare alternative ???
meine device lebe gefaehrlich... ):-))

so, im augenblick hab ich keine ahnung wie das weitergehen
soll, in der hoffnung auf deine antwort meld mich im
laufe des tages.
schoenes weekend noch
mfg nomad

[peschmae]

hi,
also berechtigungen auf PC64(zielrechner) in
/etc/ssh/sshd_config
PubkeyAuthentication == kein eintrag vorhanden.

frage: eintrag ergaenzen ?

ja, den hinzutun

folgendes ist mir bei PC90 (quellrechner)
in /etc/ssh/sshd_config
sind obige eintraege ausdokumentiert
frage: aendern ?

das ist egal. Wichtig ist der Zielrechner - sshd ist das Programm das auf eintreffende ssh-Zugriffe wartet. Mit dem Quellrechner hast du ja diesbezüglich nichts vor.

nun zu: ssh 192.168.100.1 "mv .ssh/authorized_keys2
.ssh/authorized_keys
hab in meinen netzwerk-buch folgendes gefunden:

ssh liest ja von authorized_keys und nicht von _keys2.
...

Ja, stand irgendwie falsch in meinem howto - ist bei mir auch _keys

2,) ssh 192.168.100.1 "mv .ssh/authorized_keys2 .ssh/authorized_keys

du hast wohl das abschliessende " vergessen
Das bemerkt die Shell - dein Befehl ist noch nicht abgeschlossen. Folglich "denkt" sie du möchtest einfach auf der nächsten Zeile weitertippen.
Ssh wird da noch nicht gestartet...

Kannst das natürlich auch direkt am anderen PC umbenennen

MfG Peschmä

[nomad]

hi,
uups...
ich hab leider ????
folgendes gemacht:

da ssh ja die _keys im zielrechner liest
und der "mv"-befehl (;-o nichts gebracht hat.
hab ich folgendes gemacht:
1. auf zielrechner _keys2 in einen seperaten ordner
verschoben,
2. dort keys_2 in keys umbenammst
3. _keys nach /root/.ssh/ copiert
4. dort chmod 644 authorizied_keys
hat jetzt die gleichen rechte wie gestern _keys2

ergebnis wie gehabt..

kann aber wieder den originalzustand herstellen.

dann noch ev.schlimmer.

weiterer versuch mit adminHandbuch von suse 9.0
aus ssh-authentifizierungsmechanismen:
1. generierung des schluesselpaars
mit ssh-keygen -t dsa
(da wir das schon vermutlich richtig gemacht haben,
hab ich das nicht nochmals gemacht)
auf quellrechner pc90 liegen unter /root/.ssh/ als
id_dsa, id_dsa.pub, known_hosts

== komischer ist, lt output von ssh-keygen -t dsa
sollten die files in /root/.ssh/id_dsa liegen
bei mir aber eben unter /root/.ssh/
das ../id_dsa hab ich nicht gefunden.??

2. gem.suse hab ich dann das file id_dsa.pub
mit nfs zum zielrechner kopiert unter /root/.ssh/
und umbenannt zu authorized_keys

3. berechtigungen sind die gleichen wie oben

ergebnis mit ssh 192...
und ssh root@192....
mit password...

asche auf mein haupt
also ich ergaenz jetzt mal PubkeyAuth... yes.
und guck dann mal was passiert

hoffentlich redest du noch mit mir,
mfg nomad

HIIILFE
zusatz
hi,
also nach eintrag PubkeyAuthentication yes
und neustart aller rechner:

1) linux: ~/Desktop # ssh root@192.168.100.1 ls
ssh: connect to host 192.168.100.1 port 22:
Connection refused
linux: ~/Desktop #

2)linux: ~/Desktop # ssh 192.168.100.1
ssh: connect to host 192.168.100.1 port 22:
Connection refused
linux: ~/Desktop #

entschuldige sch..... jetzt uups.

waere es eine moeglichkeit das ganze zeugs nochmals
von vorn zu machen also
auf zielrechner alles loeschen (in /root/.ssh/
generierung des schluessel ssh-keygen -t dsa
aber eben _keys statt _keys2

was ich nicht ganz versteh bevor ich
PubkeyAuthentication yes nicht gemacht hatte,
gings ja noch, hab ich die falschen schluessel erwischt
oder was

hoffentlich meldest du dich sonst bin ich ganz schoen
aufgeschmissen.
wart jetzt auch ganz schoen brav.
mfg nomad

[peschmae]

Hmm, eigentlich hätte es jetzt gehen sollen.

Argh, mein Fehler. Setz auf dem Server-Rechner (dem auf den zu via ssh zugreifen willst) die Rechte für den .ssh-Ordner auf 700 und die für die authorized_keys auf 600:
chmod 700 .ssh
chmod 600 .ssh/authorized_keys

MfG Peschmä

[nomad]

merci,
also den rechner auf den ich zugreifen moechte
(pc64 - 192.168.100.1)
unter /root/ oberhalb von .ssh == chmod 700 .ssh
unter /root/ oberhalb von .ssh == chmod 600 .ssh/authorized_keys
ergebnis: chmod: ./ssh/authorized_keys:no such file or
directory
jetzt innerhalb von /root/.ssh/
chmod 600 authorized_keys

berechtigung: autorized_keys = -rw-------
berechtigung: .ssh/ = drwx------

nun neustart aller rechner

versuch mit
linux: ~/Desktop # ssh root@192.168.100.1 ls

ergebnis: ssh: connect to host 192.168.100.1 port 22
connection refused

mit ssh 192.168.100.1 dasselbe ergebnis

jetzt noch ne frage: hab ich bei meinen obigen aktionen
was falsch gemacht oder wie
soll ich nochmals von vorne anfangen
also mit
1-ssh-keygen -t dsa
2- scp ~/.ssh/id_dsa.pub 192.168.100.1:.ssh/authorized_keys2
3- ssh 192.168.100.1 "chmod 644 .ssh/authorized_keys2
4- ssh 192.168.100.1 "mv ./ssh/authorized_keys2
./ssh/authorized_keys"
5- ev. wie oben chmod wieder richtig setzen

ich verzweifle langsam
mfg nomad

[peschmae]

1-ssh-keygen -t dsa
2- scp ~/.ssh/id_dsa.pub 192.168.100.1:.ssh/authorized_keys
3- ssh 192.168.100.1 "chmod 600 .ssh/authorized_keys

dann guckst du am besten mal in die logfiles. Auf dem Server-Pc führst du als root ein "tail -f /var/log/auth.log" anschliessend versuchst du dich vom anderen PC einzuloggen (am besten mit "ssh -v 192.68.x.y" das gibt n bisschen mehr Output) und guckst was inzwischen auf dem Server ausgegeben wurde. Bei mir sieht das etwa so aus:

Jul 24 19:09:03 localhost sshd[2146]: Accepted publickey for root from 192.168.1.37 port 53740 ssh2
Jul 24 19:09:03 localhost sshd[2148]: (pam_unix) session opened for user root by root(uid=0)

und wenn die Verbindung beendet wurde:
*nix war da*

MfG Peschmä

[nomad]

hi,
danke das mach ich mal:

aber was heisst dass:
yooour qoute:
und wenn die verbindung beendet wurde:

[code] ???? da komm ich nicht ran.

da ich z.Z.nur eine notverbindung zum web habe
und netscape 3.01 verwenden muss.
bitte keine attachments oder sonstige sachen
wie [code]anhaengen,
netscape kann das nicht, ich kann ja nicht einmal
von meinen notizen cut and paste auf dieses formular machen.
ich hab hier eine richtige clickorgie wenn ich alle
fehlermeldungen wegglicken muss, die waehrend einer
sitzungen auftauchen.. das ist ganz heftiger frust....
bitte,bitte );-o
ich meld mich morgen wiedeer
schoenen abend auch
mfg nomad

[nomad]

hi,
bevor ich deine sachen gemacht habe,
hab ich mal auf dem zielrechner die urspruenglichen
_keys verwendet und mit allen berechtigungen (auch/.ssh/)
versehen die nur moeglich sind.
ergebnis wie gehabt. connection refused.
koennte es also am PubkeyAuthentication-eintrag liegen???
denn wenn der ausdokumentiert, geht die ganze choose
wieder (aber mit password).
der zielrechner ist ein suse 6.4.system

nun zu deinen sachen:
cd /root/
1) ssh-keygen -t dsa
== the same procedure as every year..
== /root/.ssh/id_dsa = exist == overwrite == yes
== your public key has been saved.... etc

soweit so gut:

2) ~/.ssh/id_dsa.pub 192.168.100.1:.ssh/authorized_keys
ergebnis:
ssh: connect to host 192.168.100.1 port 22: Connection
refused
lost connection
linux: ~ #

zu deiner no 3 komm ich also garnicht.

da der verbindungsaufbau ohne PubkeyAuthentications-eintrag
funzzt,(mit password)

schick ich dir jetzt mal einen auszug aus dem sshd_config-
file:
ein auszug deswegen weil bei mir auch kein attachment
funzzt, also alles schoen abtippen.
(suse 6.4 = zielrechner, quelle suse 9.0)
koennte es sein dass suse 6.4 ein anderes crypto-
verfahren hat also mit einem kleineren schluessel;
suse 9.0 = 1024????

== das hier sind eintraege die mir komisch vorkommen.
sshd_config:
HostKey /etc/ssh/ssh_host_key
ServerKeyBits 768PubkeyAuthentication
== PermitRootLogin yes
== PubkeyAuthentication yes (dieser war nicht vorhanden)
== StrictMode yes
== X11Forwarding yes
== RSAAuthentication yes
# to disable tunneled clear text passwords,
change to no here
== PasswordAuthentication yes
== PermitEmptyPasswords no

Kerberus ist alles ausdokumentiert

ps: noch ne ueberlegung,
laege in diesem file nicht die moeglichkeit,
die ganze sicherheit abzustellen,
du hast das mal in
einer deiner antworten gesagt dies waer aeussest unsicher
aber damit koennte ich sehr gut leben..

so bis spaeter
mfg nomad

[peschmae]

Durchaus möglich dass es da Probleme gibt weil das ne alte Version ist bei SuSE 6.4.

Was für ne Version ists denn?

MfG Peschmä

[nomad]

hi,
PC64 (suse 6.4)
- SSH Version OpenSSH-1.2.2 protokol Version 1.5

PC90 (suse 9.0)
- OpenSSH_3.7.1p2 SSH protokols 1.5/2.0
OpenSSL 0.9.7b 10 April 2003

also die protokolle koennten uebereinstimmen.

Bitte beantworten (telnet)
falls alle stricke reissen.
ich weiss dass das sehr unsicher ist...

folgende frage:
Wenn ich von PC90 als user telnet verwende,
zielrechner PC64 (only root-vorhanden)
muss da auf PC64 ein user vorhanden sein???
ich hab nur gelesen ???(finds im augenblick nicht) dass es nicht moeglich ist als root telenet zu starten, wie
sieht es auf der seite des zielrechners aus.
hab vor einigen tagen versucht, auf pc64 einen
user anzulegen(yast). ist aber in die hose gegangen.
haettest du da bitte tips fuer mich...

oder eben, moeglichkeit bei ssh die authentifkation
voellig abzustellen ???

danke,
mfg nomad

[peschmae]

1. Von Telnet hab ich keine ahnung
2. Ich glaube nicht dass man bei ssh das Zeugs einfach abstellen kann - genaueres weiss ich aber auch nicht

Da auf dem Server ssh wohl nur Protokollversion 1 unterstütz musst du RSA-Schlüssel verwenden, nicht DSA. (Hab ich eben in der Manpage gesehen)

1-ssh-keygen -t rsa
2- scp ~/.ssh/id_dsa.pub 192.168.100.1:.ssh/authorized_keys
3- ssh 192.168.100.1 "chmod 600 .ssh/authorized_keys

Die Datei bei 2- dürfte jetzt auch anders heissen - irgendwas mit rsa und pub im Namen halt. Kopieren musst du die Sache immer noch nach authorized_keys.

Eventuell soltlest du noch auf deinem Client-Pc in der /etc/ssh/ssh_config
Protocol 1,2
setzen oder ssh jeweils mit "ssh -1" starten.

MfG Peschmä

[nomad]

hi,

also vermutlich hab ich den fehler:

rein zufaellig hab ich meinen pc64 rechner beim
starten zu gesehen.
dann kam eine fehlermeldung betref.

-- PubkeyAuthentication -- Bad sshd_config 0ption.
break...
laeuft aber weiter.
also hat suse 6.4 etwas gegen diese option.
sobald ausdokumentiert neustart = keine fehlermeldung.
uups...

da waere dann noch die frage ob das mit dem RSA-schluessel
ueberhaupt funzzen wuerde, da vermutlich auch in diesem
fall Pubkeyauthentication verwendet wuerde.???

warte jetzt, was du meinst.

ich hab dir ja geschrieben, dass ich keinen user
(pc64) anlegen konnte.
kein wunder, wenn du bei suse -yast- startest um
einen neuen user anzulegen, wird im hintergrund
ein script adduser.local gestartet.
das war leer, ich frech, von suse 9.0 via nfs
das entsprechende file rueberkopiert, alles in butter,
inclusiv zugriff auf all meine entwicklungs-ordner.(root)
hi, darf alles kann alles.
gut jetzt dreht sich jeder admin im grabe um..
aber es geht, das ist die hauptsache. find ich.

zu telnet schade,
jedenfalls kann ich jetzt von beiden seiten mit telnet auf
die andere seite zugreifen.
nur: beim start alles ok (als user),
nur konnte ich dann telnet nicht beenden.
laut man telnet sollte das doch mit exit moeglich sein.
fragen ueber fragen.

also noch einen schoenen abend
mfg nomad