Strano problema SSH, ssh funziona con -t ma si blocca senza di essa

Quando sshentro in uno dei miei server, sembra che acceda, ma poi si blocca prima di darmi il prompt ( message debug2: shell request accepted on channel 0 is the last log entry).

Anche se la cosa strana è che ssh -t "/bin/bash"funziona quando sshnon lo fa.

Quello che ho scoperto finora

• Posso accedere normalmente dai server nella stessa posizione geografica
• Se posso ssh -t '/bin/bash', posso accedere perfettamente da QUALSIASI posizione.
• Se uso rsync per il server, sembra funzionare, e si blocca poi
• Se uso rsync dal server, funziona senza problemi

Quello che ho provato

• rimozione o modifica di tutte le opzioni di accesso .profile,.bashrc /etc/profile
• Modifica di ssh_config e / o sshd_config in uno da un server identico che funziona correttamente
• Ho controllato il routing
• Ho avuto un esperto di rete che ha esaminato tcpdumpinutilmente (anche se sembra che ci siano molte ritrasmissioni)

Non riesco proprio a pensare ad altro

A parte un driver / firmware per schede di rete non sicure.

Ciò potrebbe derivare da un problema nel profilo.
Quando ti connetti con la ssh -t /bin/bash tua shell non effettuerà il login, non genererà /etc/profilené il ~/.profilee ~/.bashrc...

Quindi dopo la connessione, metti la shell in modalità debug, quindi dai origine a ciascun file per trovare ciò che sta bloccando all'interno:

set -x 
. /etc/profile 
...and so on

MODIFICARE

Nota che ho sbagliato, il file .bashrc verrà fornito da qualsiasi shell interattiva (quindi qui contano solo i file profile, profile.d).

Prova a fare l'elenco delle diverse fasi del processo di connessione. Qualcosa come questo

1) connessione ssh (config, ...)
2) login (PAM, tty, wtmp, ...)
3) avvio della shell (profilo, accesso alla home directory, ...)

Per controllare il (1) è possibile avviare il demone sshd in modalità debug. Per questo è necessario avviare un altro sshd, ascoltando una porta dedicata (non sulla porta 22, quindi non è necessario arrestare il demone sshd normale).

# /usr/sbin/sshd -p 2222 -ddd 

Che sshd accetterà solo una connessione e non andrà in background. Apri un altro terminale e connettiti a quella sessione SSH.

# ssh -vvv -p 2222 user@host

Puoi confrontare i messaggi che ricevi con quelli di un altro server della stessa marca. Quindi saprai se il problema è o meno sul lato SSH.

(-ddd e -vvv sono il livello massimo di debug, puoi ottimizzarlo)

Ho ottenuto quel link , molto più dettagliato.

La risposta al mio problema Si è scoperto che era un problema di rete. Alla fine ho scoperto che facendo cadere un po 'l'MTU di tutte le schede di rete, il problema è scomparso.

Molto probabilmente qualcosa non è configurato correttamente per quella rete, ma ora posso provarlo e consegnarlo al team della rete (che continuava a dirmi che si trattava di un problema del server).

Tuttavia, questa è l'ultima risorsa. La particolarità che avevo era che il server ssh funzionava dalla stessa sottorete ma non al di fuori di esso, e ssh -t '/ bin / bash' funzionava da qualsiasi luogo.

Ho anche avuto rsync che sarebbero iniziati bene, ma a un certo punto semplicemente si bloccano o si interrompe la connessione.

Quindi, se stai guardando questa risposta, prova prima gli altri sopra, e SOLO se ottieni stranezze come la mia, è probabile che questo ti aiuti.

Quindi grazie per tutto l'aiuto. Ho provato di tutto e mi ha insegnato molto, e lasciami confermare che non aveva nulla a che fare con il server (che è tutto ciò che speravo).

Quindi grazie a tutti quelli che hanno aiutato

Quando si esegue ssh some_user@some_host /bin/bash, quello che stai facendo sta lanciando some_user 's shell (come definito nella /etc/passwdsu some_host ) e poi eseguire il comando dato, /bin/bash, dall'interno di quel guscio.

Ora, la shell di some_user (supponiamo che sia anche bash) non viene lanciata in modo interattivo (sta invece eseguendo il comando dato). Quindi non alloca un pty (uno pseudo-terminale ) e questo significa che non c'è un pty da usare per il comando emesso, quindi inizia in modo non interattivo.

Nell'esempio, il /bin/bashcomando richiesto viene avviato ma sembra bloccarsi.

È possibile risolvere questo problema chiedendo comunque sshdi creare un pty in modo che ce ne sia uno disponibile per la shell e i relativi processi figlio. Questo è ciò che -tfa.

    $ ssh -t some_user@some_host bash

Puoi anche risolvere questo problema forzando il comando a creare un pty. Per bash, lo fai passando un -iargomento. Anche la seguente riga di comando dovrebbe funzionare:

$ ssh some_user@some_host bash -i

Si noti, tuttavia, che in quest'ultimo caso, la shell non può accedere /dev/ttye ciò si traduce in un avviso:

bash: no job control in this shell

Le ragioni di ciò sono spiegate qui . Questo potrebbe essere o meno un problema a seconda di cosa si prevede di fare nella shell ma l'utilizzo ssh -tè probabilmente l'opzione migliore.

(nota che puoi semplicemente passare bashcome comando perché dovrebbe comunque trovarsi sul percorso della shell predefinita dell'utente)

Ho lo stesso problema quando ho usato di recente una piattaforma di virtualizzazione nidificata.

Funziona dopo aver ridotto MTU da 1500 a 1400 sul server di origine o di destinazione.

/sbin/ip link set dev eth0 mtu 1400