Sto cercando di installare SSH senza password su un server Ubuntu con ssh-copy-id myuser@myserver, ma sto ottenendo l'errore:
Avvertenza: la chiave host ECDSA per "myserver" differisce dalla chiave per l'indirizzo IP "192.168.1.123"
Cosa sta causando questo e come posso risolverlo? Ho provato a eliminare la .sshdirectory sul computer remoto, ed eseguendo ssh-keygen -R "myserver"localmente, ma questo non risolve l'errore.
Risposte:
Rimuovere la chiave memorizzata nella cache per 192.168.1.123sul computer locale:
ssh-keygen -R 192.168.1.123
ssh-keyscan -t ecdsa my.server.domain >> ~/.ssh/known_hostsdopo che non è necessario verificare la nuova chiave all'inizio connettersi all'host.
Nel mio caso ssh-keygen -R ...non è stato corretto l'avviso. Ho avuto informazioni extra come questa:
Offending key for IP in /home/myuser/.ssh/known_hosts:8
Matching host key in /home/myuser/.ssh/known_hosts:24
Ho semplicemente modificato ~/.ssh/known_hostsed eliminato manualmente la riga 8 (la "chiave offensiva"). Ho provato a ricollegarmi, l'host è stato aggiunto in modo permanente e dopo tutto è andato bene!
sed -e '8d' /home/myuser/.ssh/known_hosts, sostituendo il numero di riga 8e il nome file con quelli visualizzati sul sistema.
known_hosts:8riferisce a un valore con indice zero o meno. Buono a sapersi che è una mappatura 1: 1 ...
ssh-keygen -R [hostname]:2022
~/.ssh/known_hosts, ricevo il messaggio che non è possibile stabilire l'autenticità e "Sei sicuro di voler continuare a connetterti". Rispondere "Sì" tenta e non riesce a connettersi. Se provo a connettermi una seconda volta, ottengo lo stesso errore della chiave host ECDSA con cui ho iniziato.
Faccio molte ricerche tra i miei computer LAN e i miei due account di web hosting, quindi ho risolto tutti i tipi di probabilità e termina con SSH, compresi i problemi di autenticazione ssh -vper vedere dove e cosa è andato storto.
Avendo appena risolto questo problema e non essere soddisfatto delle risposte, volevo davvero sapere "perché" me stesso ...
Il trigger per il mio caso è: installato il nuovo sistema operativo del server al lavoro e al momento dell'installazione del pacchetto openssh-server, un nuovo set di chiavi host è stato generato sul server di lavoro. In precedenza, tutti i miei sistemi operativi server erano Ubuntu e questa volta è cambiato in Debian (e sospetto che ci sia una differenza sfumata nelle autorizzazioni).
Quando tutti i sistemi operativi erano Ubuntu e reinstallo il sistema operativo di un server, al primo SSH, ottengo questo tipo di avviso, che preferisco rispetto all'avviso silenzioso sopra!
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
06:ea:f1:f8:db:75:5c:0c:af:15:d7:99:2d:ef:08:2a.
Please contact your system administrator.
Add correct host key in /home/user/.ssh/known_hosts to get rid of this message.
Offending key in /home/user/.ssh/known_hosts:4
RSA host key for domain.com has changed and you have requested strict checking.
Host key verification failed.
Quindi apro ~/.ssh/known_hostssul computer l'avvio di ssh, elimino quella riga, riconnetto e questo succede:
chris@home ~ $ ssh work
The authenticity of host '[work]:11122 ([99.85.243.208]:11122)' can't be established.
ECDSA key fingerprint is 56:6d:13:be:fe:a0:29:ca:53:da:23:d6:1d:36:dd:c5.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '[work]:11122 ([99.85.243.208]:11122)' (ECDSA) to the list of known hosts.
Linux rock 3.2.0-4-amd64 #1 SMP Debian 3.2.51-1 x86_64
Quel po ': 11122 è il numero di porta da cui instrado SSH sul firewall
Ho controllato i backup da un precedente server Ubuntu e ho fatto una differenza rispetto alla mia nuova installazione Debian:
Ubuntu: Debian:
# Package generated configuration file # Package generated configuration file
# See the sshd(8) manpage for details # See the sshd_config(5) manpage for details
# What ports, IPs and protocols we listen for # What ports, IPs and protocols we listen for
Port 22 Port 22
# Use these options to restrict which interface # Use these options to restrict which interfaces
#ListenAddress :: #ListenAddress ::
#ListenAddress 0.0.0.0 #ListenAddress 0.0.0.0
Protocol 2 Protocol 2
# HostKeys for protocol version 2 # HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key HostKey /etc/ssh/ssh_host_dsa_key
------------------------------------------------ HostKey /etc/ssh/ssh_host_ecdsa_key
#Privilege Separation is turned on for security #Privilege Separation is turned on for security
UsePrivilegeSeparation yes UsePrivilegeSeparation yes
Quindi sì, probabilmente, l'host ha iniziato a usare le chiavi ecdsa di recente, che di recente in base alle modifiche di Ubuntu, darei la colpa a un aggiornamento. Il passaggio di Ubuntu dal solido sistema operativo Linux su cui ho contato è il motivo per cui ho installato Debian questa volta.
Ho letto un security.SE q / a su ecdsa e ho già rimosso quella riga dal sshd_configmio nuovo server Debian. (e corse service ssh restart)
ubuntu debian servere vedrai cosa intendo.
Il prompt si verifica ogni volta perché gli indirizzi IP cambiano continuamente quando si utilizza l'indirizzamento dinamico. Prova a utilizzare l'IP statico, quindi devi aggiungere la chiave solo una volta.
ssh-keygen -f "/root/.ssh/known_hosts" -R 192.168.1.123
Questo dovrebbe sostituire le chiavi esistenti in known_hosts.old e crearne una nuova. Questa soluzione ha funzionato per me nello stesso scenario
Ho aggiunto le seguenti righe al mio ~ / .ssh / config, disabilitando così il controllo rigoroso dell'host per tutti gli indirizzi .local. (con l'assegnazione dell'indirizzo DHCP, gli indirizzi IP dei miei computer locali cambiano sempre)
host *.local
StrictHostKeyChecking no
Ricevi comunque l'avvertimento, che per me va bene.
Stai usando lo stesso utente per la connessione?
Se si è connessi a un PC locale come l'utente John e si è connessi al server B come l'utente Adolf @ B e tutto è OK, ciò non significa che tutto sia OK se si è connessi al PC locale come l'utente Jane e ci si connette al server B come utente Adolf @ B .
Se si desidera accedere al server B come utente Beda dal PC A senza password, provare questo comando, tutto dal PC A :
ssh-keygen -t rsa
Questo comando genera la chiave e memorizza la chiave nel file. Si prega di lasciare la passphrase vuota.
ssh Beda@B mkdir -p .ssh
Questo comando crea la directory, se non esistono già. Altrimenti, non stampare un messaggio di errore.
cd ~/.ssh
Questo comando modifica la directory nella home directory degli utenti ./ssh.
cat id_rsa.pub | ssh Beda@B 'cat >> .ssh/authorized_keys'
Questo comando stampa il file id_rsa.pub (la tua chiave pubblica) in authorized_keys sul server.
IMPORTANTE: Beda è il tuo nome utente sul server a cui ti stai connettendo, B è l'IP del tuo server.
Ora puoi connetterti al server B senza password o passphrase:
ssh Beda@B
Il thread qui può aiutare.
In sostanza, si desidera rimuovere entrambe le chiavi RSA ed ECDSA per quell'host, quindi utilizzarle ssh-keyscanper reinserirle nel known_hostsfile in modo da non causare questo conflitto. Ha funzionato per me quando ho avuto lo stesso problema.
Domanda: Cosa sta causando questo, ...?
Quindi la chiave host del server ssh è cambiata. Cosa ha causato il cambiamento? È difficile da dire. Ecco alcune ipotesi:
Domanda: ... e come posso ripararlo?
Come altri hanno già risposto, rimuovere la chiave host ECDSA memorizzata nella cache per myserver che il proprio account ha memorizzato nella cache.
Questo errore mi ha infastidito per molto tempo. Per qualche ragione ha fatto la differenza se avrei fatto un
ssh host
o
ssh host.domain
https://askubuntu.com/questions/87449/how-to-disable-strict-host-key-checking-in-ssh
quindi mi ha indicato l'opzione di modificare il file di configurazione. Vedi il mio script https://askubuntu.com/a/949731/129227 lì per automatizzare il processo.
CanonicalizeHostnamee CanonicalDomainspermetterebbe di evitare la rimozione di controllo rigoroso e renderebbe ssh considerare host e host.domain ad essere lo stesso.
L'ho risolto su un Chromebook disinstallando e reinstallando Secure Shell ... Funzionava come un fascino.
Ecco come rimuovere un'impronta digitale host nota (dal known_hostsfile) su un sistema operativo Chrome:
Trova l'indice della voce host offensiva nell'output ssh quando la connessione non riesce. Ad esempio, nella riga sotto l'indice offensivo è 7 :
Offending ECDSA key in /.ssh/known_hosts:7
Aprire la console JavaScript ( CTRL+ Shift+ J) della finestra Secure Shell e digitare quanto segue, sostituendolo INDEXcon il valore appropriato (ad esempio 7 ):
term_.command.removeKnownHostByIndex(INDEX);
Questa soluzione è stata presa in prestito dal Blog di Leo Gaggl .
The ECDSA host key for server has changed. La mia strada è rimuovere la stringa di cache relativa sul dominio in~/.ssh/known_hosts. Quindi funziona ssh.