Fråga:
Hur kontrollerar jag om en SSH privat nyckel har lösenfras eller inte?
kung
2016-07-11 16:19:00 UTC
view on stackexchange narkive permalink

Låt oss säga att jag har tillgång till den privata delen av ett RSA-nyckelpar. Hur kan jag kontrollera om den här nyckeln har tillhörande lösenfras eller inte?

försöker använda den
@Ayozint Luta dig nu tillbaka och vänta på frågorna om hur du ställer in en dummy ssh-server för ändamålet, och hur man dödar en `ssh`-process i förtid från ett skript efter att ha matchat strängen och frågat efter ett lösenord.
Fyra svar:
gowenfawr
2016-07-11 17:21:10 UTC
view on stackexchange narkive permalink

Nyckelfilen har en annan rubrik om den är lösenordsskyddad. Här är toppen av en nyckel utan lösenfras: 

  ----- BEGIN RSA PRIVATE KEY ----- MIIEogIBAAKCAQEA3qKD / 4PAc6PMb1yCckTduFl5fA1OpURLR5Z + T4xY1JQt3eTM  
  ----- BEGIN RSA PRIVATE KEY ----- Proc-Type: 4, ENCRYPTEDDEK-Info: DES-EDE3 -CBC, 556C1115CDA822F5AHi / 3 ++ 6PEIBv4kfpM57McyoSAAaT2ECxNOA5DRKxJQ9pr2D3aUeMBaBfWGrxd / Q

Tyvärr fungerar det bara när man tittar på filerna. Jag vet inget sätt för en server att kunna berätta om nycklarna som presenteras för den var skyddade med en lösenfras, vilket är den mest användbara platsen för att kunna utnyttja den typen av information.

En lösning baserad på tidpunkten kan fungera.Vid en okrypterad nyckel skickas vanligtvis svaret direkt så snart servern skickar utmaningen, där det för en krypterad nyckel tar åtminstone några sekunder för användaren att ange lösenfrasen för att dekryptera nyckeln.
@AndreBorie, tyvärr kan inte klienten lita på.Normal användning kan inte ha någon fördröjning om en nyckelagent cachar (formulerad) nyckel, och en skadlig klient kan införa falska förseningar för att "efterlikna" låsa upp nyckeln ... Vi gick igenom samma sak för 20 år sedan med "timinganalys avlösenordsinmatning "på protokoll som telnet :)
Mer allmänt är kryptering av nyckeln en helt * klientsida * -operation.Om du vill veta att nyckeln är krypterad måste den leva och dekrypteras på serversidan.Men då har servern den dekrypterade privata nyckeln, som snarare besegrar poängen med asymmetrisk kryptografi.
Svaret är inte korrekt (längre).En priv-nyckel som inte visar rubrikerna "proc-type" och "DEK" kan mycket väl krypteras.
@GerardJP Jag tolkar svaret som att om 'proc-type' och 'DEK' rubrikraderna saknas är det inte lösenordsskyddat.Jag tror inte att det talar om huruvida något är krypterat eller inte.
Jakuje
2016-07-11 17:51:49 UTC
view on stackexchange narkive permalink

Det är inte alltid så enkelt som beskrivs i de andra svaren. Det fungerar bara med de gamla PEM-tangenterna. Ny openssh -format för tangenterna (genereras med alternativet -o , säkrare, eftersom openssh-6.5) ser likadant ut om du markerar rubrikerna: 

  $ huvudet rsa_enc ----- BEGIN OpenSSH privata nyckel ----- b3BlbnNzaC1rZXktdjEAAAAACmFlczI1Ni1jYmMAAAAGYmNyeXB0AAAAGAAAABCYdi7MhY $ huvudet rsa ----- BEGIN OpenSSH privata nyckel ----- b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAABFwAAAAdzc2gtcn

Det enklaste sättet i det här fallet är att köra någon operation på dem med ssh-keygen . Om den frågar efter en lösenfras har den en ( eller det är inte en ssh-nyckel), om den inte har en lösenfras: 

  $ ssh- keygen -yf rsa_encEnter lösenfras: $ ssh-keygen -yf rsassh-rsa AAAAB3NzaC1y ...

Kanske ännu bättre är följande exempel, eftersom det inte ber om inmatning :-P specificerar lösenfrasen som ska användas, en oskyddad nyckel öppnas med en tom lösenfras. 

  $ ssh-keygen -y -P "" -f rsa_encLoad key "path_to_key": felaktig lösenfras tillhandahålls för att dekryptera privat nyckel " $ ssh-keygen -y -P "" -f rsassh-rsa AAAAB3NzaC1y ...
Säkrare men mindre kompatibla: de uppfattade det faktum att den kända ASN.1-strukturen också var krypterad som underlättar brute-force-attackerna och lämnade därför standardlagringen för att skapa sitt eget lagringsformat där angriparen kan lita på ingen tidigare kändtext.Tack!
Base64-kodade data innehåller dock information om huruvida nyckeln är krypterad: Den första avkodar till `openssh-key-v1 ..... aes256-cbc .... bcrypt ......... v..` och den andra avkodas till `openssh-key-v1 ..... none .... none ................ ssh-`
@Random832 du har rätt.Tack.Men det är inte så uppenbart som i det första fallet där det är i ASCII.
Nåväl, base64 kartlägger alltid tre inmatade tecken till fyra utdatatecken, så det finns en chans att du kan upptäcka den kodade `non` eller` one` av `none ', beroende på vad den exakta förskjutningen för den strängen i filen är.
@UlrichSchwarz Eller? Nej och nej?för okända värden på?
Andra kommandot ska använda ett annat filnamn, som `rsa_dec`?
@immibis Ja.Fixat nu.Tack för anteckningen.Kopiera klistra in fel.Men poängen var nog tydlig.
Till den som undrar vad gör alternativet `-yf`: * -y: Det här alternativet kommer att läsa en privat OpenSSH-formatfil och skriva ut en OpenSSH offentlig nyckel till stdout *, och` f` står bara för filsökvägen.[källa] (https://linux.die.net/man/1/ssh-keygen)
Och 2018 (börjar med 7.8) är nu nytt format _default_ och `-o` behövs inte (du kan fortfarande bli gammal = OpenSSL-format förutom ed25519 med` -m pem`) FWIW PuTTY har sitt eget 'ppk' format(även text + base64, men inte PEM) med den andra raden som anger kryptering eller inte.
WhiteWinterWolf
2016-07-11 17:51:06 UTC
view on stackexchange narkive permalink

"RSA-nyckeln" är faktiskt en uppsättning värden som är lagrade som en ASN.1-struktur i det standardiserade DER-binära formatet och kodas sedan i bas-64 för att få den slutliga PEM-filen.

En mycket enkelt sätt att avgöra om en nyckel är kodad eller inte är helt enkelt att kontrollera om ASN.1-rubriken är närvarande, och detta är vanligtvis lika enkelt som att kontrollera om "nyckeln" börjar med bokstäverna MII som i exemplet nedan:

----- BEGIN RSA PRIVATE KEY -----
MII CWwIBAAKBgQCWxk9djtgA / t7n6M8g1d2fk3exyCSu1uubpxUkoFLJBKjLYiaa
[ ...]
eCrpRFHxhPICHI4db + I8GZ9QDmlbCN / bl3BBNNTn3w ==
----- SLUT RSA PRIVATE KEY -----

I lösenordsskyddade filer , eftersom hela ASN.1-strukturen är krypterad, visas allt som slumpmässiga tecken.

Men detta kan leda till falska positiva om den krypterade strängen också börjar med MII?
@Falco: Ja.På en praktisk basis är det till exempel en bra heuristik att snabbt kontrollera en uppsättning okända nycklar, men det enda sättet att ha 100% garanti om nyckelstatus (krypterad, skadad, etc.) är genom att använda metoden som tillhandahållsi Jakujes svar (`ssh-keygen -yf `).
Enklare _och_ robust: OpenSSL 'traditionellt' format PEM-nivå kryptering har två rubriker plus en tom rad före den krypterade & base64'ade data, som visas i gowenfawrs svar
santiagopim
2018-03-04 18:52:48 UTC
view on stackexchange narkive permalink

Privata nycklar ska skyddas, försöker ställa in lösenordet förklarar bara om det ännu är lösenordsskyddat. Med ssh-keygen på den skyddade nyckeln: 

  ~ / .ssh $ ssh-keygen -p -f id_rsa_password_protected Ange gammal lösenfras:

Och med inte skyddad: 

  ~ / .ssh $ ssh-keygen -p -f id_rsa_not_protected Ange ny lösenfras (tom utan lösenfras):

Så om det inte är lösenordsskyddat, bara ställ in lösenordet .



ⓘ
Denna fråga och svar översattes automatiskt från det engelska språket.Det ursprungliga innehållet finns tillgängligt på stackexchange, vilket vi tackar för cc by-sa 3.0-licensen som det distribueras under.
Loading...