On 2014-06-26 09:26 (GMT+0200) Per Jessen composed:

Felix Miata wrote:

...

telnet-server is installed SuSEfirewall2 is not installed shorewall is not installed chkconfig -l says telnet is on telnet is not present in output of systemctl|grep list-unit-files|list-units iptables is not present in output of systemctl|grep list-unit-files|list-units

...

Why $SUBJECT?

What does "netstat -ltn" say? Unless something is listening on port 23, telnet isn't running.

Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN

I'm not sure if telnet is provided via xinetd or not.

'telnet: on' is among the xinetd based services in chkconfig -l output. -- "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/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 2014-06-26 11:17 (GMT+0200) Per Jessen composed:

...

...

What does "netstat -ltn" say? Unless something is listening on port 23, telnet isn't running.

...

Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN

There you go, that is the cause of $SUBJ :-)

...

...

I'm not sure if telnet is provided via xinetd or not.

...

'telnet: on' is among the xinetd based services in chkconfig output.

Perhaps xinetd wasn't restarted when you enabled telnet? Installing telnet-server probably just drops a file into /etc/xinetd.d .

This has been on 13.1 and 13.2 installations on multiple systems booted multiple times. I got xinitd going early on, but that was only a minor first obstacle. The current obstacle is getting PAM, /etc/securetty, /etc/xinetd.d/*, /etc/xinetd.conf, etc. figured out after the recent auth overhaul obsoleting everything understandable Googling could find me. -- "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/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 2014-06-26 09:34 (GMT+0200) Andreas Schwab composed:

Felix Miata writes:

...

chkconfig -l says telnet is on

Do you have xinetd started?

I didn't, because I never knew what it was good for, much less that it was required by telnet-server in order to work. Now that the subject error message is gone, it still doesn't work. Simply typing a username at the login prompt produces "Login incorrect" in both 13.1 and Factory. -- "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/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 2014-06-26 10:24 (GMT+0200) Andreas Schwab composed:

Felix Miata wrote:

...

Now that the subject error message is gone, it still doesn't work. Simply typing a username at the login prompt produces "Login incorrect" in both 13.1 and Factory.

Root login is not allowed.

It's not your machine, it's mine, a multi-multiboot test machine infrequently used, with no users *except* root[1]. How does it get disallowed? It's not disallowed in Rawhide or by my Linux STBs. [1] https://bugzilla.novell.com/show_bug.cgi?id=833253 -- "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/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 2014-06-26 10:36, Felix Miata wrote:

On 2014-06-26 10:24 (GMT+0200) Andreas Schwab composed:

...

Root login is not allowed.

It's not your machine, it's mine, a multi-multiboot test machine infrequently used, with no users *except* root[1]. How does it get disallowed? It's not disallowed in Rawhide or by my Linux STBs.

Why not use ssh then? It does allow login as root, and is easier to install nowdays. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

Felix Miata wrote:

On 2014-06-26 11:02 (GMT+0200) Carlos E. R. composed:

...

Why not use ssh then? It does allow login as root, and is easier to install nowdays.

I object on general principle to being told I can't do something with my own equipment on my own LAN.

Felix, nobody told you that - Andreas just helped you by informing you what the default policy is. You're free to change it of course. Anyway, is this really Factory-related?

That said, you must have missed the implication of "multi-multiboot". ssh is only tolerable[1] the first time used on a system. The next and successive installations require all kinds of overhead because the client keyed on the first used installation.

Sorry, no big deal, Felix. I agree with Carlos, just use ssh and update the clients' ~/.ssh/known_hosts as and when required. I do it all the time.

[1] ssh is not enabled/configured by default, so by the time you need [it you have a chicken<>egg problem.

Just tick the right box at install time. If you install over the network, it's even done for you automatically. -- Per Jessen, Zürich (17.9°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Felix Miata wrote:

On 2014-06-26 11:32 (GMT+0200) Per Jessen composed:

...

Sorry, no big deal, Felix. I agree with Carlos, just use ssh and update the clients' ~/.ssh/known_hosts as and when required.

First one must remember that's what's necessary after not needing remote login for several months or more. It's a tail wagging the dog.

It's not really too difficult - when you try to ssh to a system and the key has been re-generated, you're warned and given the file name and the line-number. Then it's only a couple of keystrokes.

...

...

[1] ssh is not enabled/configured by default, so by the time you [need it you have a chicken<>egg problem.

...

Just tick the right box at install time. If you install over the network, it's even done for you automatically.

As I virtually always install over network, and stumble over ssh with non-zero frequency, I suspect that ain't necessarily so.

A network install to me involves ssh - I virtually always install over the network, but very rarely with physical access. When you install via ssh, ssh is automatically enabled when you're done. -- Per Jessen, Zürich (18.0°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 2014-06-26 11:27, Felix Miata wrote:

On 2014-06-26 11:02 (GMT+0200) Carlos E. R. composed:

...

Why not use ssh then? It does allow login as root, and is easier to install nowdays.

I object on general principle to being told I can't do something with my own equipment on my own LAN. The first boot of any *buntu installation I do I do 'passwd root' to avoid the sudu/su BS trying to configure an installation.

I'm not telling you to do anything. I'm just trying to suggest helpful alternatives, based on what I use.

That said, you must have missed the implication of "multi-multiboot". ssh is only tolerable[1] the first time used on a system. The next and successive installations require all kinds of overhead because the client keyed on the first used installation.

I don't see a problem. Or I don't understand it. If you mean that the ssh client complains that the target machine has changed fingerprints, that has solutions. One is to tell the client to forget the previous fingerprint - this is either a command, for which you get the hint in the error message, or deleting an easy to find line in a text file, and try again. The other is to use a different IP for each of the multiboot installs.

[1] ssh is not enabled/configured by default, so by the time you need it you have a chicken<>egg problem.

True, but it is a single click on the summary system install screen. I have a small cheat-sheet (in actual paper) of absolutely needed customizations I should do directly on installation, on that screen, and I do them. Ticking the ssh one is in fact the easiest of all the modifications I do. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

On 2014-06-26 12:18, Felix Miata wrote:

On 2014-06-26 11:53 (GMT+0200) Carlos E. R. composed:

...

Felix Miata wrote:

But you see, very few people install the telnet server. It has security implications and it was removed many years ago from the default install. People that install it must do it on purpose. This has the consequence that probably nobody tests it, even less as root. You can probably do it, but nobody is (normally) doing it, so very few people know how to activate it.

I tried the figuring out which one before. It makes me cross-eyed trying with the multitude of installations here. The need to forget each time is another one of those things I disagree with on principle.

Well, that is a very sensible default security measure. You may not want/need it, but that setting must not be disabled by the distribution defaults.

I'm spoiled by the simplicity of NFS, where all needs done to configure is provide an IP range on the server, and what needs doing between machines is easily done.

NFS is designed for a secured intranet, whereas ssh is designed for an insecure network, including Internet. In fact, some of us need an NFS with some features of ssh.

...

The other is to use a different IP for each of the multiboot installs.

That would never work here, too many installations on too many machines.

There is another possibility, which is replacing the signature identifiers on all those installs on the same machine, so that they match and the ssh client doesn't complain. It may be some of the *key files in /etc/ssh/, but I don't know which. Probably all these in /etc/ssh/sshd_config: # HostKey for protocol version 1 #HostKey /etc/ssh/ssh_host_key # HostKeys for protocol version 2 #HostKey /etc/ssh/ssh_host_rsa_key #HostKey /etc/ssh/ssh_host_dsa_key #HostKey /etc/ssh/ssh_host_ecdsa_key

...

True, but it is a single click on the summary system install screen. I have a small cheat-sheet (in actual paper) of absolutely needed customizations I should do directly on installation, on that screen, and

Mine wouldn't fit on one letter sheet in a type size big enough for me to read. :-p I do the ones I remember from memory and scanning various categories, then taboo those I don't want out of the summary list.

That's the list of packages. Different thing.

...

I do them. Ticking the ssh one is in fact the easiest of all the modifications I do.

ISTR simply having it installed in a systemd world isn't sufficient. Life was oh so much simpler using chkconfig.

Not installing. On the summary screen during openSUSE DVD installation, a single screen, at the bottom there is a one click item to enable/disable the sshd server or not, and to open it on the firewall. A single click, very visible and simple to use. Click it, and it works out of the box on first boot. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

James Knott wrote:

On 06/26/2014 08:25 AM, Carlos E. R. wrote:

...

In fact, some of us need an NFS with some features of ssh.

sshfs?

NFS over a vpn? -- Per Jessen, Zürich (21.8°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Thu, Jun 26, 2014 at 2:18 PM, Carlos E. R. wrote:

AFAIK, NFS 3 does not have authentication. You just connect if you have the right IP. An intruder to the building, or a visitor, could connect a new machine and get access to the NFS shares. I recogn that I have not looked carefully at NFS 4 features to find out what has changed there, though.

NFSv4 supports kerberos[0] (authentication, albeit a horrid one if you ask me), and idmapd[1], which maps usernames to uid/gid. [0] https://help.ubuntu.com/community/NFSv4Howto#NFSv4_Server_with_Kerberos [1] https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/... -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Thursday 26 of June 2014 05:27:41 Felix Miata wrote:

I object on general principle to being told I can't do something with my own equipment on my own LAN. The first boot of any *buntu installation I do I do 'passwd root' to avoid the sudu/su BS trying to configure an installation.

Nobody told you you can't. You can configure it and I told you how. Try disabling the pam_securetty.so lines in /etc/pam.d/login and /etc/pam.d/remote (I don't know which of those telnet uses). You just can't demand your preferred configuration to be default. Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Thu, Jun 26, 2014 at 7:52 AM, Felix Miata wrote:

...

Try disabling the pam_securetty.so lines in /etc/pam.d/login and

...there is but one line in that file containing pam_securetty.so, which I've been unable to correlate to what you wrote or anything Googling found, and I've as yet found no way to reconcile the differences.

I have to agree that it's a bit obscure if all you've got to read is the config file. But googling "pam" alone (which seems quite an obvious search string) should have turned this[0], which does seem to explain exactly what that does. [0] http://www.linux-pam.org/Linux-PAM-html/Linux-PAM_SAG.html -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 2014-06-26 16:58, Cristian Rodríguez wrote:

You are not providing enough information.. also, since this is a fairly arcane thing that no one in their right mind should ever use in year 2014.. it is possible for the package to be broken.

Do not use a telnet server, stick with SSH.

I agree, do not use telnet servers. On the other hand, many of use do have to use telnet clients, want it or not. Even on newly bought machines, like routers: only telnet and http, not https. So /they/ are using telnet servers, and force us to use them... The same daft kind of people that supply, no, install, thousands of customers with the same access router with the same password for admin, and the same *WEP* password. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

On 2014-06-26 19:49, James Knott wrote:

On 06/26/2014 01:29 PM, Carlos E. R. wrote:

...

Even on newly bought machines, like routers: only telnet and http, not https. So /they/ are using telnet servers, and force us to use them...

Then you need a regular telnet client, not a server to talk to those boxes.

Absolutely. My intent was to comment that many manufacturers only implement telnet servers on their (new) machines.

Also, many of them, such as Cisco gear also support ssh. In fact, Cisco recommends allowing ssh only. HTTPS is also supported. A ssh client is built in with Linux and, if you're forced to use Windows, you can use PuTTY, which supports ssh, telnet and serial ports.

But that is a serious, expensive, router. My home TP-Link has no "https:" nor "ssh", nor do I see it in the config. cer@Telcontar:~> nmap router.valinor Starting Nmap 6.40 ( http://nmap.org ) at 2014-06-26 20:04 CEST Nmap scan report for router.valinor (192.168.1.1) Host is up (0.019s latency). rDNS record for 192.168.1.1: router Not shown: 997 closed ports PORT STATE SERVICE 23/tcp open telnet 80/tcp open http 1900/tcp open upnp Nmap done: 1 IP address (1 host up) scanned in 0.32 seconds cer@Telcontar:~> Most home routers I have seen are similar. And those same routers are used at small business, not even that small. Those that make do with an ADSL or smallish fiber. My multimedia center, doesn't have natively ssh either, although it has ssh with alternative software from the community. My HP printer has http, not https - and HP surely is a serious manufacturer. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

On 2014-06-26 20:55, James Knott wrote:

On 06/26/2014 02:11 PM, Carlos E. R. wrote:

...

Most home routers I have seen are similar. And those same routers are used at small business, not even that small. Those that make do with an ADSL or smallish fiber.

So why is this a problem that causes you to set up a telnet server? Just telnet and be done with it. Also, those devices are generally accessed from the local network only. Anything that can be accessed from the net should be using ssh or https only.

No, no, it does not causes me to _setup_ a telnet server. You misunderstand. I grumble that I'm forced to connect to important, to me, servers using telnet. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

On 2014-06-26 21:19, James Knott wrote:

On 06/26/2014 03:12 PM, Carlos E. R. wrote:

...

No, no, it does not causes me to _setup_ a telnet server. You misunderstand. I grumble that I'm forced to connect to important, to me, servers using telnet.

Yes I do misunderstand. I thought you were trying to set up a telnet server, when you should be using ssh. If it's someone else's server, then it's their problem. I really fail to understand the need for setting up a telnet server in this day & age. By all means, use a telnet client when you have to, but for your own servers, ssh is the way to go.

Absolutely, absolutely. It is the embedded machines I buy that have only telnet servers, and I can not change them. And I grumble about it. It is Felix who is setting telnet servers on openSUSE ;-) -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday, 2014-06-27 at 13:36 +0100, Sid Boyce wrote:

Hi Carlos, Which embedded systems? So I can avoid them. For the longest time I have been using ssh with Beagleboard, Beaglebone, Pandaboard, ODROID-X, ODROID-U3 and Parallella-16.

Er... by "system" I don't refer to the operating system they run. I refer to machines I buy, with their original firmware. For instance, my tp-link router, about a year old, has neither ssh nor https; same happens to my HP printer. My previous router was the same. Access to a router by a "bad person" is high risk. The command set is limited, but he may access the wifi encryption setup, open ports I do not want opened... Thus, I hesitate to change settings or even access my router config page via wireless, and I hope the thing does not broadcast what it gets via cable to the wifi. Should not, but... The HP printer did get a security related firmware update. I forget why it was. My multimedia center is/was the same; I replaced its firmware with a community one, and now it has ssh, but not by default. But the password is hardcoded anyway, so it does not matter. You say: a multimedia "gadget" is not a high risk machine. Well, it is not, but it happens that it does run a Linux system. Busy box, quite complete. A hacker gaining access to my house somehow could access it and run scripts and things there, and make it his tool. So it /is/ dangerous. - -- Cheers, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlOtvyUACgkQtTMYHG2NR9U2/ACfcPWQkVA623JAXJM3KDF8uBNm 3s8An1SHx1uZqL0UOTxGOdZB/feVlu1b =d9t1 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday, 2014-06-27 at 13:29 +0100, Sid Boyce wrote:

...

misunderstand. I grumble that I'm forced to connect to important, to me, servers using telnet.

I thought telnet was dead decades. I have been using ssh to everything on my network including routers, cable modems, ARM boxes, remote SPARC Enterprise servers, etc.

Mmmm... back on the year 2000, I was working with a group setting up a supervision network for a big telco. One of the things was remote access to old and very expensive machines that didn't know anything about tcp/ip; instead it used local serial port terminals and printers. This were then connected to a special router, and converted to telnet, for remote access. Telnet, not ssh. Via big intranet, so in theory, someone could snoop. Some time before, I saw technicians accessing similar machines via phone and modem, without password. Had some bad body found out, and wanted to, and knew how, he could have caused really huge damage, measured in millions of euros. I'm afraid that a lot of the industry has never used secure practices. Of course, I can only judge by my limited knowledge, I haven't sampled all the industries - LOL. - -- Cheers, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlOtw3wACgkQtTMYHG2NR9UmkQCfUY5mMiXtgZmEcP8qqFlPf2G3 eGUAnjPKIcW7r9UD49lhz1A3qUPLE5TK =UEEN -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

El 26/06/14 13:29, Carlos E. R. escribió:

On 2014-06-26 16:58, Cristian Rodríguez wrote:

...

You are not providing enough information.. also, since this is a fairly arcane thing that no one in their right mind should ever use in year 2014.. it is possible for the package to be broken.

Do not use a telnet server, stick with SSH.

I agree, do not use telnet servers.

On the other hand, many of use do have to use telnet clients.

No argument on having a working telnet client in a distribution, it should work. The value of including the server component in future products is highly questionable though. In any case, it will probably break without human intervention due to bit rotting at anytime. -- Cristian "I don't know the key to success, but the key to failure is trying to please everybody." -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 06/26/2014 03:15 PM, Carlos E. R. wrote:

But maybe there are some environments out there that _do_ have to set them up? :-?

Why??? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 2014-06-26 20:55, Cristian Rodríguez wrote:

El 26/06/14 13:29, Carlos E. R. escribió:

In any case, it will probably break without human intervention due to bit rotting at anytime.

He, on second thoughts, it would be a good thing, for me, that the server bitrotts ASAP. Then the manufacturers that build embedded machines using telnet servers, via.. what's the name? I just can't remember it now... busybox? Yes, that one. Well, if telnet server bitrotts soon, they will eventually be forced to set up sshd instead. Hopefully in my lifetime. :-) -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

On 2014-06-26 22:27, Cristian Rodríguez wrote:

El 26/06/14 15:19, Carlos E. R. escribió:

That's not what I mean, telnet servers in embedded machines will not bitrot, since the underlying components do not change if the firmware is not upgraded. if the firmware is modified, someone has to check if features present in previous incarnations still work.

Of course. I mean that I hope that they are forced, some time, to replace telnet with ssh on the new machines they build. The existing machines can not change, of course. Now that I remember... it was my previous router, it had an ssh server, but at some point Linux was unable to connect to it. Something changed in the openSUSE client, and connection broke. I had to go back to telnet. They were probably using a very obsolete ssh server implementation. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)