From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1NHILC-000658-PW for garchives@archives.gentoo.org; Sun, 06 Dec 2009 14:44:03 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 5483DE078E; Sun, 6 Dec 2009 14:43:09 +0000 (UTC) Received: from mail.muc.de (colin.muc.de [193.149.48.1]) by pigeon.gentoo.org (Postfix) with ESMTP id D71DCE078E for ; Sun, 6 Dec 2009 14:43:08 +0000 (UTC) Received: (qmail 20599 invoked by uid 3782); 6 Dec 2009 14:43:08 -0000 Received: from acm.muc.de (pD9E5395F.dip.t-dialin.net [217.229.57.95]) by colin2.muc.de (tmda-ofmipd) with ESMTP; Sun, 06 Dec 2009 15:43:06 +0100 Received: (qmail 2776 invoked by uid 1000); 6 Dec 2009 14:48:36 -0000 Date: Sun, 6 Dec 2009 14:48:36 +0000 To: gentoo-user@lists.gentoo.org Subject: [gentoo-user] Problems setting up sshd on an installation kernel Message-ID: <20091206144836.GA2599@muc.de> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i X-Delivery-Agent: TMDA/1.1.5 (Fettercairn) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Archives-Salt: 409f161e-796d-49a8-b0f5-5be37a0e4ac7 X-Archives-Hash: 7b3e6fbc32919986be5a4f44d2da73e0 Hi, folks! I'm trying to get sshd working on an embryonic Gentoo installation on my laptop. The reason is that I want to ssh from my nice comfy desktop system into this laptop to do the rest of the installation stuff. The installation kernel with which I'm having problems is: Linux livecd 2.6.30-gentoo-r8 #1 SMP Tue Nov 3 11:40:51 UTC 2009. Having started sshd on my laptop, when I do ssh -lroot 192.168.2.101 from my desktop, I get prompted for my ssh key's pass phrase, which I enter. Thereafter, nothing happens, and it continues to happen for a long, long time. I've run sshd as sshd -d, which puts debugging info onto the screen. It turns out my system can't create a pty "pseudo terminal". Here is the debugging output. Please note the lines marked by "<=====": Postponed publickey for root from 192.168.2.100 port 41130 ssh2 debug1: userauth-request for user root service ssh-connection method publickey debug1: attempt 2 failures 0 debug1: temporarily_use_uid: 0/0 (e=0/0) debug1: trying public key file /root/.ssh/authorized_keys debug1: fd 4 clearing O_NONBLOCK debug1: matching key found: file /root/.ssh/authorized_keys, line 1 Found matching DSA key: a8:6a:76:30:f8:a4:4e:c4:3b:cd:ba:3d:20:87:0c:8f debug1: restore_uid: 0/0 debug1: ssh_dss_verify: signature correct debug1: do_pam_account: called Accepted publickey for root from 192.168.2.100 port 41130 ssh2 debug1: monitor_child_preauth: root has been authenticated by privileged process debug1: PAM: establishing credentials debug1: Entering interactive session for SSH2. debug1: server_init_dispatch_20 debug1: server_input_channel_open: ctype session rchan 0 win 65536 max 16384 debug1: input_session_request debug1: channel 0: new [server-session] debug1: session_new: session 0 debug1: session_open: channel 0 debug1: session_open: session 0: link with channel 0 debug1: server_input_channel_open: confirm session debug1: server_input_channel_req: channel 0 request pty-req reply 0 debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 req pty-req debug1: Allocating pty. <========================== openpty: No such file or dIrectory <========================== session_pty_req: session 0 alloc failed <========================== debug1: server_input_channel_req: channel 0 request shell reply 0 debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 req shell debug1: Forced command (key option) '/bin/bash' Exiting on signal 2 debug1: do_cleanup debug1: PAM: cleanup debug1: PAM: deleting credentials debug1: PAM: closing session Clearly openpty (a C function) is failing to find some file. Don't you just love error messages like "No such file or directory" which forget to identify the filename? I'm guessing that the file it can't find is the device file for the new pty. Is there anything I can do to get sshd working from this kernel (and if so, what?), or is there something fundamentally wrong with the kernel configuration? Thanks in advance for any and all help! -- Alan Mackenzie (Nuremberg, Germany).