Voor degenen onder ons die de SSH, dat wil zeggen, degenen onder ons die constant toegang moeten hebben tot externe computers of servers in ons dagelijks leven, krijgen het punt dat ze genoeg hebben van het typen van wachtwoorden, het zou zijn:
- Toets een terminal in: ssh user @ server
- Wacht een paar seconden
- De server waarmee we verbinding willen maken, zal om het wachtwoord vragen
- Zodra we het wachtwoord hebben ingevoerd en op [Enter] hebben gedrukt, zullen we toegang krijgen tot de externe server
En nu mijn vraag, is het niet eenvoudiger om gewoon te typen ?:
sshpass -p «PASSWORD» ssh root@servidor
Stel dat de gebruiker dat is wortel, de server is: ontwikkelaardesdelinux.net en het wachtwoord is xunil ... dan zou de regel zijn:
sshpass -p xunil ssh root@dev.desdelinux.net
Om dit te bereiken, hoeven we alleen maar het pakket te installeren sshpass, en Debian / Ubuntu of derivaten zouden zijn met sudo apt-get installeer sshpass ondertussen in ArchLinux of derivaten zouden volstaan met sudo pacman -S sshpass
Als we de poort willen specificeren (omdat SSH niet op poort 22 staat) we voegen toe -p «POORT» ... dat wil zeggen, ervan uitgaande dat het poort 9122 is:
sshpass -p xunil ssh root@dev.desdelinux.net -p 9122
Om dit allemaal nog meer te vereenvoudigen we kunnen aliassen makenAls u bijvoorbeeld server1 uitvoert, wordt de hele regel uitgevoerd om via SSH verbinding te maken met server1 (sshpass -p wachtwoord gebruiker @ server1) of iets dergelijks, dus we besparen ook het plaatsen van een te lange regel 😉
Hoe dan ook, ik hoop dat dit nuttig voor je is geweest.
Een andere manier om te voorkomen dat u het wachtwoord moet schrijven wanneer we toegang krijgen via SSH, is door openbare en privésleutels.
groeten
Mijn excuses, maar dit is een vreselijke veiligheidsafwijking !! Je hebt het wachtwoord vastgezet in scripts, platte tekstbestanden, bash-geschiedenis, enz.
Daarvoor ondersteunt openssh authenticatie met openbare sleutels met behulp van RSA.
Dankzij dit soort praktijken (geïmplementeerd door proefpersonen die zichzelf "beheerders" noemen) is er zoveel computeronzekerheid.
Groeten.
Laten we zien. Ja, het is een beveiligingsprobleem, maar het betekent niet dat "subjecten" die beheerders zijn of deze methode niet hoeven te gebruiken. De methode bestaat en wordt weergegeven voor het geval deze moet worden gebruikt in een omgeving waar beveiliging geen probleem is. In de winkel verkopen ze je het mes, jij beslist of je er groente mee snijdt of iemand vermoordt.
Ik begrijp uw standpunt, maar het spijt me dat ze in een blog met zo'n faam dit soort praktijken promoten, het is bijna als een "verontschuldiging voor het vreselijke systeembeheer" hehe.
Een knuffel!!
Ik begrijp nog steeds niet wat het probleem is 🙁
Aangezien we ook hebben gesproken over "hoe u meer veiligheid kunt krijgen" in verschillende aspecten, kunnen we ook praten over andere "minder veilige" onderwerpen. Ons doel is om de informatie aan te bieden, het is aan jou om te weten wat je ermee moet doen. Bovendien kan de auteur van de meest paranoïde post over beveiliging, geloof me, dit soort dingen niet zijn als het gaat om systeembeheer.
Met vriendelijke groet 😉
Ten eerste, toen ik zei 'uitgevoerd door proefpersonen die zichzelf "beheerders" noemen, verwees ik op geen enkel moment naar de auteur van het artikel, ik begrijp niet waarom ze zo vatbaar zijn.
Het probleem, vanuit mijn standpunt, is dat deze tool in strijd is met alle goede beveiligingspraktijken. Ik geloof dat we vanuit de GNU / Linux-gemeenschap ons kostbare besturingssysteem zo veilig mogelijk moeten houden. Ik bedoel, ik zou niet willen dat GNU / Linux wordt omgezet in Windows (qua beveiliging).
Helaas zijn er veel beginnende beheerders die de juiste manier om dingen te doen niet weten en deze tools uiteindelijk op kritieke systemen gebruiken.
Natuurlijk heb je het recht om te publiceren wat je wilt, maar ik herhaal, het spijt me dat deze blog (een van de belangrijkste in de Spaanse taal) plaats geeft aan tools die de veiligheid bedreigen.
Groeten!
En geef Juana met het bekken. Juist omdat het een referentieblog is, geven we graag allerlei informatie. Ik begrijp dit:
Een gebruiker arriveert en vraagt: Hoe kan ik via SSH verbinding maken met een server zonder om het wachtwoord te vragen?
Ze beantwoorden hem in elk forum: Nee, dat is een beveiligingsprobleem, niemand doet dat.
Zelfs als hij het weet, vertelt de gebruiker hem niet waarom het een beveiligingsprobleem is. Slecht, heel slecht, het is goed dat je weet hoe je dingen moet doen, daarom in Desdelinux:
Een gebruiker arriveert en vraagt: Hoe kan ik via SSH verbinding maken met een server zonder om het wachtwoord te vragen?
We schrijven een bericht en zeggen: U kunt deze methode gebruiken, het werkt op deze manier, maar het IS NIET VEILIG. Het veiligste is om deze andere te gebruiken.
Welke is volgens jou beter?
Oké, ik respecteer je houding. Vriendelijke groeten!!
SSHPass vormt eigenlijk geen bedreiging voor de beveiliging, de persoon die de beveiliging bedreigt is in ieder geval de gebruiker die er misbruik van maakt.
Hier is bijvoorbeeld een uitstekend voorbeeld dat SSHPass niet alleen wordt gebruikt voor wat ik in de post becommentarieer, het kan ook worden gebruikt voor (bijvoorbeeld) het kraken van OpenSSH-Server: http://paste.desdelinux.net/4810
De applicatie is niets meer dan dat, een applicatie, het gebruik dat eraan wordt gegeven, zal storingen veroorzaken die de beveiliging in gevaar brengen of niet.
Wat betreft nerveus of vatbaar, helemaal niet, misschien was het de manier waarop je het zei (of die lezing maakt het moeilijk om het correct te begrijpen), maar ik interpreteerde dat de opmerking tegen mij was gericht, als dat niet zo was, bied ik mijn excuses aan.
PS: er zullen er vast wel meerdere zijn die het script dat ik heb geplaatst interessant en zelfs grappig zullen vinden LOL!
Oké, ik ben blij dat we een akkoord hebben bereikt. Proost !!
Heb ik ooit gezegd dat deze methode veiliger is dan het gebruik van openbare en privésleutels?
In een ander artikel deelde ik al hoe je ze moet gebruiken [1], nu leg ik gewoon een andere manier uit om hetzelfde of iets dergelijks te bereiken.
Iedereen gebruikt degene die het beste bij hen past, degene die ze verkiezen. Hier heb ik simpelweg een van de toepassingen uitgelegd die aan sshpass kunnen worden gegeven, een andere zou via een Bash-script kunnen zijn om SSH te kraken door het gebruik van een woordenboek ... maar kom op, dit is gewoon een ander gebruik.
Ik herhaal, ik deel alleen mijn kennis met betrekking tot GNU / Linux. SSHPass is misschien niet de ideale keuze voor elk geval, maar het heeft nut, aarzel niet.
Trouwens, verwijzend naar: (geïmplementeerd door onderwerpen die zichzelf "beheerders" noemen) ... heh ... heh ... heh ... ik geef er de voorkeur aan om geen commentaar te geven, ik heb niets te bewijzen aan iemand, om nog maar te zwijgen van het feit dat uw vriend van mij, je hebt geen idee van wie ik ben, veel minder dan ik weet 😉
[1] https://blog.desdelinux.net/ssh-sin-password-solo-3-pasos/
Wees niet zenuwachtig, het komt voor dat ik in mijn vakgebied mensen ken die hun werk op Google baseren en bij het oplossen van problemen dit soort dingen kopiëren en plakken. Dan is de beveiligingsbeheerder degene die "de wielen in het wiel steekt" wanneer hij dergelijke afwijkingen detecteert. Proost !!
Relax man, het is het niet waard 😉
Natuurlijk, maar dan wordt het wachtwoord geregistreerd in de gebruikte commando's. Om veiligheidsredenen mag dit niet worden gedaan ...
Dat is wat ik dacht toen ik de post las
Als je dit toevoegt aan onze .bashrc, worden de sshpass-gerelateerde commando's niet opgeslagen:
HISTIGNORE='sshpass *'Ik zal een bericht plaatsen over het negeren van opdrachten, zodat ze niet binnenkort in de bash-geschiedenis worden opgeslagen :)
Een andere manier om opdrachten niet op te slaan, is door altijd een spatie voor de opdracht te plaatsen. ^ __ ^
Ik denk dat het veiliger is om sleutels te gebruiken om verbinding te maken via SSH zonder het wachtwoord in te voeren.
Aan de andere kant kan het een beveiligingsprobleem zijn om een volledige opdrachtalias te maken waar het wachtwoord wordt opgeslagen.
Als het mij een tekortkoming lijkt in de computerbeveiliging, maar we ervoor gaan zorgen dat ze niet worden opgeslagen in de bash-geschiedenis, is dat niet zozeer het probleem dat we doen (behalve een alias die enorm zou zijn), ook als elav zegt in de winkel ons het mes te verkopen, wij zijn degenen die zullen zien wat ze moeten gebruiken
Interessant, maar gebruik beter de openbare en privésleutel die je in een ander item hebt laten zien.
@KZKG
Ik denk dat het praktischer is - en veiliger! - gebruik RSA / ECDSA-sleutels samen met een sleutelhanger (SSH-agent) voor automatische authenticatie.
In mijn geval gebruik ik een SSH-sleutelhanger voor Keychain, ontwikkeld door de mensen van Funtoo, die heel goed werkt, zeer weinig bronnen gebruikt en zeer veilig is:
http://www.funtoo.org/Keychain
voorbeeld:
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)"'
Hoe te gebruiken:
SSHKEYGEN {ecdsa, rsa}
SSHCOPYID {ecdsa, rsa} gebruiker @ {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'
Waar:
-p #: poort
usr1 @ server1: gebruiker @ AVAHI server
usr1@server1.local: user @ AVAHI-server (afhankelijk van hoe de server in sommige systemen is geconfigureerd, moet het achtervoegsel .local worden toegevoegd)
usr1 @ [addr. ip] .101: vast ip-adres.
/ etc / ssh / sshd_config: http://paste.chakra-project.org/4974/
~ / .ssh / config: http://paste.chakra-project.org/4975/
Besturingssysteem: Arch Linux / Chakra
Ik hoop dat het je van dienst is, groeten!
In feite gebruik ik sleutels, niet SSHPass om toegang te krijgen tot mijn servers ... Ik ontdekte SSHPass toen ik een manier nodig had om dit script te doen: http://paste.desdelinux.net/4810
Maar ... nou, ik wilde SSHPass met iedereen delen, maar ik kon hier natuurlijk geen script plaatsen dat het gebruik van een woordenboek toestaat om OpenSSH-Server HAHAHA te schenden!
"[…] Ik kon hier geen script plaatsen dat het gebruik van een woordenboek toestaat om OpenSSH-Server HAHAHA te schenden!"
Maar waarom niet!!?
Maakt hacken en kraken geen deel uit van het aanleren van goede beveiligingspraktijken [0]!?
Alsjeblieft man, ga je gang !!!
[0] Is het niet mooi om woorden te gebruiken die precies het tegenovergestelde betekenen van wat ze letterlijk betekenen!? Hack de taalkunde !!! ;-D
Hallo, ik krijg deze foutmelding:
Het test wachtwoorden tot 192.168.20.11 op poort 22 met de rootgebruiker
cat: con-letters.txt: bestand of directory bestaat niet
het bestand met letters.txt Ik maak ze?
groeten
Dit wordt niet gedaan, aangezien het wachtwoord in bash_history wordt opgeslagen als platte tekst, behalve dat het op een andere manier kan worden achterhaald. Zodat ssh je niet om een wachtwoord vraagt, is de juiste manier met "publieke en private sleutels".
Ik gebruik RSA om op afstand verbinding te maken met mijn servers, maar toch denk ik dat het een goed hulpmiddel is om verbinding te maken met een computer waar we niet zo'n sterke beveiliging nodig hebben, bedankt voor de tip!
Chiuuuu
En waarom kan ik mijn wachtwoord beter niet publiceren, zodat het voor iedereen beschikbaar is?
Uitstekend zo goed !!!!!! en in het Spaans.
Uitstekend artikel, zoals altijd klagen mensen in plaats van te bedanken, hoewel de methode onzeker is, hangt het af van waar en hoe je het gebruikt, heel erg bedankt 🙂