2015-08-21 13 views
5

voglio fare quanto segue:impostati manualmente le chiavi host SSH su un server/Digital Ocean Droplet

  1. Creare Ocean Digital gocce da mia macchina di sviluppo (per distribuire i miei test, che stanno prendendo troppo lungo).
  2. Emettere in modo sicuro un comando alla goccia.
  3. Distruggi la goccia.

Sono bloccato su # 2. Posso creare correttamente le gocce tramite l'API Digital Ocean e posso impostare la mia chiave SSH nell'area authorized_keys, ma se consento a Digital Ocean di creare la chiave, non ho modo di verificare la chiave pubblica del server.

Ora, se questo fosse all'interno dello stesso data center, non sarebbe un problema, dal momento che potrei fare affidamento su Digital Ocean non implementando un attacco MITM perché hanno comunque root, ma dal momento che mi sto connettendo dal mio sviluppo macchina Ho bisogno di un modo per fidarmi della chiave pubblica.

Ho provato in seguito a diverse guide cloud-init, ma ho sempre l'errore:

ssh [email protected] 
Connection closed by 178.62.69.133 

Ho cercato di eliminare ogni possibilità di errore, ho anche fatto ricorso alla codifica Base64 il privato chiave, pensando che potrebbe esserci qualche problema di fuga.

Questo è il comando che uso per creare le chiavi:

e = "ssh-keygen -t ecdsa-sha2-nistp256 -f #{loc} -q -N #{password} -C \"\"" 
system(e) 

che si espande a questo:

ssh-keygen -t ecdsa-sha2-nistp256 -f /tmp/testing-60f42fcf -q -N 77924d8f4fa12a365c8c003ca091f5ad6a2c4c22 -C "" 

Ho poi base64 codificare,

private_key = `base64 --wrap=0 #{loc}`.chomp 
public_key = `base64 --wrap=0 #{loc}.pub`.chomp 

e posizionarlo nel file yaml cloud-init (non volevo usare | perché è un personaggio speciale in Yaml, e io voluto evitare, se possibile):

#cloud-config 
--- 
runcmd: 
- echo test > /root/test 
- rm /etc/ssh/ssh_host* 
- echo LS0tLS1CRUdJTiBFQyBQUklWQVRFIEtFWS0tLS0tClByb2MtVHlwZTogNCxFTkNSWVBURUQKREVLLUluZm86IEFFUy0xMjgtQ0JDLEY3MDNDNzM1QTAxQzgyNEVBRjhCODA4NkVDREIyMjAwCgpiYlpCa3A2Ujcyd1RRNUsyL2w4QW9YU3FQNllRVjV0aVJETytmU1FqZTlEUjY4MG9wY3RCRGhKRWdPQ0prSkw1CmhOUGxydzUveHFwTHM5UXc3cWJaWlUvRHR0YnlxZTFWUDcyVHBRS1pFL2FDcTdGTWFpbFJrcUpFa3JobVdCcFEKbWtQTW15M3BwVFZZKzJvRDZTdmMzdzZyTW1JTlpKUkltRUxiUk81S2M4bz0KLS0tLS1FTkQgRUMgUFJJVkFURSBLRVktLS0tLQo= 
    > /tmp/base64_pri && base64 --decode /tmp/base64_pri > /etc/ssh/ssh_host_ecdsa_key 
- echo ZWNkc2Etc2hhMi1uaXN0cDI1NiBBQUFBRTJWalpITmhMWE5vWVRJdGJtbHpkSEF5TlRZQUFBQUlibWx6ZEhBeU5UWUFBQUJCQkVHSDJBS3BVcVE0NVZQWGNFK3h5NXV6elVnajhKelBxODJNaERLV0szaGltUVBReWRPQ0RlRVdyRVJzeCtUTEtPSjBlRElJWU9jT2RWT0FteHZycG1nPSAK 
    > /tmp/base64_pub && base64 --decode /tmp/base64_pub > /etc/ssh/ssh_host_ecdsa_key.pub 
- sleep 1 && service ssh restart 

(Non ti preoccupare, la chiave ssh/gocciolina è stata distrutta, questo è per scopi dimostrativi)

posso verificare che quando lascio il resto dei comandi eseguiti da echo test > /root/test. Ho anche provato questo sulla mia macchina locale e le md5sums partita:

028760a9374f9abd9c2c66eceb20f245 /tmp/pub_key_check 
028760a9374f9abd9c2c66eceb20f245 /tmp/testing-60f42fcf.pub 

2bf65516aaef01c731d061fa4ba788c5 /tmp/pri_key_check 
2bf65516aaef01c731d061fa4ba788c5 /tmp/testing-60f42fcf 

quindi so che li sto decodifica correttamente.

Ho provato altri tipi di chiavi, ma mi piacerebbe usare le chiavi ecdsa se possibile, perché è l'impostazione predefinita per le altre mie caselle. Cosa sto facendo di sbagliato qui? Inoltre, sono l'unico a farlo? Ho Google in giro e sembra che la risposta comune sia che le persone si fidano automaticamente della chiave pubblica generata che penso sia folle se si sta facendo questo cross data center poiché qualsiasi ISP casuale (o, nel mio caso, cafe) potrebbe passivamente MITM voi.

+2

Non esiste tipo 'ECDSA-SHA2-nistp256'. Nella pagina di manuale, c'è una selezione da '[-t dsa | ecdsa | ed25519 | rsa | rsa1] '(almeno sulla mia ubuntu). – Jakuje

+0

@Jakuje Grazie per l'idea, ma cambiare ti in 'ecdsa' o' rsa' non risolve il problema. – zachaysan

risposta

Problemi correlati