ssh отказывается от всех подключений после обновления до 11.10

Я обновился с 11.04 до 11.10 и по завершении обнаружил, что больше не могу подключаться к ssh другим компьютерам, которые я обычно делаю. Я проверил несколько вещей:

1. Проверка подлинности Kerberos работает нормально, это не проблема.
2. Я попытался перезапустить и переустановить SSH, но ни один не помог.
3. Я попытался скопировать все файлы, связанные с ssh, с моего ноутбука (с должным образом функционирующим ssh в 11.04) и заменить то, что на моей 11.10 неисправной ОС, но это не помогло.

4. Я попытался удалить файл.ssh/known_hosts. При следующей попытке я впервые получил обычное сообщение о подключении куда-то, но все равно было отказано в подключении.

   jason:~$ /usr/sbin/sshd -ddd
   debug2: load_server_config: filename /etc/ssh/sshd_config 
   debug2: load_server_config: done config len = 682 
   debug2: parse_server_config: config /etc/ssh/sshd_config len 682 
   debug3: /etc/ssh/sshd_config:5 setting Port 22 
   debug3: /etc/ssh/sshd_config:9 setting Protocol 2 
   debug3: /etc/ssh/sshd_config:11 setting HostKey /etc/ssh/ssh_host_rsa_key 
   debug3: /etc/ssh/sshd_config:12 setting HostKey /etc/ssh/ssh_host_dsa_key 
   debug3: /etc/ssh/sshd_config:13 setting HostKey /etc/ssh/ssh_host_ecdsa_key 
   debug3: /etc/ssh/sshd_config:15 setting UsePrivilegeSeparation yes 
   debug3: /etc/ssh/sshd_config:18 setting KeyRegenerationInterval 3600 
   debug3: /etc/ssh/sshd_config:19 setting ServerKeyBits 768 
   debug3: /etc/ssh/sshd_config:22 setting SyslogFacility AUTH 
   debug3: /etc/ssh/sshd_config:23 setting LogLevel INFO 
   debug3: /etc/ssh/sshd_config:26 setting LoginGraceTime 120 
   debug3: /etc/ssh/sshd_config:27 setting PermitRootLogin no 
   debug3: /etc/ssh/sshd_config:28 setting StrictModes yes 
   debug3: /etc/ssh/sshd_config:30 setting RSAAuthentication yes 
   debug3: /etc/ssh/sshd_config:31 setting PubkeyAuthentication yes 
   debug3: /etc/ssh/sshd_config:35 setting IgnoreRhosts yes 
   debug3: /etc/ssh/sshd_config:37 setting RhostsRSAAuthentication no 
   debug3: /etc/ssh/sshd_config:39 setting HostbasedAuthentication no 
   debug3: /etc/ssh/sshd_config:44 setting PermitEmptyPasswords no 
   debug3: /etc/ssh/sshd_config:48 setting ChallengeResponseAuthentication no 
   debug3: /etc/ssh/sshd_config:63 setting X11Forwarding yes 
   debug3: /etc/ssh/sshd_config:64 setting X11DisplayOffset 10 
   debug3: /etc/ssh/sshd_config:65 setting PrintMotd no 
   debug3: /etc/ssh/sshd_config:66 setting PrintLastLog yes 
   debug3: /etc/ssh/sshd_config:67 setting TCPKeepAlive yes 
   debug3: /etc/ssh/sshd_config:74 setting AcceptEnv LANG LC_* 
   debug3: /etc/ssh/sshd_config:76 setting Subsystem sftp /usr/lib/openssh/sftp-server 
   debug3: /etc/ssh/sshd_config:87 setting UsePAM yes 
   debug1: sshd version OpenSSH_5.8p1 Debian-7ubuntu1 
   debug3: Incorrect RSA1 identifier 
   debug1: read PEM private key done: type RSA 
   debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048 
   debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048 
   debug1: private host key: #0 type 1 RSA 
   debug3: Incorrect RSA1 identifier 
   debug1: read PEM private key done: type DSA 
   debug1: Checking blacklist file /usr/share/ssh/blacklist.DSA-1024 
   debug1: Checking blacklist file /etc/ssh/blacklist.DSA-1024 
   debug1: private host key: #1 type 2 DSA 
   debug3: Incorrect RSA1 identifier 
   debug1: read PEM private key done: type ECDSA 
   debug1: Checking blacklist file /usr/share/ssh/blacklist.ECDSA-256 
   debug1: Checking blacklist file /etc/ssh/blacklist.ECDSA-256 
   debug1: private host key: #2 type 3 ECDSA 
   debug1: setgroups() failed: Operation not permitted 
   debug1: rexec_argv[0]='/usr/sbin/sshd' 
   debug1: rexec_argv[1]='-ddd' 
   debug3: oom_adjust_setup 
   Set /proc/self/oom_score_adj from 0 to -1000 
   debug2: fd 3 setting O_NONBLOCK 
   debug1: Bind to port 22 on 0.0.0.0. 
   Bind to port 22 on 0.0.0.0 failed: Permission denied. 
   debug2: fd 3 setting O_NONBLOCK 
   debug3: sock_set_v6only: set socket 3 IPV6_V6ONLY 
   debug1: Bind to port 22 on ::. 
   Bind to port 22 on :: failed: Permission denied. 
   Cannot bind any address. 
   

Возможно, проблема в этом показании, но я не достаточно знаком с этим выводом, чтобы знать.

Мой ноутбук, на котором установлена ​​Ubuntu 11.04, все еще может успешно входить в систему на компьютерах, которые мне нужны, поэтому проблема определенно связана с обновлением моего рабочего стола до 11.10.

================================================== =======================

[править:] Я думаю, я что-то придумаю

Если я сделаю ssh -vv name@computer.org.com (компьютер, на котором я пытаюсь войти), к концу вывода я получаю:

Jason Nett 11:06:38 PM
debug1: Authentications that can continue: gssapi-keyex,gssapi-with-mic,keyboard-interactive
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug2: we did not send a packet, disable method
debug1: Next authentication method: gssapi-with-mic
debug2: we sent a gssapi-with-mic packet, wait for reply
debug1: Authentication succeeded (gssapi-with-mic).
Authenticated to computer.org.com ([xxx.xxx.xxx.xxx]:xx).

Обратите внимание: "gssapi-with-mic" находится в списке "Аутентификации, которые могут продолжаться" и является успешным. Когда я пытаюсь на машине, которая потеряла свою способность SSH, это вывод:

debug1: Authentications that can continue: gssapi-keyex,gssapi-with-mic,keyboard-interactive
debug1: Next authentication method: keyboard-interactive
debug2: userauth_kbdint
debug2: we sent a keyboard-interactive packet, wait for reply
debug1: Authentications that can continue: gssapi-keyex,gssapi-with-mic,keyboard-interactive
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (gssapi-keyex,gssapi-with-mic,keyboard-interactive).

Таким образом, на этом компьютере никогда не предпринимаются попытки "gssapi-keyex" и "gssapi-with-mic" (согласно подробному выводу), а только "клавиатурно-интерактивный". Из моих онлайн-поисков я понял, что gssapi-with-mic как-то связан с передачей моей аутентификации по протоколу Kerberos, но в настоящий момент я не совсем уверен, куда идти.

Надеемся, что эта дополнительная информация поможет нам быстро устранить проблему.