Help setting up sshd, please
Alan Mackenzie
I'm trying to get sshd working on an embryonic Gentoo installation. So
far, so good. My remote client prompts for a password, but when I enter
it nothing happens, and my client hangs forever.
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:
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
Would somebody please give me a clue as to how to fire up the pty?
Thanks!
--
Alan Mackenzie (Nuremberg, Germany).
Nico Kadel-Garcia
Install RHEL? More seriously, telling us that it's an "embryonic
Gentoo" is leaving out a lot. I assume this is after the first
installation and reboot, and that you didn't customize your kernel
into leaving out important pseudo-randomization bits? And is your
login from the Gentoo server, or from another host?
Alan Mackenzie
>> I'm trying to get sshd working on an embryonic Gentoo installation. ?So
>> far, so good. ?My remote client prompts for a password, but when I enter
>> it nothing happens, and my client hangs forever.
>> 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:
>> 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
>> Would somebody please give me a clue as to how to fire up the pty?
>> Thanks!
> Install RHEL? More seriously, telling us that it's an "embryonic
> Gentoo" is leaving out a lot. I assume this is after the first
> installation and reboot, ......
Pretty much, except I've not yet got to the reboot stage - each time, I'm
firing up the new box from the installation CD, and chrooting to the new
partition on the hard disk.
> .... and that you didn't customize your kernel into leaving out
> important pseudo-randomization bits?
I don't know what you mean by this, but I rebuilt the kernel using pretty
much supplied defaults. What are the pseudo-randomization bits, and how
are they important?
> And is your login from the Gentoo server, or from another host?
The debug info is from the Gentoo server. It is validating the key
supplied by the host (my long working Debian Sarge box), and attempting
to start a pty for a remote bash session. It fails to start the pty, as
indicated in the three debug lines I've indicated with arrows.
Signs are that I've got the pty stuff in my kernel - in particular, the
device file /dev/ptmx was there.
Nico Kadel-Garcia
OK, then you're on the installation media's kernel still. I assume
you're inside the chroot cage of the newly installed OS, and you're
running the SSH daemon from an init script, and that it's
automatically set up your host keys at this point? Or are you starting
the sshd manually?
> > .... and that you didn't customize your kernel into leaving out
> > important pseudo-randomization bits?
>
> I don't know what you mean by this, but I rebuilt the kernel using pretty
> much supplied defaults. What are the pseudo-randomization bits, and how
> are they important?
I'd have to dig for where the kernel components for them. *YES*,
they're important. This is why I don't like customizing kernels as an
early step, but only after the first boot of a known standard kernel.
Did you just use the default .config?
> > And is your login from the Gentoo server, or from another host?
>
> The debug info is from the Gentoo server. It is validating the key
> supplied by the host (my long working Debian Sarge box), and attempting
> to start a pty for a remote bash session. It fails to start the pty, as
> indicated in the three debug lines I've indicated with arrows.
>
> Signs are that I've got the pty stuff in my kernel - in particular, the
> device file /dev/ptmx was there.
The *existence* of the /dev/ material isn't set by the kernel, it's
built these days into the 'udev' components that run at boot time. So
that's not a key. There are components that handle the generation of
pseudo-random material, which I'm reasonably certain is in the kernel
rather than in glibc, but I'd have to actually go looking.
Does sshd work after the first reboot?
Alan Mackenzie
I'm starting it manually. The machine is a laptop. My idea is (or was)
to get ssh set up at a very early stage so as to do the bulk of the
installation via ssh from my comfortable desktop keyboard and video.
>> > .... and that you didn't customize your kernel into leaving out
>> > important pseudo-randomization bits?
>> I don't know what you mean by this, but I rebuilt the kernel using pretty
>> much supplied defaults. ?What are the pseudo-randomization bits, and how
>> are they important?
Er sorry, I was a bit confused, there. I'm not using the kernel I built.
I'm still using the installation kernel. However, I've taken its config
from /proc/config.gz. Is there anything in particular I should look for
in it?
> I'd have to dig for where the kernel components for them. *YES*,
> they're important. This is why I don't like customizing kernels as an
> early step, but only after the first boot of a known standard kernel.
> Did you just use the default .config?
I still don't know what "pseudo-randomization" bits are.
>> > And is your login from the Gentoo server, or from another host?
>> The debug info is from the Gentoo server. ?It is validating the key
>> supplied by the host (my long working Debian Sarge box), and attempting
>> to start a pty for a remote bash session. ?It fails to start the pty, as
>> indicated in the three debug lines I've indicated with arrows.
>> Signs are that I've got the pty stuff in my kernel - in particular, the
>> device file /dev/ptmx was there.
> The *existence* of the /dev/ material isn't set by the kernel, it's
> built these days into the 'udev' components that run at boot time. So
> that's not a key. There are components that handle the generation of
> pseudo-random material, which I'm reasonably certain is in the kernel
> rather than in glibc, but I'd have to actually go looking.
How about these settings from the installation kernel's config?
CONFIG_HW_RANDOM=y
# CONFIG_HW_RANDOM_TIMERIOMEM is not set
CONFIG_HW_RANDOM_INTEL=y
CONFIG_HW_RANDOM_AMD=y
CONFIG_HW_RANDOM_GEODE=y
CONFIG_HW_RANDOM_VIA=y
CONFIG_HW_RANDOM_VIRTIO=m
> Does sshd work after the first reboot?
Haven't got that far, yet. I was hoping to be able to do the setting up
of Lilo or Grub over ssh. Maybe that was being a touch optimistic.
David Brown
> Hi, folks!
>
> I'm trying to get sshd working on an embryonic Gentoo installation. So
> far, so good. My remote client prompts for a password, but when I enter
> it nothing happens, and my client hangs forever.
>
I read something recently about ssh getting stuck after asking for the
password - it turned out that the user in question had a valid username
and password, but the home directory did not exist (the server "home"
partition was not mounted). I have no idea if your problem is similar,
but it should be easy to check.
Alan Mackenzie
No, I am trying to log on as root and I definitely have a ~root
directory. But you've given me an idea - the error I get (when sshd
tries to get a pty) is "openpty: No such file or directory", so perhaps
it is trying to log the action and failing to find a log file. I think I
will create my logging subsystem, and try again.
Thanks for the idea!
John Hasler
> But you've given me an idea - the error I get (when sshd tries to get
> a pty) is "openpty: No such file or directory", so perhaps it is
> trying to log the action and failing to find a log file.
No. From the openpty() man page:
ERRORS
openpty() will fail if:
ENOENT There are no available ttys.
--
John Hasler
jha...@newsguy.com
Dancing Horse Hill
Elmwood, WI USA
Alan Mackenzie
> Alan Mackenzie writes:
>> But you've given me an idea - the error I get (when sshd tries to get
>> a pty) is "openpty: No such file or directory", so perhaps it is
>> trying to log the action and failing to find a log file.
> No. From the openpty() man page:
> ERRORS
> openpty() will fail if:
> ENOENT There are no available ttys.
OK. So that brings me back to where I started. If there are no ttys,
other than those already attached to processes, how do I create more? Do
I need to give some kernel parameter? Where is it documented?
John Hasler
> OK. So that brings me back to where I started. If there are no ttys,
> other than those already attached to processes, how do I create more?
> Do I need to give some kernel parameter? Where is it documented?
man openpty, man pty, man MAKEDEV. openpty() wants BSD ptys. You
probably have none. Go to /dev and run "MAKEDEV pty" as root.
Alan Mackenzie
John Hasler <jha...@newsguy.com> wrote:
> Alan Mackenzie writes:
>> OK. So that brings me back to where I started. If there are no ttys,
>> other than those already attached to processes, how do I create more?
>> Do I need to give some kernel parameter? Where is it documented?
> man openpty, man pty, man MAKEDEV. openpty() wants BSD ptys. You
> probably have none. Go to /dev and run "MAKEDEV pty" as root.
openpty needs old-fashioned BSD ptys? YUCK! That feels like a bug, not
a feature.
There's not much point in me creating the /dev entries, since (sadly) the
installation kernel I was hoping to get sshd running on doesn't have
CONFIG_LEGACY_PTYS set. So I'm going to have to install a bootable
kernel after all, before I get my sshd going. At least I'll know to
configure these things in now.
Thanks!
John Hasler
> openpty needs old-fashioned BSD ptys? YUCK! That feels like a bug, not
> a feature.
I missed this:
NOTES
In versions of glibc before 2.0.92, openpty() returns file descriptors
for a BSD pseudo-terminal pair; since glibc 2.0.92, it first
attempts to open a Unix 98 pseudo-terminal pair, and falls back
to opening a BSD pseudo-terminal pair if that fails.
Nico Kadel-Garcia
to cross-post over there? I'm short of testing environments to try
breaking things to reproduce your environment.
And as a favor: please post the exact versions of gentoo and OpenSSH,
the username you are attempting to log in as.
You know, hmm. If what you want is the ability to reach *INTO* your
environment and configure lilo.conf remotely, maybe you can reach
*OUT* from the gentoo console to do what you need to, and scp *FROM*
the gentoo console to grab the file you want? Why are you reluctant to
configure these things from the local console?
Nico Kadel-Garcia
> Alan, this needs discussion over at comp.protocols.ssh. Would you care
> to cross-post over there? I'm short of testing environments to try
> breaking things to reproduce your environment.
Eeek. I meant "comp.security.ssh". You'd think I'd remember the group
name after years being active on it.
Alan Mackenzie
Somebody on the gentoo-users mailing list gave me the answer, and it is
thus: part of the recipe for chrooting involves a "bind mounting" of the
/dev system - you surely know what that is, I found out about an hour
ago. The recipe command is this:
mount -o bind /dev /mnt/gentoo/dev
. Sadly, that double mounts only /dev itself, not any subdirectories.
So the subdirectory I needed, /dev/pts, simply wasn't there. So I
changed the above recipe step to
mount --rbind /dev /mnt/gentoo/dev
, and I can now ssh into the new box without problem. I have got lilo
going on it (after wasting ~hour playing with grub), and can now boot
into the new system. I'm enjoying a beer at the moment.
Thanks for all the help!
Nico Kadel-Garcia
Son of a....
See, this is why I detest installers that require so many manual steps
and require the new user to be a wizard themselves, and why I like
installers with questionnaires that then do things for you as needed.
Alan Mackenzie
Nico Kadel-Garcia <nka...@gmail.com> wrote:
> On Dec 6, 4:33?pm, Alan Mackenzie <a...@muc.de> wrote:
>> Hi, Nico,
>> Somebody on the gentoo-users mailing list gave me the answer, and it
>> is thus: part of the recipe for chrooting involves a "bind mounting"
>> of the /dev system - you surely know what that is, I found out about
>> an hour ago. ?The recipe command is this:
>> ? ? mount -o bind /dev /mnt/gentoo/dev
>> . ?Sadly, that double mounts only /dev itself, not any subdirectories.
>> So the subdirectory I needed, /dev/pts, simply wasn't there. ?So I
>> changed the above recipe step to
>> ? ? mount --rbind /dev /mnt/gentoo/dev
>> , and I can now ssh into the new box without problem. ?I have got lilo
>> going on it (after wasting ~hour playing with grub), and can now boot
>> into the new system. ?I'm enjoying a beer at the moment.
>> Thanks for all the help!
> Son of a....
Batch?
> See, this is why I detest installers that require so many manual steps
> and require the new user to be a wizard themselves, and why I like
> installers with questionnaires that then do things for you as needed.
You're not short of choice, then. ;-) I have come to hat installers
that just ask a lot of questions, then do things behind your back. It's
great until something doesn't "quite" work. Particularly networking not
working. It never did for me, up until I got a broadband link with a
dhcp router.
The problem I stumbled over is just a bug in the gentoo installer. I'm
going to report it as such, and I expect they'll fix it.