[gentoo-user] Problems setting up sshd on an installation kernel

[gentoo-user] Problems setting up sshd on an installation kernel

[Alan Mackenzie]

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).

Re: [gentoo-user] Problems setting up sshd on an installation kernel

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 615 bytes --]

On Sunday 06 December 2009 14:48:36 Alan Mackenzie wrote:

> 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?

Not sure if this is a kernel problem.  Have you tried to set up a user account 
and passwd then login as a plain user over ssh and then su to root?  
Alternatively, check /etc/ssh/sshd_config to see if root logins are disabled 
as a default.

While you're there you may also/first want to disable pam for ssh just in case 
it interferes with the root login.
-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Problems setting up sshd on an installation kernel

[Alan Mackenzie]

Hi, Mick,

On Sun, Dec 06, 2009 at 04:28:10PM +0000, Mick wrote:
> On Sunday 06 December 2009 14:48:36 Alan Mackenzie wrote:

> > 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?

> Not sure if this is a kernel problem.  Have you tried to set up a user
> account and passwd then login as a plain user over ssh and then su to
> root?

No.  Could that make a difference?  It is prompting me for my key's
passphrase and accepts it; it is failing to create a pseudo terminal.

> Alternatively, check /etc/ssh/sshd_config to see if root logins are
> disabled as a default.

They are explicitly permitted.  I set up sshd_config myself.

> While you're there you may also/first want to disable pam for ssh just in case 
> it interferes with the root login.

Er, pam?  That's when my ssh client prompts me for my pass phrase, isn't
it?

> Regards,
> Mick

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [gentoo-user] Problems setting up sshd on an installation kernel

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 1656 bytes --]

On Sunday 06 December 2009 20:23:39 Alan Mackenzie wrote:
> Hi, Mick,
> 
> On Sun, Dec 06, 2009 at 04:28:10PM +0000, Mick wrote:
> > On Sunday 06 December 2009 14:48:36 Alan Mackenzie wrote:
> > > 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?
> >
> > Not sure if this is a kernel problem.  Have you tried to set up a user
> > account and passwd then login as a plain user over ssh and then su to
> > root?
> 
> No.  Could that make a difference?  It is prompting me for my key's
> passphrase and accepts it; it is failing to create a pseudo terminal.

I was trying to take out of the equation user access issues. 

> > Alternatively, check /etc/ssh/sshd_config to see if root logins are
> > disabled as a default.
> 
> They are explicitly permitted.  I set up sshd_config myself.

OK

> > While you're there you may also/first want to disable pam for ssh just in
> > case it interferes with the root login.
> 
> Er, pam?  That's when my ssh client prompts me for my pass phrase, isn't
> it?

No, it's when it asks/expects a user passwd which I wasn't sure that you set 
up beforehand.

Typically, one would create a user and set up passwd both for user and root 
locally, then start screen as the user and detach it, login remotely with ssh 
and chroot from that point on.  If as you said in previous message you are 
trying to do this from within the chrooted environment then things may be more 
complicated.  I can't recall ever trying that to know how or why it fails.
-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Problems setting up sshd on an installation kernel

[Florian Philipp]

[-- Attachment #1: Type: text/plain, Size: 1186 bytes --]

Alan Mackenzie schrieb:
> 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.
> 
[...]
> 
> 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?
> 

Where did you start sshd, in the chrooted environment or on the live cd
itself?


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 261 bytes --]

Re: [gentoo-user] Problems setting up sshd on an installation kernel

[Joshua Murphy]

On Sun, Dec 6, 2009 at 11:59 AM, Florian Philipp
<lists@f_philipp.fastmail.net> wrote:
> Alan Mackenzie schrieb:
>> 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.
>>
> [...]
>>
>> 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?
>>
>
> Where did you start sshd, in the chrooted environment or on the live cd
> itself?

My first thought as well... I'd guess, just at a glance, that sshd was
started in the chroot, and that /mnt/gentoo/dev/ is bind mounted
properly, but /mnt/gentoo/dev/pts/ isn't.

-- 
Poison [BLX]
Joshua M. Murphy

Re: [gentoo-user] Problems setting up sshd on an installation kernel

[Alan Mackenzie]

Hi, Joshua,

On Sun, Dec 06, 2009 at 01:56:06PM -0500, Joshua Murphy wrote:
> On Sun, Dec 6, 2009 at 11:59 AM, Florian Philipp
> <lists@f_philipp.fastmail.net> wrote:
> > Alan Mackenzie schrieb:

> >> 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.

> > [...]

> >> 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?


> > Where did you start sshd, in the chrooted environment or on the live cd
> > itself?

> My first thought as well... I'd guess, just at a glance, that sshd was
> started in the chroot, and that /mnt/gentoo/dev/ is bind mounted
> properly, but /mnt/gentoo/dev/pts/ isn't.

It was, and it is, but it isn't, just as you suggest.  I've just read up
on exactly what

    mount -o bind /dev /mnt/gentoo/dev

means, and I can see I really want "-o rbind" (or --rbind) instead.

Thanks!  It'll surely work, now

> Joshua M. Murphy

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [gentoo-user] Problems setting up sshd on an installation kernel

[Alan Mackenzie]

On Sun, Dec 06, 2009 at 01:56:06PM -0500, Joshua Murphy wrote:
> On Sun, Dec 6, 2009 at 11:59 AM, Florian Philipp
> <lists@f_philipp.fastmail.net> wrote:
> > Alan Mackenzie schrieb:
> >> 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.

> > [...]

> >> 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?


> > Where did you start sshd, in the chrooted environment or on the live cd
> > itself?

> My first thought as well... I'd guess, just at a glance, that sshd was
> started in the chroot, and that /mnt/gentoo/dev/ is bind mounted
> properly, but /mnt/gentoo/dev/pts/ isn't.

As said, I fixed the problem by mounting /dev with --rbind.  This
misunderstanding cost me, perhaps, 10 hours of my time.

I then reported my problem to the bug tracker, suggesting that the manual
should be amended to say "--rbind" here.

I really wish I hadn't bothered.  My attempt to contribute was brusquely
brushed aside by somebody who didn't even bother to thank me for my
trouble (I always thank people reporting bugs to my project), said that
he "couldn't reproduce [my] error", and asserted that sshd wasn't meant
to work in the chrooted environment (why on Earth not?), implying it was
my stupid fault for not following the manual rigidly and droidwise.  To
cap it all, he patronisingly referred me to the appropriate sections of
the fine manual (that's after my having reported how I'd already fixed
the problem for me).

See https://bugs.gentoo.org/show_bug.cgi?id=296073

Seems to me, reporting problems to Gentoo is a waste of time, at least
documentation problems.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [gentoo-user] Problems setting up sshd on an installation kernel

[Alan McKinnon]

On Wednesday 09 December 2009 17:24:16 Alan Mackenzie wrote:
> > My first thought as well... I'd guess, just at a glance, that sshd was
> > started in the chroot, and that /mnt/gentoo/dev/ is bind mounted
> > properly, but /mnt/gentoo/dev/pts/ isn't.
> 
> As said, I fixed the problem by mounting /dev with --rbind.  This
> misunderstanding cost me, perhaps, 10 hours of my time.
> 
> I then reported my problem to the bug tracker, suggesting that the manual
> should be amended to say "--rbind" here.
> 
> I really wish I hadn't bothered.  My attempt to contribute was brusquely
> brushed aside by somebody who didn't even bother to thank me for my
> trouble (I always thank people reporting bugs to my project), said that
> he "couldn't reproduce [my] error", and asserted that sshd wasn't meant
> to work in the chrooted environment (why on Earth not?), implying it was
> my stupid fault for not following the manual rigidly and droidwise.  To
> cap it all, he patronisingly referred me to the appropriate sections of
> the fine manual (that's after my having reported how I'd already fixed
> the problem for me).

I can see his point of view, the chroot environment is something that exists 
only while doing the installation and as such is a temporary dodge so that you 
can do it. No binary distro runs sshd in the chroot it creates while 
performing the install either.

The supported method is to ssh into the "LiveCD" environment then chroot from 
that shell. It's hard to imagine a scenario where you would have more than one 
user doing that at the same time, so why run sshd in the chroot at all?

> See https://bugs.gentoo.org/show_bug.cgi?id=296073
> 
> Seems to me, reporting problems to Gentoo is a waste of time, at least
> documentation problems.

That is a classic case of applying a specific case to the general case. You 
had a problem with one specific dev regarding one specific bug relating to one 
specific piece of documentation. To then assert that contributing anything to 
any aspect of Gentoo documentation is pointless merely on the basis of one 
experience is disingenuous to say the least.

-- 
alan dot mckinnon at gmail dot com

Re: [gentoo-user] Problems setting up sshd on an installation kernel

[Alan Mackenzie]

Hi, Alan,

Thanks for the quick reply.

On Wed, Dec 09, 2009 at 05:43:50PM +0200, Alan McKinnon wrote:
> On Wednesday 09 December 2009 17:24:16 Alan Mackenzie wrote:
> > > My first thought as well... I'd guess, just at a glance, that sshd was
> > > started in the chroot, and that /mnt/gentoo/dev/ is bind mounted
> > > properly, but /mnt/gentoo/dev/pts/ isn't.

> > As said, I fixed the problem by mounting /dev with --rbind.  This
> > misunderstanding cost me, perhaps, 10 hours of my time.

> > I then reported my problem to the bug tracker, suggesting that the manual
> > should be amended to say "--rbind" here.

> > I really wish I hadn't bothered.  My attempt to contribute was brusquely
> > brushed aside by somebody who didn't even bother to thank me for my
> > trouble (I always thank people reporting bugs to my project), said that
> > he "couldn't reproduce [my] error", and asserted that sshd wasn't meant
> > to work in the chrooted environment (why on Earth not?), implying it was
> > my stupid fault for not following the manual rigidly and droidwise.  To
> > cap it all, he patronisingly referred me to the appropriate sections of
> > the fine manual (that's after my having reported how I'd already fixed
> > the problem for me).

> I can see his point of view, the chroot environment is something that
> exists only while doing the installation and as such is a temporary
> dodge so that you can do it. No binary distro runs sshd in the chroot
> it creates while performing the install either.

However, setting up /dev completely (with --rbind) costs nothing, adds
capability, and takes nothing away.

> The supported method is to ssh into the "LiveCD" environment then
> chroot from that shell. It's hard to imagine a scenario where you would
> have more than one user doing that at the same time, so why run sshd in
> the chroot at all?

If you run sshd in the bare installation (as suggested), the ssh client
has to update his ~/.ssh/known_hosts every time the system is booted
(what?  There are people who only boot it once before getting Gentoo
completely installed? ;-).  When sshd'ing from within the chrooted
environment, the ssh client has to add an entry to known_hosts just once,
and this entry will persist even when the embryonic gentoo has been fully
installed and configured.

More to the point, though, is that the manual doesn't explicitly state
that sshd must be started from outside the chroot.  It sort of implies
it, but doesn't emphasise it.  Reading the manual, it was clear to me
that it didn't matter (turns out I was wrong).  Also, people are going to
be running sshd on their own initiative, and it seems perverse knowingly
to leave a hindrance on one of the two ways they'll choose to do it.

This situation cost me around 10 hours of frustration.  Looks like I'll
not be the last victim.

> > See https://bugs.gentoo.org/show_bug.cgi?id=296073

> > Seems to me, reporting problems to Gentoo is a waste of time, at least
> > documentation problems.

> That is a classic case of applying a specific case to the general case.
> You had a problem with one specific dev regarding one specific bug
> relating to one specific piece of documentation. To then assert that
> contributing anything to any aspect of Gentoo documentation is
> pointless merely on the basis of one experience is disingenuous to say
> the least.

What you write is indeed true, but only up to a point.  I reported how
things "seem to me", and truly hope that my experience is not typical.
By contrast, the posters on gentoo-user, including yourself, have been
very helpful indeed.  Thank you!

> -- 
> alan dot mckinnon at gmail dot com

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [gentoo-user] Problems setting up sshd on an installation kernel

[Alan McKinnon]

On Wednesday 09 December 2009 18:46:11 Alan Mackenzie wrote:
> > The supported method is to ssh into the "LiveCD" environment then
> > chroot from that shell. It's hard to imagine a scenario where you would
> > have more than one user doing that at the same time, so why run sshd in
> > the chroot at all?
> 
> If you run sshd in the bare installation (as suggested), the ssh client
> has to update his ~/.ssh/known_hosts every time the system is booted
> (what?  There are people who only boot it once before getting Gentoo
> completely installed? ;-).  When sshd'ing from within the chrooted
> environment, the ssh client has to add an entry to known_hosts just once,
> and this entry will persist even when the embryonic gentoo has been fully
> installed and configured.
> 
> More to the point, though, is that the manual doesn't explicitly state
> that sshd must be started from outside the chroot.  It sort of implies
> it, but doesn't emphasise it.  Reading the manual, it was clear to me
> that it didn't matter (turns out I was wrong).  Also, people are going to
> be running sshd on their own initiative, and it seems perverse knowingly
> to leave a hindrance on one of the two ways they'll choose to do it.
> 
> This situation cost me around 10 hours of frustration.  Looks like I'll
> not be the last victim.

All I can add is that if I were the maintainer, I wouldn't support what you 
are asking either. Installation is supposed to be an atomic operation - it 
starts then continues till it ends. It either fully completes or is considered 
to not have happened, meaning that persistence is diametrically opposed to 
what an install is. It's analogous to a compile - terminating compilation at 
some arbitrary point then picking up from where it ended at some later point 
is just not supported. Possible yes, but not supported by default.

But it's easy to get what you want: take what is there, modify it and create a 
fork. You become the maintainer of the fork and can accept or decline 
suggestions as you see fit.

-- 
alan dot mckinnon at gmail dot com

Re: [gentoo-user] Problems setting up sshd on an installation kernel

[Stroller]

On 9 Dec 2009, at 19:42, Alan McKinnon wrote:
> ...
> Installation is supposed to be an atomic operation - it
> starts then continues till it ends. It either fully completes or is  
> considered
> to not have happened, meaning that persistence is diametrically  
> opposed to
> what an install is. It's analogous to a compile - terminating  
> compilation at
> some arbitrary point then picking up from where it ended at some  
> later point
> is just not supported. Possible yes, but not supported by default.

I'd disagree with you on that point, assuming I'm reading you right.

If a compile fails it shouldn't be an "unsupported" situation. One  
should be able to reemerge the package, possibly after emerging a  
required dependency first. That should work just fine (and surely it  
always does?).

Likewise it's not at all uncommon to make a mistake during the  
installation process - to miss out an essential kernel driver or  
package, and find that the installation fails to boot. The way I  
interpret your statement is that the supported remedy is to start  
again completely from scratch. Clearly this is not what one does - one  
boots again with the LiveCD, chroots into the installation, makes the  
fix and then reboots again to see if the system is now fixed. Every  
new Gentoo user has to do this a number of times, it is our standard  
advice to them, and we, as experienced users, will still have to do  
the same thing occasionally due to our own oversights.

However, I would agree with you that resolving Alan Mackenzie's  
problems with ssh should not be a priority. The "standard" procedure  
should be written for a user sitting in front of the machine on which  
Gentoo is being installed. Installing via SSH is an "advanced"  
procedure and should be considered to be undertaken by users who know  
what they're doing. The requirement to rarely remove a line from  
~/.ssh/known_hosts is really not much hassle.

I am somewhat surprised that Mr Mackenzie managed  to waste as much  
time as 10 hours attempting to SSH into the "wrong" environment, as it  
has never occurred to me to do it that way around, and Florian posted  
appropriate advice to resolve the problem less than 2 hours after  
Alan's original post.

I think this is typical of the kind of mistake we all make and learn  
from - we have all wasted 10 hours on some occasion, only to kick  
ourselves afterwards. When we do this we learn never again to make the  
same mistake.

On 9 Dec 2009, at 16:46, Alan Mackenzie wrote:
> However, setting up /dev completely (with --rbind) costs nothing, adds
> capability, and takes nothing away.

It is not clear to me that this is the "obvious" and "optimal"  
solution. It may be. I cannot foresee whether it may introduce side- 
effects.

Stroller.

Re: [gentoo-user] Problems setting up sshd on an installation kernel

[Alan McKinnon]

On Wednesday 09 December 2009 23:57:18 Stroller wrote:
> On 9 Dec 2009, at 19:42, Alan McKinnon wrote:
> > ...
> > Installation is supposed to be an atomic operation - it
> > starts then continues till it ends. It either fully completes or is  
> > considered
> > to not have happened, meaning that persistence is diametrically  
> > opposed to
> > what an install is. It's analogous to a compile - terminating  
> > compilation at
> > some arbitrary point then picking up from where it ended at some  
> > later point
> > is just not supported. Possible yes, but not supported by default.
> 
> I'd disagree with you on that point, assuming I'm reading you right.
> 
> If a compile fails it shouldn't be an "unsupported" situation. One  
> should be able to reemerge the package, possibly after emerging a  
> required dependency first. That should work just fine (and surely it  
> always does?).

I made an analogy, a poor one :-), which only goes as far as it goes (and 
that's not very far). I meant that if gcc is running and compiling some 
arbitrary .c and you hit ^C, there's no magic incantation to tell gcc to find 
what it was doing and continue from that point as if the interruption never 
happened.

Likewise with installation - you can't just decide to stop halfway, shut the 
box down and continue tomorrow expecting the software to pick up where you 
left off automagically (without you having to do anything extra). Consider 
*any* installation media of your choice for *any* OS; none of them that I have 
ever used allow you to interrupt the install and continue later.

I see no reason why the install dev and the doc dev should support such a feat 
on Gentoo even if it is technically feasible.

> Likewise it's not at all uncommon to make a mistake during the  
> installation process - to miss out an essential kernel driver or  
> package, and find that the installation fails to boot. The way I  
> interpret your statement is that the supported remedy is to start  
> again completely from scratch. Clearly this is not what one does

Correct, one normally redoes the setup commands:
boot, mkdir, mount, mkmoredirs, more mount, mount proc, chroot, cp resolv.conf
etc etc etc and continue. This only works because any data written to the disk 
during $INSTALL_ATTEMPT_1 is persistent by virtue of it being written to 
*disk*. And there is no need to untar a stage all over again.

By happy coincidence, oftentimes after chrooting one finds an environment that 
has everything required to run sshd, but there is no guarantee of that at all. 
So one can try start sshd, if it works then all well and good, if not then 
that's tough. Either way the human running the show is on his own with this 
one.

I still maintain that the doc dev is correct in refusing to document such a 
thing - it's way too unreliable and uncertain to even warrant a mention.

-- 
alan dot mckinnon at gmail dot com

Re: [gentoo-user] Problems setting up sshd on an installation kernel

[Alan Mackenzie]

Hi, Stroller,

On Wed, Dec 09, 2009 at 09:57:18PM +0000, Stroller wrote:

> On 9 Dec 2009, at 19:42, Alan McKinnon wrote:
> >...
> >Installation is supposed to be an atomic operation - it starts then
> >continues till it ends. It either fully completes or is  considered to
> >not have happened, meaning that persistence is diametrically  opposed
> >to what an install is. It's analogous to a compile - terminating
> >compilation at some arbitrary point then picking up from where it
> >ended at some  later point is just not supported. Possible yes, but
> >not supported by default.

> I'd disagree with you on that point, assuming I'm reading you right.

> If a compile fails it shouldn't be an "unsupported" situation. One  
> should be able to reemerge the package, possibly after emerging a  
> required dependency first. That should work just fine (and surely it  
> always does?).

> Likewise it's not at all uncommon to make a mistake during the  
> installation process - to miss out an essential kernel driver or  
> package, and find that the installation fails to boot. The way I  
> interpret your statement is that the supported remedy is to start  
> again completely from scratch. Clearly this is not what one does - one  
> boots again with the LiveCD, chroots into the installation, makes the  
> fix and then reboots again to see if the system is now fixed. Every  
> new Gentoo user has to do this a number of times, it is our standard  
> advice to them, and we, as experienced users, will still have to do  
> the same thing occasionally due to our own oversights.

Thanks!  ;-)

> However, I would agree with you that resolving Alan Mackenzie's  
> problems with ssh should not be a priority.

For filesystem checking's sake!  My personal problem has been solved.
The /dev directory in the newly chrooted system is broken.  I simply
asked the project to fix it, provided the fix, and the fix is replacing
6 characters in a file with 6 different characters.

Now, at this stage, people say "it isn't broken, because you can do
everything in it that we've decided you need to do.".  Let's just say
this isn't in the spirit of free software.  ;-)

How did this breakage happen?  I would guess that at the time the
installation procedure was devised, this line

    # mount -o bind /dev /mnt/gentoo/dev

worked perfectly OK, since /dev didn't have any subdirectories.  Some
time recently, /dev acquired subdirectories (e.g. /dev/pts), but nobody
realised this would render the chrooted system less capable.

Now, how much work would it cost to replace that line in the manual with

    # mount --rbind /dev /mnt/gentoo/dev

, compared with the cost of all this correspondence?  Instead, the
maintainer spent all his energy telling me I'm stupid for wanting to do
what I wanted to do.

> The "standard" procedure  should be written for a user sitting in front
> of the machine on which  Gentoo is being installed. Installing via SSH
> is an "advanced"  procedure and should be considered to be undertaken
> by users who know  what they're doing. The requirement to rarely remove
> a line from  ~/.ssh/known_hosts is really not much hassle.

The machine I was installing on was a laptop with no available desk top
to place it on.  Therefore I decided to get SSH up and running as early
as possible so as to do the bulk of the installation from my nice comfy
desktop, monitor and keyboard.  Starting sshd from inside the chrooted
system was obviously the Right Thing.

> I am somewhat surprised that Mr Mackenzie managed  to waste as much  
> time as 10 hours attempting to SSH into the "wrong" environment, ....

That's starting from "ssh doesn't work", realising that the ssh server
was validating my password (or key, I've forgotten which), and then doing
nothing.  It's the time taken to go through sshd_config looking for
stupidities.  It's the time taken to read various manual pages, try out
various methods of dumping debug info, to the point of getting the vague
irritating error message: "file not found".  It's the time taken to set
up logging facilities, on the (false) hypothesis that it couldn't find a
logging file.  It's the time taken to post my problem on
comp.os.linux.setup, and fail to get an answer there.  It's the time
taken to post the problem again on this mailing list, and get the answer
from Joshua, to whom I'm most grateful.

> .... as it  has never occurred to me to do it that way around, and
> Florian posted  appropriate advice to resolve the problem less than 2
> hours after  Alan's original post.

> I think this is typical of the kind of mistake we all make and learn  
> from - we have all wasted 10 hours on some occasion, only to kick  
> ourselves afterwards. When we do this we learn never again to make the  
> same mistake.

With all due respect, it wasn't my mistake, or if you disagree here
we'll just have to agree to disagree ;-).  /dev is broken.

> On 9 Dec 2009, at 16:46, Alan Mackenzie wrote:
> >However, setting up /dev completely (with --rbind) costs nothing, adds
> >capability, and takes nothing away.

> It is not clear to me that this is the "obvious" and "optimal"  
> solution. It may be. I cannot foresee whether it may introduce side- 
> effects.

I can.  There won't be any.  Think about it, before /dev/ acquired
subdirectories, having a fully functional /dev didn't have negative side
effects.  So why should restoring it to full functionality have side
effects now?

> Stroller.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [gentoo-user] Problems setting up sshd on an installation kernel

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 726 bytes --]

On Thu, 10 Dec 2009 10:36:41 +0000, Alan Mackenzie wrote:

> The machine I was installing on was a laptop with no available desk top
> to place it on.  Therefore I decided to get SSH up and running as early
> as possible so as to do the bulk of the installation from my nice comfy
> desktop, monitor and keyboard.  Starting sshd from inside the chrooted
> system was obviously the Right Thing.

Surely starting sshd from the live environment is The Right Thing if you
want to get SSH running as soon as possible? That's how I've always done
it.


-- 
Neil Bothwick

Some people are born mediocre, some people achieve mediocrity, and some
people have mediocrity thrust upon them.  - Joseph Heller, "Catch-22"

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Problems setting up sshd on an installation kernel

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 998 bytes --]

Hi Neil and all,

On Thu, Dec 10, 2009 at 02:23:13PM +0000, Neil Bothwick wrote:
> On Thu, 10 Dec 2009 10:36:41 +0000, Alan Mackenzie wrote:
> 
> > The machine I was installing on was a laptop with no available desk top
> > to place it on.  Therefore I decided to get SSH up and running as early
> > as possible so as to do the bulk of the installation from my nice comfy
> > desktop, monitor and keyboard.  Starting sshd from inside the chrooted
> > system was obviously the Right Thing.
> 
> Surely starting sshd from the live environment is The Right Thing if you
> want to get SSH running as soon as possible? That's how I've always done
> it.
 
You can actually start sshd as part of the boot process if your network
is automatically configured by adding something like this to what you
already type at the boot prompt:

dosshd passwd=rootpassword

I'm not sure why you would want to run sshd inside the chrooted
environment since it runs fine from the cd.

William


[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Problems setting up sshd on an installation kernel

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 1344 bytes --]

On Thursday 10 December 2009 14:23:13 Neil Bothwick wrote:
> On Thu, 10 Dec 2009 10:36:41 +0000, Alan Mackenzie wrote:
> > The machine I was installing on was a laptop with no available desk top
> > to place it on.  Therefore I decided to get SSH up and running as early
> > as possible so as to do the bulk of the installation from my nice comfy
> > desktop, monitor and keyboard.  Starting sshd from inside the chrooted
> > system was obviously the Right Thing.
> 
> Surely starting sshd from the live environment is The Right Thing if you
> want to get SSH running as soon as possible? That's how I've always done
> it.

Last time I read the docs (and that was some years ago) you would also launch 
screen, then detach/reattach the session after you ssh'ed into your LiveCD 
env.  In that sense rebooting the LiveCD is not something you would do more 
than once - unless there was something wrong with kernel you just rolled up.  
Hold on, I found it:

http://www.gentoo.org/doc/en/gentoo-x86-tipsntricks.xml#leave_terminal

However, I find what Alan Mackenzie says fairly sensible and something which 
is a rather simple amendment for the gentoo handbook.  The suggested change 
should not (I think) cause any side effects on a conventional install, so it 
should be accepted.

Just my 2c's.
-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Problems setting up sshd on an installation kernel

[Willie Wong]

On Thu, Dec 10, 2009 at 10:36:41AM +0000, Penguin Lover Alan Mackenzie squawked:
> How did this breakage happen?  I would guess that at the time the
> installation procedure was devised, this line
> 
>     # mount -o bind /dev /mnt/gentoo/dev
> 
> worked perfectly OK, since /dev didn't have any subdirectories.  Some
> time recently, /dev acquired subdirectories (e.g. /dev/pts), but nobody
> realised this would render the chrooted system less capable.

Just to be pedantic.

Not subdirectories. 'mount --bind' binds the directory tree. What /dev
picked up was submounts, which is why you issued 'mount --rbind' as a
workaround. (The mount manpage I think has something about devpts.) 

I wonder if 'mount -t devpts devpts /dev/pts' is a better workaround
for your problem, though. 

Cheers, 

W

-- 
M: Hot almond milk. Best stuff on earth.
Sortir en Pantoufles: up 1098 days, 14:03

Re: [gentoo-user] Problems setting up sshd on an installation kernel

[Joshua Murphy]

On Thu, Dec 10, 2009 at 10:27 AM, Willie Wong <wwong@math.princeton.edu> wrote:
> On Thu, Dec 10, 2009 at 10:36:41AM +0000, Penguin Lover Alan Mackenzie squawked:
>> How did this breakage happen?  I would guess that at the time the
>> installation procedure was devised, this line
>>
>>     # mount -o bind /dev /mnt/gentoo/dev
>>
>> worked perfectly OK, since /dev didn't have any subdirectories.  Some
>> time recently, /dev acquired subdirectories (e.g. /dev/pts), but nobody
>> realised this would render the chrooted system less capable.
>
> Just to be pedantic.
>
> Not subdirectories. 'mount --bind' binds the directory tree. What /dev
> picked up was submounts, which is why you issued 'mount --rbind' as a
> workaround. (The mount manpage I think has something about devpts.)
>
> I wonder if 'mount -t devpts devpts /dev/pts' is a better workaround
> for your problem, though.
>
> Cheers,
>
> W
>
> --
> M: Hot almond milk. Best stuff on earth.
> Sortir en Pantoufles: up 1098 days, 14:03

That one only works if the kernel of your install disk is configured
to allow multiple instances of devpts to be mounted
(CONFIG_DEVPTS_MULTIPLE_INSTANCES) ... I'm in no way certain if that's
enabled on the Gentoo generated livecds, currently.

-- 
Poison [BLX]
Joshua M. Murphy

Re: [gentoo-user] Problems setting up sshd on an installation kernel

[Alan Mackenzie]

Hi, Alan,

On Wed, Dec 09, 2009 at 09:42:56PM +0200, Alan McKinnon wrote:
> On Wednesday 09 December 2009 18:46:11 Alan Mackenzie wrote:
> > > The supported method is to ssh into the "LiveCD" environment then
> > > chroot from that shell. It's hard to imagine a scenario where you
> > > would have more than one user doing that at the same time, so why
> > > run sshd in the chroot at all?

> > If you run sshd in the bare installation (as suggested), the ssh
> > client has to update his ~/.ssh/known_hosts every time the system is
> > booted (what?  There are people who only boot it once before getting
> > Gentoo completely installed? ;-).  When sshd'ing from within the
> > chrooted environment, the ssh client has to add an entry to
> > known_hosts just once, and this entry will persist even when the
> > embryonic gentoo has been fully installed and configured.

> > More to the point, though, is that the manual doesn't explicitly
> > state that sshd must be started from outside the chroot.  It sort of
> > implies it, but doesn't emphasise it.  Reading the manual, it was
> > clear to me that it didn't matter (turns out I was wrong).  Also,
> > people are going to be running sshd on their own initiative, and it
> > seems perverse knowingly to leave a hindrance on one of the two ways
> > they'll choose to do it.

> > This situation cost me around 10 hours of frustration.  Looks like
> > I'll not be the last victim.

> All I can add is that if I were the maintainer, I wouldn't support what
> you are asking either.

What you seem to be missing is that this change COSTS NOTHING, bar the
time it takes to change a few bytes of source code, recompile and commit.
Nothing which previously worked would cease to work, and the amount of
support required would decrease or stay the same.

> Installation is supposed to be an atomic operation - it starts then
> continues till it ends. It either fully completes or is considered to
> not have happened, meaning that persistence is diametrically opposed to
> what an install is.

OK, we don't live on the same planet.  I have never completed a Linux
installation in a single sitting, and don't expect ever to do so.
Particularly on a distribution like Gentoo where so much has to be done
by hand.  (That's not a criticism, by the way.  It's one of the things
which has attracted me to Gentoo.)  You and others around this list might
be supermen, I'm not, and I feel no shame about it.

> It's analogous to a compile - terminating compilation at some arbitrary
> point then picking up from where it ended at some later point is just
> not supported.

That analogy is so week as to be meaningless.  Installation, unlike
compilation, consists of a large number of discrete manual steps, and it
is silly to suggest that if you don't finish by bedtime you should wipe
the hard drive and start again from scratch when you get up in the
morning.

> Possible yes, but not supported by default.

The manual neither states nor implies that you've got to finish at one
sitting.  The only difficulty, and it's not much of one, is working out
how to restart in the middle.  Hey, even I managed that.

> But it's easy to get what you want: take what is there, modify it and
> create a fork. You become the maintainer of the fork and can accept or
> decline suggestions as you see fit.

Oh, that old stuff.  No thanks, Alan, I've got quite enough to do
supporting my own project (Emacs CC Mode).  I'll just carry on with my
own way of doing things, "supported" or not.  I'll keep my bright ideas
and "customer feedback" to myself from now on, since nobody here seems to
want them.  But I'll ask for help when I need it - you guys are great at
helping, and that's most appreciated.

Thanks for the chat, and good night for now!

> -- 
> alan dot mckinnon at gmail dot com

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [gentoo-user] Problems setting up sshd on an installation kernel

[Stroller]

On 9 Dec 2009, at 22:35, Alan Mackenzie wrote:
> ...
>> Installation is supposed to be an atomic operation - it starts then
>> continues till it ends. It either fully completes or is considered to
>> not have happened, meaning that persistence is diametrically  
>> opposed to
>> what an install is.
>
> OK, we don't live on the same planet.  I have never completed a Linux
> installation in a single sitting, and don't expect ever to do so.
> Particularly on a distribution like Gentoo where so much has to be  
> done
> by hand.  (That's not a criticism, by the way.  It's one of the things
> which has attracted me to Gentoo.)  You and others around this list  
> might
> be supermen, I'm not, and I feel no shame about it.

You only chroot after untarring the stage 3.

When you do chroot then you emerge grub, the kernel and add sshd to  
the default runlevel.

Remove the live CD, reboot.

Job done.

Obviously there's a lot more to do after this to get a *fully working*  
operating system, but you should by this stage now be able to boot  
from the hard-drive into your embryonic system, and from there you can  
add a user, a system logger, cron, perform updates &c.

Stroller.

Re: [gentoo-user] Problems setting up sshd on an installation kernel

[Stroller]

On 9 Dec 2009, at 16:46, Alan Mackenzie wrote:
> ...
> (what?  There are people who only boot it once before getting Gentoo
> completely installed? ;-).

Yes, absolutely. I would consider this to be the normal scenario.

>  When sshd'ing from within the chrooted
> environment, the ssh client has to add an entry to known_hosts just  
> once,
> and this entry will persist even when the embryonic gentoo has been  
> fully
> installed and configured.

Well, it was totally worth wasting 10 hours of your time not to have  
to delete one line of a text file.  ;)

FWIW I have in .bashrc:

    alias ssg="ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/ 
dev/null"


I do totally sympathise with you on trying to open bugs & improve  
Gentoo. I have been brushed off and received snotty responses from  
devs on a number of occasions. They're either a bunch of arrogant  
knobs, or they simply deal with bugs in a terse manner (which, totally  
unintended, happens to offend certain people such as you & I). I  
suppose charitably we must assume the latter.

Stroller.
  

Re: [gentoo-user] Problems setting up sshd on an installation kernel

[Dale]

Stroller wrote:
>
> On 9 Dec 2009, at 16:46, Alan Mackenzie wrote:
>> ...
>> (what?  There are people who only boot it once before getting Gentoo
>> completely installed? ;-).
>
> Yes, absolutely. I would consider this to be the normal scenario.

+1  I have done that several times, even over ssh to another country. 

>
>>  When sshd'ing from within the chrooted
>> environment, the ssh client has to add an entry to known_hosts just 
>> once,
>> and this entry will persist even when the embryonic gentoo has been 
>> fully
>> installed and configured.
>
> Well, it was totally worth wasting 10 hours of your time not to have 
> to delete one line of a text file.  ;)
>
> FWIW I have in .bashrc:
>
>    alias ssg="ssh -o StrictHostKeyChecking=no -o 
> UserKnownHostsFile=/dev/null"
>
>
> I do totally sympathise with you on trying to open bugs & improve 
> Gentoo. I have been brushed off and received snotty responses from 
> devs on a number of occasions. They're either a bunch of arrogant 
> knobs, or they simply deal with bugs in a terse manner (which, totally 
> unintended, happens to offend certain people such as you & I). I 
> suppose charitably we must assume the latter.
>
> Stroller.
>  

+1 here too.  I haven't filed a bug in a while although I have found a 
couple.  I also very rarely post on -dev.  I learned that if you don't 
say anything, they don't know you are there to bite on.  ;-)   Sort of 
like a fly on the wall.

Dale

:-)  :-) 

Re: [gentoo-user] Problems setting up sshd on an installation kernel

[Alan Mackenzie]

Hi, Florian,

On Sun, Dec 06, 2009 at 05:59:00PM +0100, Florian Philipp wrote:
> Alan Mackenzie schrieb:

> > 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.

> [...]

> > 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?


> Where did you start sshd, in the chrooted environment or on the live cd
> itself?

In the chrooted environment.  When I start it directly in the live cd
session, it seems to work just fine.

When it works (from live cd), it creates a device file /dev/pts/0 in
(presumably) the installation ram disk.  When it doesn't work (from
chrooted environment) it fails to create /dev/pts/0, even though /dev/pts
exists inside the chrooted root filesystem.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [gentoo-user] Problems setting up sshd on an installation kernel

[Walter Dnes]

On Sun, Dec 06, 2009 at 02:48:36PM +0000, Alan Mackenzie wrote
> 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.

  Has your install gotten to the stage where you can chroot and emerge
and unmerge.  If so, I would suggest the following...
  1) unmerge pam.  *DO NOT LOGOUT OR REBOOT*
  2) put the line
sys-libs/pam
     in /etc/portage/package.mask Create the file if it doesn't exist.
  3) emerge shadow *BEFORE YOU LOG OUT OR REBOOT*.

  Pam is an extra-high-security option that makes sense on a public
server with lots of people being able to log in.  On a personal laptop
it is overkill.  There was a comedy album once that was called...
"Everything You Know Is Wrong".  That describes Pam.  The security
settings for various services are in totally different files and
locations than normal.

  Are you still booting from the install CD? The way you are running
sshd is not how the install manual suggests to do it.  The webpage...
http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=1&chap=2
shows that you can pass the kernel options...

dosshd passwd=temppassword

at bootup, where "temppassword" is a temporary password.  This allows
you to log in by typing the temporary password.

-- 
Walter Dnes <waltdnes@waltdnes.org>

Re: [gentoo-user] Problems setting up sshd on an installation kernel

[Joshua Murphy]

On Sun, Dec 6, 2009 at 1:36 PM, Walter Dnes <waltdnes@waltdnes.org> wrote:
> On Sun, Dec 06, 2009 at 02:48:36PM +0000, Alan Mackenzie wrote
>> 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.
>
>  Has your install gotten to the stage where you can chroot and emerge
> and unmerge.  If so, I would suggest the following...
>  1) unmerge pam.  *DO NOT LOGOUT OR REBOOT*
>  2) put the line
> sys-libs/pam
>     in /etc/portage/package.mask Create the file if it doesn't exist.
>  3) emerge shadow *BEFORE YOU LOG OUT OR REBOOT*.
>
>  Pam is an extra-high-security option that makes sense on a public
> server with lots of people being able to log in.  On a personal laptop
> it is overkill.  There was a comedy album once that was called...
> "Everything You Know Is Wrong".  That describes Pam.  The security
> settings for various services are in totally different files and
> locations than normal.
>
>  Are you still booting from the install CD? The way you are running
> sshd is not how the install manual suggests to do it.  The webpage...
> http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=1&chap=2
> shows that you can pass the kernel options...
>
> dosshd passwd=temppassword
>
> at bootup, where "temppassword" is a temporary password.  This allows
> you to log in by typing the temporary password.
>
> --
> Walter Dnes <waltdnes@waltdnes.org>

None of which would affect (failing) pty allocation... while I share
the disdain for PAM, it doesn't likely do a whole lot to fix the
problem at hand.

-- 
Poison [BLX]
Joshua M. Murphy

Re: [gentoo-user] Problems setting up sshd on an installation kernel

[Boy Hartsuiker]

On Sun, Dec 06, 2009 at 02:48:36PM +0000, Alan Mackenzie wrote
> 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 experienced something similar once, because I copied a new fstab over
the default installed one. Be sure to have this line in /etc/fstab:

devpts /dev/pts devpts rw,nosuid,noexec,gid=5,mode=620 0 0