ComputerBase Menü
Aktuelles

welches Passwort bei Prompt "ssh root@192.168.x.x"?

Warning: unprotected priuvate key file ...too open
 
DaZpoon schrieb:
Der id_rsa sollte eigentlich der private key sein (anonsten meist Endung.pub).
Zum Vergrößern anklicken....
Da hast du natürlich Recht, dann liegt der privat Key in zwei Formaten vor. OpenSSH und Putty ppk.
Ergänzung ()

lnstinkt schrieb:
Warning: unprotected priuvate key file ...too open
Zum Vergrößern anklicken....
Das bedeutet nur, dass der Key nicht noch einmal mit einem Passwort gesichert ist, ist ok.
 
Falc410 schrieb:
Also in putty: Connection --> SSH --> Auth: Private Key File auswählen (unten auf Durchsuchen klicken)
Zum Vergrößern anklicken....
habe den .ppk-key mit PuttyGen in eine OpenSSH-Datei konvertiert und per USB-Stick auf den Pi gepackt, in denselben Ordner wie die anderen Keys, also

/home/pi/Downloads/keys/xyz

Resultat: Warning: unprotected private key file ...too open
this private key will be ignored
 
Mickey Mouse schrieb:
Das funktioniert so nicht, dafür muss der public Key erst auf das Zielsystem kopiert und konfiguriert werden, Huhn / Ei....
Zum Vergrößern anklicken....
So wie ich es hier rausgelesen habe, wird er ja beim Aufspielen der Firmware gefragt, ob SSH Keys erstellt werden sollen. Da gehe ich dann mal davon aus, das die dann auch direkt in die Firmware integriert werden. Anders wäre es ja auch Blödsinn, weil man dann das von die erwähnte Henne-Ei-Problem hätte.

Gerade mal im Sourecode des Image-Buildes nachgeguckt, und die Keys werden entsprechend ins Image kopiert.
Bash: 
echo "+ Generate SSH Host Keys if necessary"
if [ ! -r "${BASEDIR}/ssh_host_rsa_key" ]; then
    ssh-keygen -N "" -t rsa -f "${BASEDIR}/ssh_host_rsa_key"
fi
if [ ! -r "${BASEDIR}/ssh_host_dsa_key" ]; then
    ssh-keygen -N "" -t dsa -f "${BASEDIR}/ssh_host_dsa_key"
fi
if [ ! -r "${BASEDIR}/ssh_host_ecdsa_key" ]; then
    ssh-keygen -N "" -t ecdsa -f "${BASEDIR}/ssh_host_ecdsa_key"
fi
if [ ! -r "${BASEDIR}/ssh_host_ed25519_key" ]; then
    ssh-keygen -N "" -t ed25519 -f "${BASEDIR}/ssh_host_ed25519_key"
fi

echo "+ Replace ssh host keys"
mkdir -p "${IMG_DIR}/etc/ssh"
cat "${BASEDIR}/ssh_host_rsa_key" > "${IMG_DIR}/etc/ssh/ssh_host_rsa_key"
cat "${BASEDIR}/ssh_host_rsa_key.pub" > "${IMG_DIR}/etc/ssh/ssh_host_rsa_key.pub"
cat "${BASEDIR}/ssh_host_dsa_key" > "${IMG_DIR}/etc/ssh/ssh_host_dsa_key"
cat "${BASEDIR}/ssh_host_dsa_key.pub" > "${IMG_DIR}/etc/ssh/ssh_host_dsa_key.pub"
cat "${BASEDIR}/ssh_host_ecdsa_key" > "${IMG_DIR}/etc/ssh/ssh_host_ecdsa_key"
cat "${BASEDIR}/ssh_host_ecdsa_key.pub" > "${IMG_DIR}/etc/ssh/ssh_host_ecdsa_key.pub"
cat "${BASEDIR}/ssh_host_ed25519_key" > "${IMG_DIR}/etc/ssh/ssh_host_ed25519_key"
cat "${BASEDIR}/ssh_host_ed25519_key.pub" > "${IMG_DIR}/etc/ssh/ssh_host_ed25519_key.pub"

https://github.com/zvldz/vacuum/blob/master/builder_vacuum.sh#L303
 
Zuletzt bearbeitet:
und was heißt das jetzt?
 
Dass du dich beim Verbinden per SSH auch den generierten Private-Key nutzen musst.
 
genau, davon ging ich ja immer aus, aber WIE? konkret?
 
Die id_rsa ist eigentlich bereits der private key, also war die Umwandlung PPK->Private Key überflüssig, aber egal. Die unprotected-Meldung kommt evtl. auch durch zu offene Dateirechte. Read-Only reicht.

Bash: 
chmod 400 KEYFILE

Wen ssh klemmt, dann kann man mit
Bash: 
ssh -v root@....
schauen was es tut und meckert.
Ergänzung ()

Ich muss jetzt leider erstmal weg. Ich hoffe der Rest hier kriegt es gelöst, ansonsten musst du bis heute Abend noch von Hand staubsaugen ;-)
 
Zuletzt bearbeitet:
Ich hätte es, wie gesagt, einfach Mal mit PuTTY und der ppk Datei versucht... Das ist doch das einfachste?
 
DaZpoon schrieb:
Evtl. ist das Dateisystem dort sogar auf einem ROM, also read only. Nicht ungewöhnlich bei Firmwares.
Zum Vergrößern anklicken....
wie gesagt, deshalb funktioniert die von Andi_bz beschriebene/verlinkte Methode ganz sicher nicht. Egal ob da ein key Paar schon fest im ROM abgelegt oder bei der Erstellung des Images erstellt wurde. DAS wollte ich sagen.
 
Mickey Mouse schrieb:
Das funktioniert so nicht, dafür muss der public Key erst auf das Zielsystem kopiert und konfiguriert werden, Huhn / Ei....
Zum Vergrößern anklicken....
lnstinkt schrieb:
der Dateipfad existiert bei mir nicht. in /etc/ssh/ finden sich jedoch etwas.
Zum Vergrößern anklicken....
Mickey Mouse schrieb:
wie gesagt, deshalb funktioniert die von Andi_bz beschriebene/verlinkte Methode ganz sicher nicht. Egal ob da ein key Paar schon fest im ROM abgelegt oder bei der Erstellung des Images erstellt wurde. DAS wollte ich sagen.
Zum Vergrößern anklicken....
Mit den Infos, die Instink uns lieferte, bin ich von ein rPi ausgegangen. So funktioniert das natürlich nicht.

Habe mir gerade die Anleitung durchgelesen. Man könnte auch den eigenen SSH Public key angeben bei der Erstellung der Firmware.

@Instinkt Könntest du uns bitte genau beschreiben wie du vorgegangen bist? Hasst du den Flash Vorgang mit den rPi gemacht? Die Verbindung dann mit Windows?

lnstinkt schrieb:
Also, die mit dem Image heruntergeladenen keys waren in einer zip-Datei, die ich entpackt habe nach /home/pi/Downloads/keys/xyz ("xyz" als Platzhalter - wurde nicht von mir vergeben....sieht nach zufälligem Buchstabensalat aus und die key-Dateien heißen ebenfalls "xyz"

darin bedinden sich nun
  • xyz.id_rsa und
  • xyz.ppk
Zum Vergrößern anklicken....

lnstinkt schrieb:
habe den .ppk-key mit PuttyGen in eine OpenSSH-Datei konvertiert und per USB-Stick auf den Pi gepackt, in denselben Ordner wie die anderen Keys, also

/home/pi/Downloads/keys/xyz

Resultat: Warning: unprotected private key file ...too open
this private key will be ignored
Zum Vergrößern anklicken....
Ich lese hier raus, dass du dich mit dem rPi zum Roboter verbindest. Die Keys müssen ins /home/pi/.ssh/ Verzeichnis, wenn du beim rPi mit dem Benutzer pi angemeldet bist.
 
Zuletzt bearbeitet:
Hier der verbose log:

Code: 
pi@insti:~ $ ssh -vvv root@192.168.8.1
OpenSSH_8.4p1 Raspbian-5+b1, OpenSSL 1.1.1k  25 Mar 2021
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf matched no files
debug1: /etc/ssh/ssh_config line 21: Applying options for *
debug2: resolve_canonicalize: hostname 192.168.8.1 is address
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts' -> '/home/pi/.ssh/known_hosts'
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts2' -> '/home/pi/.ssh/known_hosts2'
debug2: ssh_connect_direct
debug1: Connecting to 192.168.8.1 [192.168.8.1] port 22.
debug1: Connection established.
debug1: identity file /home/pi/.ssh/id_rsa type -1
debug1: identity file /home/pi/.ssh/id_rsa-cert type -1
debug1: identity file /home/pi/.ssh/id_dsa type -1
debug1: identity file /home/pi/.ssh/id_dsa-cert type -1
debug1: identity file /home/pi/.ssh/id_ecdsa type -1
debug1: identity file /home/pi/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/pi/.ssh/id_ecdsa_sk type -1
debug1: identity file /home/pi/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file /home/pi/.ssh/id_ed25519 type -1
debug1: identity file /home/pi/.ssh/id_ed25519-cert type -1
debug1: identity file /home/pi/.ssh/id_ed25519_sk type -1
debug1: identity file /home/pi/.ssh/id_ed25519_sk-cert type -1
debug1: identity file /home/pi/.ssh/id_xmss type -1
debug1: identity file /home/pi/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.4p1 Raspbian-5+b1
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.3
debug1: match: OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.3 pat OpenSSH_6.6.1* compat 0x04000002
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to 192.168.8.1:22 as 'root'
debug3: hostkeys_foreach: reading file "/home/pi/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /home/pi/.ssh/known_hosts:1
debug3: load_hostkeys: loaded 1 keys from 192.168.8.1
debug3: order_hostkeyalgs: have matching best-preference key type ecdsa-sha2-nistp256-cert-v01@openssh.com, using HostkeyAlgorithms verbatim
debug3: send packet: type 20
debug1: SSH2_MSG_KEXINIT sent
debug3: receive packet: type 20
debug1: SSH2_MSG_KEXINIT received
debug2: local client KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,ext-info-c
debug2: host key algorithms: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,sk-ecdsa-sha2-nistp256-cert-v01@openssh.com,ssh-ed25519-cert-v01@openssh.com,sk-ssh-ed25519-cert-v01@openssh.com,rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-256-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,sk-ecdsa-sha2-nistp256@openssh.com,ssh-ed25519,sk-ssh-ed25519@openssh.com,rsa-sha2-512,rsa-sha2-256,ssh-rsa
debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug2: MACs ctos: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,zlib@openssh.com,zlib
debug2: compression stoc: none,zlib@openssh.com,zlib
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug2: peer server KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: host key algorithms: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ssh-ed25519
debug2: ciphers ctos: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: ciphers stoc: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: MACs ctos: hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: MACs stoc: hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: compression ctos: none,zlib@openssh.com
debug2: compression stoc: none,zlib@openssh.com
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug1: kex: algorithm: curve25519-sha256@libssh.org
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug3: send packet: type 30
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug3: receive packet: type 31
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:O2eF3dfxxxxxxxxxxxxxxxxxxxxx7VRSVdPmM
debug3: hostkeys_foreach: reading file "/home/pi/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /home/pi/.ssh/known_hosts:1
debug3: load_hostkeys: loaded 1 keys from 192.168.8.1
debug1: Host '192.168.8.1' is known and matches the ECDSA host key.
debug1: Found key in /home/pi/.ssh/known_hosts:1
debug3: send packet: type 21
debug2: set_newkeys: mode 1
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug3: receive packet: type 21
debug1: SSH2_MSG_NEWKEYS received
debug2: set_newkeys: mode 0
debug1: rekey in after 134217728 blocks
debug1: Will attempt key: /home/pi/.ssh/id_rsa
debug1: Will attempt key: /home/pi/.ssh/id_dsa
debug1: Will attempt key: /home/pi/.ssh/id_ecdsa
debug1: Will attempt key: /home/pi/.ssh/id_ecdsa_sk
debug1: Will attempt key: /home/pi/.ssh/id_ed25519
debug1: Will attempt key: /home/pi/.ssh/id_ed25519_sk
debug1: Will attempt key: /home/pi/.ssh/id_xmss
debug2: pubkey_prepare: done
debug3: send packet: type 5
debug3: receive packet: type 6
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug3: send packet: type 50
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
debug3: preferred gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /home/pi/.ssh/id_rsa
debug3: no such identity: /home/pi/.ssh/id_rsa: No such file or directory
debug1: Trying private key: /home/pi/.ssh/id_dsa
debug3: no such identity: /home/pi/.ssh/id_dsa: No such file or directory
debug1: Trying private key: /home/pi/.ssh/id_ecdsa
debug3: no such identity: /home/pi/.ssh/id_ecdsa: No such file or directory
debug1: Trying private key: /home/pi/.ssh/id_ecdsa_sk
debug3: no such identity: /home/pi/.ssh/id_ecdsa_sk: No such file or directory
debug1: Trying private key: /home/pi/.ssh/id_ed25519
debug3: no such identity: /home/pi/.ssh/id_ed25519: No such file or directory
debug1: Trying private key: /home/pi/.ssh/id_ed25519_sk
debug3: no such identity: /home/pi/.ssh/id_ed25519_sk: No such file or directory
debug1: Trying private key: /home/pi/.ssh/id_xmss
debug3: no such identity: /home/pi/.ssh/id_xmss: No such file or directory
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
root@192.168.8.1's password:
 
Danke fürs Verbose output.
Schau mal ob diese Datei "/home/pi/.ssh/id_rsa" an genau dem Pfad liegt (das ist der private key aus dem ZIP was du runtergeladen hast) und wie die Dateiberechtigungen sind:
Bash: 
ls -la /home/pi/.ssh/
 
Code: 
pi@insti:~ $ ls -la /home/pi/.ssh
insgesamt 16
drwx------  2 pi pi 4096 26. Dez 12:36 .
drwxr-xr-x 17 pi pi 4096 26. Dez 15:04 ..
-rw-------  1 pi pi 2602 26. Dez 12:36 KEYDATEI.id_rsa
-rw-r--r--  1 pi pi  222 25. Dez 14:05 known_hosts
pi@insti:~ $

"keydatei" ist ein Buchstaben- und Zahlenmix, den ich hier lieber nicht posten möchte, solange ich nichts davon verstehe...
 
Du siehst doch, dass er den Key nicht benutzt weil er eben keinen Standardnamen hat. Also als Parameter übergeben (-i pfadname)
 
Ich...verstehe nicht.

Sollte ich den Key umbenennen auf einen Standardnamen und wenn ja, welchen?
 
lnstinkt schrieb:
debug1: Trying private key: /home/pi/.ssh/id_rsa debug3: no such identity: /home/pi/.ssh/id_rsa: No such file or directory debug1: Trying private key: /home/pi/.ssh/id_dsa debug3: no such identity: /home/pi/.ssh/id_dsa: No such file or directory debug1: Trying private key: /home/pi/.ssh/id_ecdsa debug3: no such identity: /home/pi/.ssh/id_ecdsa: No such file or directory debug1: Trying private key: /home/pi/.ssh/id_ecdsa_sk debug3: no such identity: /home/pi/.ssh/id_ecdsa_sk: No such file or directory debug1: Trying private key: /home/pi/.ssh/id_ed25519 debug3: no such identity: /home/pi/.ssh/id_ed25519: No such file or directory debug1: Trying private key: /home/pi/.ssh/id_ed25519_sk debug3: no such identity: /home/pi/.ssh/id_ed25519_sk: No such file or directory debug1: Trying private key: /home/pi/.ssh/id_xmss debug3: no such identity: /home/pi/.ssh/id_xmss: No such file or directory
Zum Vergrößern anklicken....
entweder in einen von denen, oder du gibst den Key als Parameter an - macht man i.d.R. auch so.

Wurde schon 10x im Thread hier gesagt...

1640595314452.png
 
also

Code: 
ssh -i root@192.168.8.1

probieren?
 
der Standardname ist "id_rsa" (ohne irgendeine Endung) für den Private key und "id_rsa.pub" für einen Public Key. Kannst aber die Datei auch so lassen, wie sie aktuell heißt.

Der SSH Befehl zum Verbinden heißt dann
Bash: 
ssh -i ~/.ssh/KEYDATEI.id_rsa root@ip_vom_roboter

Lässt du das "-i ....." weg, versucht SSH den Key mit einem der Standardnamen zu benutzen.
 
nope, funktioniert leider nicht...fragt weiterhin nach PW
 
Du musst dich einloggen oder registrieren, um hier zu antworten.

Ähnliche Themen

Z
Internetfreigabe über WLAN (10.0.0.1) auf LAN (192.168.X.X)?
Antworten
6
Aufrufe
2.583
Z0CK3R
Z
H
Ziel IP Adresse 5.X.X.X als 192.168.X.X maskieren/Spitzname
Antworten
5
Aufrufe
1.988
BasCom
BasCom
Zurück
Oben

Willkommen auf ComputerBase!

Mit Werbung weiterlesen

Besuche ComputerBase wie gewohnt mit Werbung und Tracking. Die Zustimmung ist jederzeit widerrufbar.

Details im Privacy Center und in der Liste unserer Partner. Ein Widerruf ist möglich in der Datenschutzerklärung.

… oder ComputerBase Pro bestellen

Nutze ComputerBase ohne Werbebanner, Video-Ads und Werbetracking schon für 4 €/Monat oder 36 €/Jahr.

Mehr zu ComputerBase Pro

Bereits Pro-Nutzer? Hier anmelden.

Tracking: Wir und unsere 160 Partner verarbeiten personenbezogene Daten, indem wir mit auf Ihrem Gerät gespeicherten Informationen (z. B. eindeutige Kennungen in Cookies) ein Nutzungsprofil erstellen, um z. B. Anzeigen zu personalisieren. Verarbeitungszwecke: Genaue Standortdaten und Abfrage von Geräteeigenschaften zur Identifikation, Informationen auf einem Gerät speichern und/oder abrufen, Personalisierte Anzeigen und Inhalte, Anzeigen- und Inhaltsmessungen, Erkenntnisse über Zielgruppen und Produktentwicklungen.

Impressum Kontakt Datenschutz