Re: enable telnetd?
Felix Miata wrote: > Dan Purgert composed on 2016-06-02 19:57 (UTC): > >> Felix Miata wrote: > >>> I have no interest in answers explaining ssh and security risk. These are >>> understood. All I'm interested in is capturing dmesg and logs from a test >>> installation while normal logins are busy with segfaulting or otherwise >>> inaccessible. > >> well, if /dev/tty# is shot because segfaulting (or otherwise >> inaccessible), I wouldn't expect telnetd to help there any (unless >> telnet uses a different pool of ttys). > > Actually I would expect it to use a different "pool", but this is not a > subject I know more than a trifle about. Same here :( > [snip] > IOW, current need is past, but I'd still like to know what's wrong and > get it fixed for a possible next time. Good that you found / fixed the problem. >> Would a serial console (i.e. /dev/ttyS0) suit your needs? > > Probably not well, something yet else to configure that I haven't > needed to do in more than two decades, another cable to locate and > connect, and likely for a one time only use. Or can serial connection > be shared over existing ethernet? No, serial connections are via serial ports, and won't traverse ethernet networks (though you could probably get ethernet -> serial modems if you really wanted to). I have enough random network hardware that uses serial consoles between my desk (a.k.a. "test bench") and my main network kit, that adding in a serial null-modem cable for the server was 'no big deal' - just some config changes in /etc/inittab, and running out to Microcenter. After having more than a few occasions where something was mis-behaving sufficently to *require* serial console access (thanks buggy router flash media), it's becoming one of those things that I look for now, and will spend extra money to get. Sure, I might only use it once or twice ever in the lifetime of the product (this being "at home" and all) ... but it's cheap insurance. -- Registered Linux user #585947 Github: https://github.com/dpurgert
Re: enable telnetd?
On 06/03/2016 05:20 AM, Felix Miata wrote: [snip] > When I wrote, I hadn't yet learned that the problem that made me want to > use Telnet was known, and a patch already submitted, but not yet > included in an update available on the mirrors: > https://github.com/systemd/systemd/issues/3339 [snip] > Dan Purgert composed on 2016-06-02 19:57 (UTC): >> Would a serial console (i.e. /dev/ttyS0) suit your needs? > > Probably not well, something yet else to configure that I haven't needed > to do in more than two decades, another cable to locate and connect, and > likely for a one time only use. Or can serial connection be shared over > existing ethernet? If the machines have two serial ports, they can be grouped pairs such that the serial console of one is connected to the second port of the other. Then you can do just about everything except turn the power on again (unless you have Wake-on-LAN set up too) from the other machine using cu, tip, or minicom or screen. But anything you can do from the console itself you can then do from the other machine in the pair. If it was just a matter of having a different daemon available to the outside world (or other machines on the LAN) then maybe you could have had the dropbear SSH daemon running on another port. If some of the system is not working maybe the shell could be busybox, but I don't know if that would work for you in this situation. Regards, Lars
Re: enable telnetd?
Dan Purgert composed on 2016-06-02 19:57 (UTC): Felix Miata wrote: I have no interest in answers explaining ssh and security risk. These are understood. All I'm interested in is capturing dmesg and logs from a test installation while normal logins are busy with segfaulting or otherwise inaccessible. well, if /dev/tty# is shot because segfaulting (or otherwise inaccessible), I wouldn't expect telnetd to help there any (unless telnet uses a different pool of ttys). Actually I would expect it to use a different "pool", but this is not a subject I know more than a trifle about. When I wrote, I hadn't yet learned that the problem that made me want to use Telnet was known, and a patch already submitted, but not yet included in an update available on the mirrors: https://github.com/systemd/systemd/issues/3339 IOW, current need is past, but I'd still like to know what's wrong and get it fixed for a possible next time. Would a serial console (i.e. /dev/ttyS0) suit your needs? Probably not well, something yet else to configure that I haven't needed to do in more than two decades, another cable to locate and connect, and likely for a one time only use. Or can serial connection be shared over existing ethernet? -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/
Re: enable telnetd?
Sven Arvidsson composed on 2016-06-02 20:59 (UTC+0200): On Thu, 2016-06-02 at 00:48 -0400, Felix Miata wrote: Google cannot provide an answer to configuring telnetd WRT Debian, only WRT every other distro on the planet. When I try to login after installing telnetd and seeing xinetd enabled, login name is always greeted with "Login incorrect". Telnet login works in openSUSE and Fedora via /etc/pam.d/remote, but that file is missing in Stretch, and copying one from openSUSE doesn't have any apparent effect. I have no interest in answers explaining ssh and security risk. These are understood. All I'm interested in is capturing dmesg and logs from a test installation while normal logins are busy with segfaulting or otherwise inaccessible. Does logging in through telnet not work at all, or just not as root? Failure differs. With login root, password entry is not offered. With other user, password entry is offered, but is "incorrect". -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/
Re: enable telnetd?
Felix Miata wrote: > I have no interest in answers explaining ssh and security risk. These are > understood. All I'm interested in is capturing dmesg and logs from a test > installation while normal logins are busy with segfaulting or otherwise > inaccessible. well, if /dev/tty# is shot because segfaulting (or otherwise inaccessible), I wouldn't expect telnetd to help there any (unless telnet uses a different pool of ttys). Would a serial console (i.e. /dev/ttyS0) suit your needs? -- Registered Linux user #585947 Github: https://github.com/dpurgert
Re: enable telnetd?
On Thu, 2016-06-02 at 00:48 -0400, Felix Miata wrote: > Google cannot provide an answer to configuring telnetd WRT Debian, > only WRT > every other distro on the planet. When I try to login after > installing > telnetd and seeing xinetd enabled, login name is always greeted with > "Login > incorrect". Telnet login works in openSUSE and Fedora via > /etc/pam.d/remote, > but that file is missing in Stretch, and copying one from openSUSE > doesn't > have any apparent effect. > > I have no interest in answers explaining ssh and security risk. These > are > understood. All I'm interested in is capturing dmesg and logs from a > test > installation while normal logins are busy with segfaulting or > otherwise > inaccessible. Does logging in through telnet not work at all, or just not as root? -- Cheers, Sven Arvidsson http://www.whiz.se PGP Key ID 6FAB5CD5 signature.asc Description: This is a digitally signed message part
enable telnetd?
Google cannot provide an answer to configuring telnetd WRT Debian, only WRT every other distro on the planet. When I try to login after installing telnetd and seeing xinetd enabled, login name is always greeted with "Login incorrect". Telnet login works in openSUSE and Fedora via /etc/pam.d/remote, but that file is missing in Stretch, and copying one from openSUSE doesn't have any apparent effect. I have no interest in answers explaining ssh and security risk. These are understood. All I'm interested in is capturing dmesg and logs from a test installation while normal logins are busy with segfaulting or otherwise inaccessible. TIA -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/
