Für diejenigen von uns, die die SSHDas heißt, diejenigen von uns, die in ihrem täglichen Leben ständig auf Remotecomputer oder -server zugreifen müssen, haben es satt, die Eingabe von Passwörtern satt zu haben.
- Geben Sie ein Terminal ein: ssh user @ server
- Warten Sie einige Sekunden
- Der Server, auf dem wir eine Verbindung herstellen möchten, fragt nach dem Kennwort
- Sobald wir das Passwort eingegeben und die Eingabetaste gedrückt haben, greifen wir auf den Remote-Server zu
Und jetzt meine Frage, ist es nicht einfacher, nur zu tippen?
sshpass -p «PASSWORD» ssh root@servidor
Angenommen, der Benutzer ist Wurzelist der Server: Entwicklerdesdelinux. Net und das Passwort ist xunil ... dann wäre die Zeile:
sshpass -p xunil ssh root@dev.desdelinux.net
Um dies zu erreichen, müssen wir einfach das Paket installieren sshpassin Debian / Ubuntu oder Derivate wären mit Sudo apt-get sshpass installieren während in ArchLinux oder Derivate würden mit ausreichen sudo pacman -S sshpass
Wenn wir den Port angeben wollen (weil SSH nicht auf Port 22 ist) Wir fügen hinzu -p «PORT» ... das heißt, vorausgesetzt, es ist Port 9122:
sshpass -p xunil ssh root@dev.desdelinux.net -p 9122
Um das alles noch weiter zu vereinfachen Wir können Aliase erstellenWenn Sie beispielsweise Server1 ausführen, wird die gesamte Leitung ausgeführt, um eine Verbindung über SSH mit Server1 herzustellen (sshpass -p Passwort user @ server1) oder ähnliches, also sparen wir uns auch das Setzen einer zu langen Zeile 😉
Wie auch immer, ich hoffe, das hat Ihnen geholfen.
Eine andere Möglichkeit, um zu vermeiden, dass wir das Passwort schreiben müssen, wenn wir über SSH darauf zugreifen, ist die Verwendung von öffentliche und private Schlüssel.
Grüße
Ich entschuldige mich, aber das ist eine schreckliche Sicherheitsabweichung !! Sie haben das Passwort in Skripten, Nur-Text-Dateien, Bash-Verlauf usw. festgehalten.
Zu diesem Zweck unterstützt openssh die Authentifizierung mit öffentlichem Schlüssel mithilfe von RSA.
Dank dieser Art von Praxis (implementiert von Subjekten, die sich "Administratoren" nennen) gibt es so viel Computerunsicherheit.
Grüße.
Wir werden sehen. Ja, es ist ein Sicherheitsproblem, aber es bedeutet nicht, dass "Subjekte", die Administratoren sind oder nicht, diese Methode verwenden müssen. Die Methode ist vorhanden und wird angezeigt, falls sie in einer Umgebung verwendet werden muss, in der Sicherheit kein Problem darstellt. Im Laden, in dem sie dir das Messer verkaufen, entscheidest du, ob du damit Gemüse schneidest oder jemanden tötest.
Ich verstehe Ihre Position, aber es tut mir leid, dass sie in einem so bekannten Blog diese Art von Praxis fördern, es ist fast wie eine "Entschuldigung für die schreckliche Verwaltung von Systemen", hehe.
Eine Umarmung!
Ich verstehe immer noch nicht, wo das Problem liegt 🙁
Da wir in verschiedenen Aspekten davon gesprochen haben, "wie man mehr Sicherheit erhält", können wir auch von anderen "weniger sicheren" Themen sprechen. Unser Ziel ist es, die Informationen anzubieten. Es liegt an Ihnen, zu wissen, was Sie damit tun sollen. Darüber hinaus kann der Autor des paranoidesten Postens mit Sicherheit nicht sein, glauben Sie mir, wenn es um Systemadministration geht, tut er so etwas nicht.
Grüße 😉
Erstens, als ich sagte "implementiert von Themen, die sich" Administratoren "nennen", habe ich mich zu keinem Zeitpunkt auf den Autor des Artikels bezogen, ich verstehe nicht, warum sie so anfällig sind.
Das Problem ist aus meiner Sicht, dass dieses Tool gegen alle guten Sicherheitspraktiken verstößt. Ich glaube, dass wir von der GNU / Linux-Community unser wertvolles Betriebssystem so sicher wie möglich halten müssen. Ich meine, ich möchte nicht, dass GNU / Linux zu Windows wird (sicherheitstechnisch).
Leider gibt es viele unerfahrene Administratoren, die nicht wissen, wie sie richtig vorgehen sollen, und diese Tools auf kritischen Systemen verwenden.
Natürlich haben Sie das Recht zu veröffentlichen, was Sie wollen, aber ich wiederhole, es tut mir leid, dass dieser Blog (einer der wichtigsten in der spanischen Sprache) Tools Platz macht, die die Sicherheit bedrohen.
Greetings!
Und gib Juana mit dem Becken. Gerade weil es sich um ein Referenzblog handelt, möchten wir alle Arten von Informationen bereitstellen. Ich verstehe das:
Ein Benutzer kommt und fragt: Wie kann ich über SSH eine Verbindung zu einem Server herstellen, ohne nach dem Passwort zu fragen?
Sie antworten ihm in jedem Forum: Nein, das ist ein Sicherheitsproblem, das macht niemand.
Selbst wenn der Benutzer es weiß, sagt er ihm nicht, warum es sich um ein Sicherheitsproblem handelt. Schlecht, sehr schlecht, es ist gut, dass man weiß, wie man Dinge macht, deshalb in Desdelinux:
Ein Benutzer kommt und fragt: Wie kann ich über SSH eine Verbindung zu einem Server herstellen, ohne nach dem Passwort zu fragen?
Wir schreiben einen Beitrag und sagen: Sie können diese Methode verwenden, sie funktioniert auf diese Weise, ist jedoch NICHT SICHER. Am sichersten ist es, diesen anderen zu verwenden.
Welches ist deiner Meinung nach besser?
Okay, ich respektiere deine Haltung. Freundliche Grüße!!
SSHPass bedroht die Sicherheit nicht, die Person, die die Sicherheit auf jeden Fall bedroht, ist der Benutzer, der sie missbraucht.
Hier ist zum Beispiel ein hervorragendes Beispiel dafür, dass SSHPass nicht nur für das verwendet wird, was ich im Beitrag kommentiere, sondern auch zum (zum Beispiel) Knacken von OpenSSH-Server: http://paste.desdelinux.net/4810
Die Anwendung ist nichts anderes als das, eine Anwendung. Die Verwendung, die ihr gegeben wird, führt zu Fehlern, die die Sicherheit gefährden oder nicht.
In Bezug auf nervös oder anfällig war es vielleicht so, wie Sie es gesagt haben (oder dass das Lesen es schwierig macht, es richtig zu verstehen), aber ich habe interpretiert, dass der Kommentar an mich gerichtet war. Wenn es nicht so war, entschuldige ich mich.
PS: Sicherlich wird es einige geben, die das Skript finden, das ich interessant und sogar lustig gemacht habe. LOL!
Ok, ich bin froh, dass wir eine Einigung erzielt haben. Prost!!
Habe ich jemals gesagt, dass diese Methode sicherer ist als die Verwendung öffentlicher und privater Schlüssel?
In einem anderen Artikel habe ich bereits erläutert, wie man sie verwendet [1]. Jetzt erkläre ich einfach einen anderen Weg, um dasselbe oder ähnliches zu erreichen.
Jeder benutzt den, der am besten zu ihm passt, den, den er bevorzugt. Hier habe ich einfach eine der Verwendungsmöglichkeiten von sshpass erklärt, eine andere über ein Bash-Skript, um SSH mithilfe eines Wörterbuchs zu knacken ... aber komm schon, dies ist nur eine andere Verwendung.
Ich wiederhole, ich teile nur mein Wissen in Bezug auf GNU / Linux. SSHPass ist vielleicht nicht die ideale Wahl für jeden Fall, aber es ist nützlich, zögern Sie nicht.
Übrigens, bezogen auf: (implementiert von Themen, die sich "Administratoren" nennen) ... heh ... heh ... heh ... Ich möchte lieber keinen Kommentar abgeben, ich habe niemandem etwas zu beweisen, ganz zu schweigen davon, dass Ihr Freund von mir, Sie haben nicht die geringste Ahnung, wer ich bin, geschweige denn, was ich weiß 😉
[1] https://blog.desdelinux.net/ssh-sin-password-solo-3-pasos/
Seien Sie nicht nervös, es kommt vor, dass ich in meinem Bereich Leute kenne, die ihre Arbeit auf Google basieren und bei der Lösung von Problemen solche Dinge kopieren und einfügen. Dann ist der Sicherheitsadministrator derjenige, der "die Räder in das Rad setzt", wenn er diese Art von Anomalien entdeckt. Grüße!!
Entspann dich, Mann, es lohnt sich nicht 😉
Sicher, aber dann wird das Passwort in den verwendeten Befehlen registriert. Aus Sicherheitsgründen sollte dies nicht erfolgen ...
Das habe ich mir beim Lesen des Beitrags gedacht
Wenn Sie dies zu unserer .bashrc hinzufügen, werden die sshpass-bezogenen Befehle nicht gespeichert:
HISTIGNORE='sshpass *'Ich werde einen Beitrag darüber schreiben, wie man Befehle ignoriert, damit sie nicht in Kürze im Bash-Verlauf gespeichert werden :)
Eine andere Möglichkeit, Befehle nicht zu speichern, besteht darin, immer ein Leerzeichen vor dem Befehl zu setzen. ^ __ ^
Ich denke, es ist sicherer, Schlüssel zu verwenden, um eine Verbindung über SSH herzustellen, ohne das Passwort eingeben zu müssen.
Das Erstellen eines vollständigen Befehlsalias, in dem das Kennwort gespeichert wird, kann jedoch ein Sicherheitsproblem darstellen.
Wenn es mir ein Fehler in der Computersicherheit erscheint, wir aber sicherstellen werden, dass sie nicht in der Bash-Historie gespeichert werden, ist das nicht so sehr das Problem, das wir machen (mit Ausnahme eines Alias, der riesig wäre), auch als elav sagt im Laden verkaufen Sie uns das Messer, wir sind diejenigen, die sehen werden, was es zu verwenden ist
Interessant, aber ich verwende besser den öffentlichen und privaten Schlüssel, den Sie in einem anderen Eintrag gezeigt haben.
@ KZKG
Ich finde es praktischer - und sicherer! - Verwenden Sie RSA / ECDSA-Schlüssel zusammen mit einem Schlüsselbund (SSH-Agent) zur automatischen Authentifizierung.
In meinem Fall verwende ich einen SSH-Schlüsselbund für den Schlüsselbund, der von den Mitarbeitern von Funtoo entwickelt wurde. Er funktioniert sehr gut, verbraucht nur sehr wenige Ressourcen und ist sehr sicher:
http://www.funtoo.org/Keychain
Beispiel:
j:0 ~ > AliasSearch ssh
# SSH management
alias SSHCOPYIDecdsa='ssh-copy-id -i ~/.ssh/id_ecdsa.pub'
alias SSHCOPYIDrsa='ssh-copy-id -i ~/.ssh/id_rsa.pub'
alias SSHKEYGENecdsa='ssh-keygen -t ecdsa -b 521 -C "$(whoami)@$(hostname)-$(date -I)"'
alias SSHKEYGENrsa='ssh-keygen -t rsa -b 4096 -C "$(whoami)@$(hostname)-$(date -I)"'
Wie benutzt man:
SSHKEYGEN {ecdsa, rsa}
SSHCOPYID {ecdsa, rsa} user @ {server, ip}
# SSH servers
alias SERVER1mosh='eval $(keychain --eval --agents ssh -Q --quiet id_ecdsa) && mosh -p # usr1@server1'
alias SERVER1='eval $(keychain --eval --agents ssh -Q --quiet id_ecdsa) && ssh -v -p # usr1@server1.local'
alias SERVER101='eval $(keychain --eval --agents ssh -Q --quiet id_ecdsa) && ssh -v -p # usr1@[direc. ip].101'
Wo:
-p #: Port
usr1 @ server1: user @ AVAHI Server
usr1@server1.local: user @ AVAHI server (abhängig davon, wie der Server in einigen Systemen konfiguriert ist, muss das Suffix .local hinzugefügt werden)
usr1 @ [addr. ip] .101: feste IP-Adresse.
/ etc / ssh / sshd_config: http://paste.chakra-project.org/4974/
~ / .ssh / config: http://paste.chakra-project.org/4975/
Betriebssystem: Arch Linux / Chakra
Ich hoffe es dient dir, Grüße!
Tatsächlich verwende ich Schlüssel, nicht SSHPass, um auf meine Server zuzugreifen ... Ich habe SSHPass entdeckt, als ich eine Möglichkeit brauchte, dieses Skript auszuführen: http://paste.desdelinux.net/4810
Aber ... nun, ich wollte SSHPass mit allen teilen, aber offensichtlich konnte ich hier kein Skript einfügen, das es erlaubt, mithilfe eines Wörterbuchs zu versuchen, OpenSSH-Server HAHAHA zu verletzen!
«[…] Ich konnte hier kein Skript einfügen, mit dem mithilfe eines Wörterbuchs versucht werden kann, OpenSSH-Server HAHAHA zu verletzen!»
Aber warum nicht!!?
Gehört Hacking & Cracking nicht zum Erlernen guter Sicherheitspraktiken [0] !?
Bitte Mann, mach weiter !!!
[0] Ist es nicht schön, Wörter zu verwenden, um das genaue Gegenteil von dem zu bedeuten, was sie wörtlich bedeuten? Hack die Linguistik !!! ;-D
Hallo, ich bekomme diesen Fehler:
Es testet Passwörter für 192.168.20.11 an Port 22 mit dem Root-Benutzer
cat: con-letter.txt: Keine solche Datei oder kein solches Verzeichnis
die Datei mit Buchstaben.txt Ich erstelle sie?
Grüße
Dies geschieht nicht, da das Passwort in bash_history als Klartext gespeichert ist, abgesehen davon, dass es auf andere Weise herausgefunden werden könnte. Damit ssh Sie nicht nach einem Passwort fragt, ist der richtige Weg mit "öffentlichen und privaten Schlüsseln".
Ich verwende RSA, um eine Remoteverbindung zu meinen Servern herzustellen, auch wenn ich denke, dass die Verbindung zu einem Computer, auf dem wir keine so hohe Sicherheit benötigen, ein gutes Werkzeug ist, danke für den Tipp!
Chiuuu
Und warum nicht mein Passwort veröffentlichen, damit es für jedermann verfügbar ist?
Ausgezeichnet so gut !!!!!! und auf Spanisch.
Ausgezeichneter Artikel, wie immer beschweren sich die Leute, anstatt sich zu bedanken, obwohl die Methode unsicher ist, hängt es davon ab, wo und wie Sie sie verwenden. Vielen Dank 🙂