SuSE und SSH, SFTP

Message

Jochen · #1 Post by **Jochen** » 10. Jul 2003 13:35

Hallo,
habe ein Problem mit SuSE 7.3 - 8.2 und SSH.
Für ein Script gesteuerten Sicherungsjob ist eine SSH bzw. SFTP-Verbindung zwischen zwei SuSE Rechner notwendig. Habe die Keys (ID_DSA und ID_RSA) erzeugt und in der authorized_Keys eingebunden. Die Verbindung klappt nur nach Eingabe der "passphrase". Wenn ich nach Einagbe von "eval `ssh-agent`" die Keys lade funktioniert das ganze während der gesamten Sitzung. Nach der Konsolenabmeldung und Neuanmeldung ist bei einer neuen SSH-Verbindung die Eingabe der "PASSPHRASE" bzw. das starten des AGENT mit Eingabe der PASSPHRASE notwendig.

Wie kann ich das umgehen?
Ist es möglich eine Verbindung, mit den hinterlegten Keys, ohne Eingabe der PASSPHRASE behaupt mögöich?

Danke in vorraus

ssh · #2 Post by **ssh** » 10. Jul 2003 21:08

ja ist es, auf prolinux gibt es einen artikel darüber wie man ssh konfiguriert... suchefunktion.....

es nennt sich rhost-authentifikation

Jochen · #3 Post by **Jochen** » 11. Jul 2003 11:12

Danke,
habe einen Artikel gefunden. Der dort beschriebene Befehl "make_ssh_known_hosts" habe ich auf SuSE 7.3 - 8.2 nicht gefunden.
Die Datei "ssh_known_hosts" ist nicht vorhanden.

Wie kann ich diese erzeugen?
Habe von den CD's alles installiert was sich auf OpenSSH bezieht.

Was habe ich vergessen?

Danke im vorraus

Michael · #4 Post by **Michael** » 11. Jul 2003 11:53

wenn Du beim Erzeugen der Keys keine
Passphrase eingibst, wird auch beim
Verbinden keine abgefragt. Dann funk-
tioniert der Verbindungsaufbau trans-
parent.

BTW: authorized_keys ist für Protokoll
Version 1, die nicht zu empfehlen ist.
Setze in der sshd_config Protocol auf
2 und benutze dann authorized_keys2.

Cheers

Michael

Michael · #5 Post by **Michael** » 11. Jul 2003 11:57

ssh_known_hosts wird vom SSH (nicht SSHD)
beim Login auf einen entfernten Rechner-
automatisch aufgebaut und beim wiederholten
Verbindungsaufbau zu Prüfung herangezogen,
ob sich dort der gleiche SSHD meldet.
(So kann zum Beispiel beim Arp-Spoofing
bemerkt werden, daß man sich an einem anderem
SSHD anmeldet)

Cheers

Michael

Michael · #6 Post by **Michael** » 11. Jul 2003 12:11

Einen hat er noch.

Statt den Abgleich mit SFTP durchzuführen
wäre doch in Betracht zu ziehen, das File-
system des entfernten Rechners via SSHFS
( http://shfs.sourceforge.net/ ) einfach
zu mounten.

Die aktuelle Ausgabe des Linux-Magazins
( http://www.linux-magazin.de/ ) hat einen
kurzen Artikel dazu.

Cheers

Michael

Jochen · #7 Post by **Jochen** » 11. Jul 2003 16:33

Hallo Michael,

die Idee beim Erzeugen des Keys keine passphrase einzugeben hat leider nicht funktioniert.
In diesem Fall fragt der Server das Root-Passwort ab.

Die SSH bzw SFTP-Verbindung wird durch ein Sicherungsscript nachts (wo ich schlafen möchte - muss auch mal sein) aufgebaut.

Muss hier eine verschlüsselte Verbindung ohne irgendwelche Passworteingaben aufbauen (geht durch eine Firewall in die DMZ) - und sicher(???) muss es sein.

Die ssh_known_hosts wurde beim händischen Verbindungsaufbau weder auf dem Server noch auf dem Client erzeugt.

Vielleicht habt Ihr noch eine Idee.

Danke im vorraus

Jetzt gehe ich erst mal ins Wochenende und am Monatg wird der Kampf wieder aufgenommen.

Michael · #8 Post by **Michael** » 14. Jul 2003 9:16

Probier mal

ssh -v name@host

Wenn so etwas kommt:

debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Trying private key: /root/.ssh/id_rsa
debug1: Offering public key: /root/.ssh/id_dsa
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: keyboard-interactive
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: password
myname@192.168.1.1's password:

dann hat die pubkey Anmeldung nicht funktioniert.

Isses so?

Cheers

Michael

Marc · #9 Post by **Marc** » 14. Jul 2003 18:25

Hi
http://www.google.de/search?q=ssh&ie=UT ... %3Dlang_de

steht auf ca. 10 Seiten, sogar in Deutscher Sprache, der Schlüssel muß nur exportiert werden.
Wie man das macht steht da ausführlich beschrieben.

Marc

ASD · #10 Post by **ASD** » 15. Jul 2003 10:52

Hallo Michael,
habe mal die Ausgabe von ssh -v root@host angefügt.

xxxxxxxxxxxx:~ # ssh -v root@xxx.xxx.xxx.xxx
OpenSSH_3.5p1, SSH protocols 1.5/2.0, OpenSSL 0x0090609f
2858: debug1: Reading configuration data /etc/ssh/ssh_config
2858: debug1: Applying options for *
2858: debug1: Rhosts Authentication disabled, originating port will not be trusted.
2858: debug1: ssh_connect: needpriv 0
2858: debug1: Connecting to xxx.xxx.xxx.xxx [xxx.xxx.xxx.xxx] port 22.
2858: debug1: Connection established.
2858: debug1: identity file /root/.ssh/xxxxx_rsa type 1
2858: debug1: identity file /root/.ssh/xxxxx_dsa type 2
2858: debug1: Remote protocol version 1.99, remote software version OpenSSH_3.5p1
2858: debug1: match: OpenSSH_3.5p1 pat OpenSSH*
2858: debug1: Enabling compatibility mode for protocol 2.0
2858: debug1: Local version string SSH-2.0-OpenSSH_3.5p1
2858: debug1: SSH2_MSG_KEXINIT sent
2858: debug1: SSH2_MSG_KEXINIT received
2858: debug1: kex: server->client aes128-cbc hmac-md5 none
2858: debug1: kex: client->server aes128-cbc hmac-md5 none
2858: debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent
2858: debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
2858: debug1: dh_gen_key: priv key bits set: 147/256
2858: debug1: bits set: 1580/3191
2858: debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
2858: debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
2858: debug1: Host 'xxx.xxx.xxx.xxx' is known and matches the RSA host key.
2858: debug1: Found key in /root/.ssh/known_hosts:4
2858: debug1: bits set: 1607/3191
2858: debug1: ssh_rsa_verify: signature correct
2858: debug1: kex_derive_keys
2858: debug1: newkeys: mode 1
2858: debug1: SSH2_MSG_NEWKEYS sent
2858: debug1: waiting for SSH2_MSG_NEWKEYS
2858: debug1: newkeys: mode 0
2858: debug1: SSH2_MSG_NEWKEYS received
2858: debug1: done: ssh_kex2.
2858: debug1: send SSH2_MSG_SERVICE_REQUEST
2858: debug1: service_accept: ssh-userauth
2858: debug1: got SSH2_MSG_SERVICE_ACCEPT
2858: debug1: authentications that can continue: publickey,password
2858: debug1: next auth method to try is publickey
2858: debug1: try pubkey: /root/.ssh/xxxxx_rsa
2858: debug1: input_userauth_pk_ok: pkalg ssh-rsa blen 149 lastkey 0x80967f8 hint 0
2858: debug1: PEM_read_PrivateKey failed
2858: debug1: read PEM private key done: type <unknown>
Enter passphrase for key '/root/.ssh/xxxxx_rsa':

Die Verbindung bau ich über IP und nicht über den Hastnamen auf.
Die Datei xxxxx_rsa und xxxxx_dsa habe ich auf Clientseite in der /etc/ssh/ssh_config definiert

Ich hoffe, das Du damit was anfangen kannst.

Danke

Michael · #11 Post by **Michael** » 15. Jul 2003 11:23

Hab das bei mir mal nachgestellt. Dabei hat
sich gezeigt, das Du auf dem Rechner, gegen
den Du Dich verbinden willst, beide ssh Protokolle
aktiviert hast.

Ändere bitte in der sshd_config des Zielrechner
den Eintrag:

Protocol 1,2

auf

Protocol 2

und starte den sshd dann mit "killall -HUP sshd" neu.

Dann kopierst Du vom Quellrechner als root

scp /root/.ssh/id_dsa.pub root@zielhost:/tmp/.

auf dem Zielrechner kommt dann als root

cat /tmp/id_dsa.pub > /root/.ssh/authorized_keys2

und

chmod 600 /root/.ssh/authorized_keys2
rm /tmp/id_dsa.pub

Jetzt sollte es eigentlich gehen.

Wenns imma noch hakt, nochmal den output von ssh -v posten.

Cheers

Michael

Michael · #12 Post by **Michael** » 15. Jul 2003 11:26

BTW: Wenn Du auf dem Zielrechner nicht alleine bist,
solltest Du mit der temporären Ablage von id_das.pub in /tmp
vorsichtig sein.

Cheers

Michael

ASD · #13 Post by **ASD** » 15. Jul 2003 12:06

Hat leider nichts gebracht, die Meldung ist die selbe.

Habe dann noch folgendes probiert:

in der sshd_config "Protocol 1,2" wieder eingestellt und
die Verbindung mit
ssh -2 -v root@xxx.xxx.xxx.xxx
und
ssh -1 -v root@xxx.xxx.xxx.xxx
probiert.

Bei ssh -2 kam die gleiche Meldung, bei ssh -1 die folgende:

xxxxxxxxxx:~ # ssh -1 -v root@xxx.xxx.xxx.xxx
OpenSSH_3.5p1, SSH protocols 1.5/2.0, OpenSSL 0x0090609f
3655: debug1: Reading configuration data /etc/ssh/ssh_config
3655: debug1: Applying options for *
3655: debug1: Rhosts Authentication disabled, originating port will not be trusted.
3655: debug1: ssh_connect: needpriv 0
3655: debug1: Connecting to xxx.xxx.xxx.xxx [xxx.xxx.xxx.xxx] port 22.
3655: debug1: Connection established.
3655: debug1: identity file /root/.ssh/xxxxx_dsa type 2
3655: debug1: Remote protocol version 1.99, remote software version OpenSSH_3.5p1
3655: debug1: match: OpenSSH_3.5p1 pat OpenSSH*
3655: debug1: Local version string SSH-1.5-OpenSSH_3.5p1
3655: debug1: Waiting for server public key.
3655: debug1: Received server public key (768 bits) and host key (1024 bits).
3655: debug1: Host 'xxx.xxx.xxx.xxx' is known and matches the RSA1 host key.
3655: debug1: Found key in /root/.ssh/known_hosts:7
3655: debug1: Encryption type: 3des
3655: debug1: Sent encrypted session key.
3655: debug1: cipher_init: set keylen (16 -> 32)
3655: debug1: cipher_init: set keylen (16 -> 32)
3655: debug1: Installing crc compensation attack detector.
3655: debug1: Received encrypted confirmation.
3655: debug1: Doing password authentication.
root@xxx.xxx.xxx.xxx's password:

Ich bin hier in der 5.Etage, vielleicht hilft es ja die Mühle über den Balkon zu halten (oder doch werfen???)

Vielen Dank für Deine Mühen

Gruss ASD (Jochen)

ASD · #14 Post by **ASD** » 15. Jul 2003 12:15

Nachtrag

Bei sftp -1 -v root@host
- gleiches wie ssh -1 u.s.w.
bei sftp root@host
- gleiches wie ssh -2 u.s.w.

bei sftp -2 u.s.w.
- illegal option -- 2

Gruss Jochen

Michael · #15 Post by **Michael** » 15. Jul 2003 12:47

Laß uns mal der Protokol 2-Variante bleiben!

Quellrechner ssh_config:

snip
----
PubkeyAuthentication yes
PasswordAuthentication yes
IdentityFile ~/.ssh/identity
IdentityFile ~/.ssh/id_rsa
IdentityFile ~/.ssh/id_dsa
Protocol 2
----
snap

Den ganzen Rest auf default (auskommentieren)

ls -la /root/.ssh

-rw------- 1 root root 668 Nov 14 2001 id_dsa
-rw-r--r-- 1 root root 599 Nov 14 2001 id_dsa.pub (Diese Datei an Zielrechner)
-rw-r--r-- 1 root root 9174 Apr 7 18:00 known_hosts
-rw-r--r-- 1 root root 604 Nov 6 2001 known_hosts2

Zielrechner:

sshd_config

snip
----
Protocol 2
PermitRootLogin yes (würde aber lieber anderen user nehmen)
PubkeyAuthentication yes
PasswordAuthentication yes
PermitEmptyPasswords no
X11Forwarding no
UsePrivilegeSeparation yes
Compression yes

Subsystem sftp /usr/local/libexec/sftp-server
----
snap

Rest auskommentieren (killall -HUP sshd)

ls -la /root/.ssh

-rw------- 1 root root 599 Jul 14 10:13 authorized_keys2
-rw------- 1 root root 668 Nov 15 2001 id_dsa
-rw-r--r-- 1 root root 598 Nov 15 2001 id_dsa.pub
-rw-r--r-- 1 root root 6092 Jul 3 08:57 known_hosts

und der Inhalt der authorized_keys2(Zielrechner)==id_dsa.pub (Quellrechner)

Abgleich, testen. Bitte jetzt nochmal Dein ssh -v

>Ich bin hier in der 5.Etage, vielleicht hilft es ja die Mühle über den Balkon zu halten (oder doch werfen???)

Schick' nen Foto, wenn's soweit kommen sollte :O)

Cheers

Michael

Pro-Linux

SuSE und SSH, SFTP

SuSE und SSH, SFTP

Re: SuSE und SSH, SFTP

Re: SuSE und SSH, SFTP

Re: SuSE und SSH, SFTP

Re: SuSE und SSH, SFTP

Re: SuSE und SSH, SFTP

Re: SuSE und SSH, SFTP

Re: SuSE und SSH, SFTP

Re: SuSE und SSH, SFTP

Re: SuSE und SSH, SFTP

Re: SuSE und SSH, SFTP

Re: SuSE und SSH, SFTP

Re: SuSE und SSH, SFTP

Re: SuSE und SSH, SFTP

Re: SuSE und SSH, SFTP