ssh si blocca senza la richiesta della password - funziona su root o altri account

Ho avuto l'accesso basato su chiave SSH che funziona bene. Quindi, ho cambiato il nome host sul mio computer e l'accesso basato su chiave ha smesso di funzionare. Sembrava avere senso. le chiavi probabilmente si basavano sul mio vecchio nome host. Quindi, ho cancellato tutte le mie chiavi e tutti i file in ~ / .ssh / e li ho rigenerati (e ho cambiato le chiavi autorizzate sui server a cui mi collego)

Ora, ogni volta che provo a ssh, si blocca semplicemente senza la richiesta della password, non importa dove io stia provando a ssh - anche i server in cui non ho configurato l'accesso basato su chiave. Non c'è nulla in .ssh / config.

Inoltre, quando "su -" eseguo il root, ssh funziona perfettamente. nessun problema. Questo succede solo sul mio account utente.

Di seguito sono riportate alcune informazioni di debug da ssh

ssh -vv mylogin@myremoteserver.com
OpenSSH_5.2p1, OpenSSL 0.9.8k 25 mar 2009
debug1: lettura dei dati di configurazione /Users/myname/.ssh/config
debug1: lettura dei dati di configurazione / usr / etc / ssh_config
......
debug1: l'host "myremoteserver.com" è noto e corrisponde alla chiave host RSA.
debug1: chiave trovata in /Users/myname/.ssh/known_hosts:1
debug2: bit impostati: 512/1024
debug1: ssh_rsa_verify: firma corretta
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS inviato
debug1: attesa SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS ricevuto
debug1: SSH2_MSG_SERVICE_REQUEST inviato
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT ricevuto

E poi si blocca qui .....

Ecco l'output di dtruss (come strace ma per OSX) vicino alla fine dove si blocca: sudo dtruss ssh -vv mylogin@myremoteserver.com

seleziona (0x4, 0x508200, 0x0, 0x0, 0x0) = 1 0
leggi (0x3, "$ \ 222 \ 351 {L \ 363 \ 261 \ 25063sN \ 216 \ 300 @ q7 \ 203 \ 276b \ 257 \ 354 \ 337 \ 356 \ 260! {\ 342 \ 017 \ 271 = \ 222, \ 245 \ 347t \ 006 \ 225 \ 257 \ 333; \ 204 \ 020] \ 242 \ 005z # \ 0 ", 0x2000) = 48 0
write (0x2, "debug2: service_accept: ssh-userauth \ r \ n \ 0", 0x26) = 38 0
connect (0x4, 0xBFFFEEA2, 0x6A) = 0 0
write (0x4, "\ 0", 0x4) = 4 0
write (0x4, "\ v5 \ 004 \ 0", 0x1) = 1 0
read (0x4, "\ 0", 0x4) = -1 Err # 4

Sembra che stia provando a leggere qualcosa e si blocca su questo. Se qualcuno ha qualche suggerimento o idea, sarei molto grato!

Il motivo per cui il tuo client ssh si blocca per il tuo account ma non per altri account (root) è probabilmente perché c'è qualcosa di sbagliato nel tuo agente ssh. O che ssh-agentnon è in esecuzione o che la sua configurazione è errata in qualche modo.

Per avere una conferma di ciò, puoi provare quanto segue:

unset SSH_AUTH_SOCK
ssh mylogin@myremoteserver.com

Se ti viene chiesto di inserire la passphrase su ssh_key significa che hai un problema con il tuo ssh-agent.

Vedi anche il mio post su questa domanda correlata .

Posso interessarti al DNS inverso?

In sostanza, il client sta eseguendo il DNS inverso sul server o viceversa.

Propongo un test:

Disabilitare le ricerche DNS sul server modificando / etc / ssh / sshd_config e accertandosi che "UseDNS" sia impostato su "no".

Esegui "service ssh reload" (o qualunque altra cosa induca il tuo demone ssh a rileggere la configurazione), quindi riprova.

Per inciso, non è felice di chiederti finalmente dopo un lungo periodo di tempo, vero?

Un'altra cosa che potresti controllare è guardare il contenuto di / etc / hosts sul server per assicurarti che non ci sia nulla di sbagliato.

Controlla le autorizzazioni sulla directory ~ / .ssh e i file in essa contenuti. Il tuo umask predefinito potrebbe essere troppo permissivo e quando hai ricreato i file potresti aver inavvertitamente dato loro le autorizzazioni sbagliate. Sono stato bruciato da questo alcune volte me stesso. Nessuno dei client (o server) SSH che ho usato ha mai dato un utile messaggio di errore a riguardo ...

hai spazio libero su disco sul tuo client (e sul tuo server)?

df -h

Ho avuto un problema simile.

ssh domain.ip:user.name

Sembra che potrei aggirare il problema forzando un nome di accesso in questo modo.

ssh -v domain.ip -l user.name

Per me, l'aggiornamento a Snow Leopard ha risolto il problema. Quindi, penso che fosse correlato a un bug in OSX.

Se è a causa di una chiave salvata, dovresti essere in grado di eliminarla dalla tua directory ~ / .ssh nel file known_hosts. Basta trovare la voce ed eliminarla, quindi dovrebbe richiederti di nuovo.

D'altra parte, dovrebbe dare un avviso quando l'host non corrisponde a ciò che è stato registrato.

Ho avuto problemi in cui su OS X la ricerca del nome host si comporta come se fallisse; la connessione scade dall'attesa così a lungo o quando viene visualizzato il messaggio è in attesa da così tanto tempo che ci vogliono circa dieci secondi per inserire una password prima di interrompere la connessione. Non ho mai potuto rintracciarlo nonostante le persone suggerissero di aggiungere l'host in questione al file host. Immagino fosse solo un "problema tecnico con le ricerche DNS di OS X" e ci si aspettava che fosse tollerato ... se qualcun altro avesse questo problema e lo avesse risolto, mi piacerebbe saperlo.

Controllare i registri sul server. Di solito è in /var/log/auth.log(Debian / Ubuntu) o /var/log/secure(RedHat / CentOS). Eventuali problemi con la connessione di solito vengono registrati lì.

Assicurati che / etc / hostname sia terminato a capo.