La nueva conexión SSH comienza a colgarse (no se rechaza ni termina) después de un día más o menos en el servidor Ubuntu 13.04

31

Recientemente hemos actualizado el servidor del servidor 12.04 LTS a 13.04. Todo estuvo bien, incluso después de un reinicio. Con todos los paquetes actualizados, comenzamos a ver un problema extraño, ssh funciona durante un día más o menos (no está claro en el momento) y luego una solicitud posterior de SSH se bloquea (no puede ctrl + c, nada).

Está activo y sirve tráfico de servidores web, etc.

El puerto 22 está abierto (ips, etc., modificado ligeramente para la publicación):

nmap -T4 -A x.acme.com

Starting Nmap 6.40 ( http://nmap.org ) at 2013-09-12 16:01 CDT
Nmap scan report for x.acme.com (69.137.56.18)
Host is up (0.026s latency).
rDNS record for 69.137.56.18: c-69-137-56-18.hsd1.tn.provider.net
Not shown: 998 filtered ports
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 6.1p1 Debian 4 (protocol 2.0)
| ssh-hostkey: 1024 54:d3:e3:38:44:f4:20:a4:e7:42:49:d0:a7:f1:3e:21 (DSA)
| 2048 dc:21:77:3b:f4:4e:74:d0:87:33:14:40:04:68:33:a6 (RSA)
|_256 45:69:10:79:5a:9f:0b:f0:66:15:39:87:b9:a1:37:f7 (ECDSA)
80/tcp open  http    Jetty 7.6.2.v20120308
| http-title: Log in as a Bamboo user - Atlassian Bamboo
|_Requested resource was http://x.acme.com/userlogin!default.action;jsessionid=19v135zn8cl1tgso28fse4d50?os_destination=%2Fstart.action
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 12.89 seconds

Aquí está el ssh -vvv:

ssh -vvv x.acme.com
OpenSSH_5.9p1, OpenSSL 0.9.8x 10 May 2012
debug1: Reading configuration data /Users/tfergeson/.ssh/config
debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to x.acme.com [69.137.56.18] port 22.
debug1: Connection established.
debug3: Incorrect RSA1 identifier
debug3: Could not load "/Users/tfergeson/.ssh/id_rsa" as a RSA1 public key
debug1: identity file /Users/tfergeson/.ssh/id_rsa type 1
debug1: identity file /Users/tfergeson/.ssh/id_rsa-cert type -1
debug1: identity file /Users/tfergeson/.ssh/id_dsa type -1
debug1: identity file /Users/tfergeson/.ssh/id_dsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.1p1 Debian-4
debug1: match: OpenSSH_6.1p1 Debian-4 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.9
debug2: fd 3 setting O_NONBLOCK
debug3: load_hostkeys: loading entries for host "x.acme.com" from file "/Users/tfergeson/.ssh/known_hosts"
debug3: load_hostkeys: found key type RSA in file /Users/tfergeson/.ssh/known_hosts:10
debug3: load_hostkeys: loaded 1 keys
debug3: order_hostkeyalgs: prefer hostkeyalgs: [email protected],[email protected],ssh-rsa
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: [email protected],[email protected],ssh-rsa,[email protected],[email protected],ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[email protected],hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[email protected],hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,[email protected],zlib
debug2: kex_parse_kexinit: none,[email protected],zlib
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,[email protected]
debug2: kex_parse_kexinit: none,[email protected]
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: mac_setup: found hmac-md5
debug1: kex: server->client aes128-ctr hmac-md5 none
debug2: mac_setup: found hmac-md5
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug2: dh_gen_key: priv key bits set: 130/256
debug2: bits set: 503/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: RSA dc:21:77:3b:f4:4e:74:d0:87:33:14:40:04:68:33:a6
debug3: load_hostkeys: loading entries for host "x.acme.com" from file "/Users/tfergeson/.ssh/known_hosts"
debug3: load_hostkeys: found key type RSA in file /Users/tfergeson/.ssh/known_hosts:10
debug3: load_hostkeys: loaded 1 keys
debug3: load_hostkeys: loading entries for host "69.137.56.18" from file "/Users/tfergeson/.ssh/known_hosts"
debug3: load_hostkeys: found key type RSA in file /Users/tfergeson/.ssh/known_hosts:6
debug3: load_hostkeys: loaded 1 keys
debug1: Host 'x.acme.com' is known and matches the RSA host key.
debug1: Found key in /Users/tfergeson/.ssh/known_hosts:10
debug2: bits set: 493/1024
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /Users/tfergeson/.ssh/id_rsa (0x7ff189c1d7d0)
debug2: key: /Users/tfergeson/.ssh/id_dsa (0x0)
debug1: Authentications that can continue: publickey
debug3: start over, passed a different list publickey
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/tfergeson/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 277
debug2: input_userauth_pk_ok: fp 3c:e5:29:6c:9d:27:d1:7d:e8:09:a2:e8:8e:6e:af:6f
debug3: sign_and_send_pubkey: RSA 3c:e5:29:6c:9d:27:d1:7d:e8:09:a2:e8:8e:6e:af:6f
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).
Authenticated to x.acme.com ([69.137.56.18]:22).
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug1: Requesting [email protected]
debug1: Entering interactive session.
debug2: callback start
debug2: client_session2_setup: id 0
debug2: fd 3 setting TCP_NODELAY
debug2: channel 0: request pty-req confirm 1
debug1: Sending environment.
debug3: Ignored env ATLAS_OPTS
debug3: Ignored env rvm_bin_path
debug3: Ignored env TERM_PROGRAM
debug3: Ignored env GEM_HOME
debug3: Ignored env SHELL
debug3: Ignored env TERM
debug3: Ignored env CLICOLOR
debug3: Ignored env IRBRC
debug3: Ignored env TMPDIR
debug3: Ignored env Apple_PubSub_Socket_Render
debug3: Ignored env TERM_PROGRAM_VERSION
debug3: Ignored env MY_RUBY_HOME
debug3: Ignored env TERM_SESSION_ID
debug3: Ignored env USER
debug3: Ignored env COMMAND_MODE
debug3: Ignored env rvm_path
debug3: Ignored env COM_GOOGLE_CHROME_FRAMEWORK_SERVICE_PROCESS/USERS/tfergeson/LIBRARY/APPLICATION_SUPPORT/GOOGLE/CHROME_SOCKET
debug3: Ignored env JPDA_ADDRESS
debug3: Ignored env APDK_HOME
debug3: Ignored env SSH_AUTH_SOCK
debug3: Ignored env Apple_Ubiquity_Message
debug3: Ignored env __CF_USER_TEXT_ENCODING
debug3: Ignored env rvm_sticky_flag
debug3: Ignored env MAVEN_OPTS
debug3: Ignored env LSCOLORS
debug3: Ignored env rvm_prefix
debug3: Ignored env PATH
debug3: Ignored env PWD
debug3: Ignored env JAVA_HOME
debug1: Sending env LANG = en_US.UTF-8
debug2: channel 0: request env confirm 0
debug3: Ignored env JPDA_TRANSPORT
debug3: Ignored env rvm_version
debug3: Ignored env M2_HOME
debug3: Ignored env HOME
debug3: Ignored env SHLVL
debug3: Ignored env rvm_ruby_string
debug3: Ignored env LOGNAME
debug3: Ignored env M2_REPO
debug3: Ignored env GEM_PATH
debug3: Ignored env AWS_RDS_HOME
debug3: Ignored env rvm_delete_flag
debug3: Ignored env EC2_PRIVATE_KEY
debug3: Ignored env RUBY_VERSION
debug3: Ignored env SECURITYSESSIONID
debug3: Ignored env EC2_CERT
debug3: Ignored env _
debug2: channel 0: request shell confirm 1
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768

Puedo reiniciar (solo monitores Mac en esa ubicación) y volveré a estar accesible. Esto ahora sucede cada vez. Es imperativo que lo solucione. Lo extraño es que se comporta inicialmente y luego comienza a colgarse después de varias horas. Leí los registros previamente y nada se destacó.

Desde auth.log, puedo ver que me ha permitido entrar, pero aún así no obtengo nada del lado del cliente:

Sep 20 12:47:50 cbear sshd[25376]: Accepted publickey for tfergeson from 10.1.10.14 port 54631 ssh2
Sep 20 12:47:50 cbear sshd[25376]: pam_unix(sshd:session): session opened for user tfergeson by (uid=0)

ACTUALIZACIONES:

Todavía ocurre incluso después de configurar UseDNS noy comentar#session optional pam_mail.so standard noenv

Esto no parece ser un problema relacionado con la red / dns, ya que todos los servicios que se ejecutan en la máquina son tan receptivos y accesibles como siempre, con la excepción de sshd.

¿Alguna idea sobre por dónde empezar?

server ssh kross
fuente
Tuve un problema similar una vez y pude resolverlo, pero no recuerdo cómo. Fue hace unos años. Hubo algunas configuraciones de búferes en /etc/sysctl.conf, creo. Además, reiniciar la "conexión en red" solucionó el problema, pero eso obviamente no es una solución. No es una respuesta, pero quizás puede ser un punto de partida. Buena suerte de todos modos :)
Jo-Erlend Schinstad
Estoy desactivando las motdcosas a las que se hace referencia en esta publicación para tratar de asegurarme de que no sea un problema.
Kross
Simplemente ocurrió nuevamente, por lo que ciertamente no está motdrelacionado.
Kross
No puedo encontrar ninguna otra sugerencia. Si bien no creo que este sea el problema, quería eliminar al menos un problema potencial. Añadido UseDNS noa la /etc/ssh/sshd_config.
Kross
1
Sigue pasando, me encantaría poner una recompensa por esto, pero sólo tienen puntos stackoverflow ...
Kross

Respuestas:

30

Desde la página SshAccess en el wiki de documentación de GNU Savannah :

Puede surgir un problema cuando intenta conectarse desde detrás de un enrutador NAT utilizando OpenSSH. Durante la configuración de la sesión, una vez que se ha proporcionado la contraseña, OpenSSH establece el campo TOS (tipo de servicio) en el datagrama IP. Se sabe que algunos enrutadores se ahogan con esto. El efecto es que su sesión se cuelga indefinidamente después de que le dio su contraseña. Aquí está el resultado de ejemplo de tal sesión ssh:

user@localhost:~$ ssh -vvv {user-name}@cvs.savannah.gnu.org
OpenSSH_4.7p1 Debian-8ubuntu1.2, OpenSSL 0.9.8g 19 Oct 2007
debug1: Reading configuration data /etc/ssh/ssh_config
[...]
Enter passphrase for key '{homedir}/.ssh/id_rsa':
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).
[...]
debug2: fd 5 setting TCP_NODELAY
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768

y de aquí en adelante se cuelga la sesión.

La solución es hacer que ssh envíe todo su tráfico a través de netcat, porque netcat no establecerá el campo TOS. Para que esto funcione, debe tener instalado netcat. Puede probar esto ingresando en la línea de comando:

user@localhost:~$ which nc

y si tienes un camino de regreso, como:

/bin/nc

entonces probablemente tengas instalado netcat. Para los muy cautelosos, también podría emitir:

user@localhost:~$ nc -h

y mira el próximo texto de ayuda. Si no tiene netcat, puede encontrarlo en http://netcat.sourceforge.net/ . También puede probar el sistema de empaquetado que viene con la distribución de su sistema operativo.

Una vez que descubra que tiene instalado netcat, emita el siguiente comando para probar si la ruta netcat resuelve su problema:

ssh -o "ProxyCommand nc %h %p" {user-name}@cvs.savannah.gnu.org

donde {nombre de usuario} es su nombre de inicio de sesión de savannah. Para un inicio de sesión exitoso, debe obtener un resultado similar a este (sin bloqueos, es decir, recibirá un mensaje después):

user@localhost:~$ ssh -o "ProxyCommand nc %h %p" {user-name}@cvs.savannah.gnu.org
Enter passphrase for key '{home-dir}/.ssh/id_rsa': 
Last login: {datetime} from {ip-adr} 
You tried to execute: 
Sorry, you are not allowed to execute that command. 
Connection to cvs.savannah.gnu.org closed. 
user@localhost:~$

Si encuentra que su inicio de sesión funciona a través de la ruta netcat, puede hacerlo permanente agregando una directiva al archivo de configuración ssh ~/.ssh/config(o, si ese archivo no existe, créelo):

ProxyCommand nc %h %p

Aquí hay un archivo de configuración ssh de ejemplo en la carpeta de inicio de un usuario (/home/user/.ssh/config):

# This is the ssh client user configuration file.  See
# ssh_config(5) for more information.  This file provides defaults for
# this user, and the values can be changed on the command line.
#
# Configuration data is parsed as follows:
#  1. command line options
#  2. user-specific file
#  3. system-wide file
# Any configuration value is only changed the first time it is set.
# Thus, host-specific definitions should be at the beginning of the
# configuration file, and defaults at the end.
#
# Directive to overcome TOS issue with our NAT router. During session setup,
# OpenSSH sets the TOS (type of service) field after the user has submitted
# the password. Some routers are known to choke on this, with the result
# that the session hangs during buildup. As workaround we send our traffic
# via netcat which doesn't set the TOS field.
ProxyCommand nc %h %p

Es aconsejable poner los comentarios también, de lo contrario, seis meses después, ¿te preguntarás de qué se trata esa directiva?

También podría agregar esta directiva a su archivo de configuración ssh global ( /etc/ssh/ssh_config), pero este cambio sería en todo el sistema, y ​​no todos los usuarios en su sistema pueden apreciar ese cambio.

jogi3000
fuente
77
El plagio no
Gilles 'SO- deja de ser malvado'
Brillante, gracias por ayudarme aquí. Debe haber sido una pesadilla para depurar. Para el registro, esto ocurre cuando estoy en un WiFi estúpido específico, por lo que he modificado mi de la ssh_configsiguiente manera: Match exec "iw dev | grep -q stupid_wifi_ssid" ProxyCommand nc %h %p
Florian Echtler
7

ssh -o IPQoS=0 x.acme.com debería decirle a openssh que deje de configurar el campo de QoS que se está obstruyendo.

Carey Underwood
fuente
Lo resolvió por mí. Curiosamente, otra máquina en mi LAN no estaba experimentando este problema. Intentaría esto, antes de intentar el enrutamiento netcat.
Dominykas Mostauskis
2

Por ridículo que parezca, la única solución que tengo en este momento es programar un reinicio nocturno. Afortunadamente, esta solución es aceptable solo porque es una máquina de desarrollo, si hubiera sido una máquina de producción, estaría en problemas.

Odio esto, pero quería estar seguro de que otros que encuentran este hilo saben que no tengo solución. Se agregó esto al crontab raíz para un reinicio nocturno a las 4 am:

0 4 * * * /sbin/shutdown -r +5
kross
fuente
1
Tengo exactamente el mismo problema con sshd.exe ejecutándose bajo cygwin en win7. Me pregunto si es un error multiplataforma en sshd?
Kev
2

Tuve el problema detrás de un NAT con ssh. Intenté "mosh" con opciones ssh y todo funciona perfectamente. Instalar mosh

Juan Zamora
fuente
1
Recomiendo editar esta respuesta para expandirla con detalles específicos sobre cómo hacer esto. (Consulte también ¿Cómo escribo una buena respuesta? Para obtener consejos generales sobre qué tipos de respuestas se consideran más valiosas en AskUbuntu.)
David Foerster
1

Tuve que congelar gnome-keyring-daemon sobre mí al 100% de CPU en Ubuntu 18.04. 

sudo killall -9 gnome-keyring-daemon

Arreglado. ...Por ahora

Dagelf
fuente
¡Maldita sea! totalmente trabajado para mí también!
Nicholas DiPiazza