OpenBSD Journal

[Current] r* Programs Going Away

Contributed by Dengue on from the lived-life-with-joy dept.

Anonymous Cowherd writes :
"It seems that rlogind and rexecd have been removed from -current . Can other legacy, security-free protocols be far behind? The original announcement from source-changes@ can be found here , along with Theo's explanation ."
Hopefully other operating systems and software vendors will take note and cease having installation or runtime dependencies on r* programs.

(Comments are closed)

Comments

  1. By Anonymous Coward () on

    The only way to herd cats is to block the exits. Take telnet while you are at it. I have lots of switches at work that I can connect to with only telnet, http, or snmp, not ssh. If necessary, I'll run one older version of OpenBSD on a box that I can ssh to, then telnet to whatever needs my attention. FTP should go to, but the only way I can see it happening is for a daemon that does both ftp and sftp, become widely used across the Internet. Then you could migrate, and at some point kill FTP.

    Unfortunately, FTP is needed for OpenBSD installs, so it will be a while coming, unless scp or sftp becomes an option. How easy that would be would require a real programmer.

    Take everything that passes passwords in the clear.

    Show the way Theo, and the crowds will follow.

    Comments

    1. By Todd Fries () todd@openbsd.org on mailto:todd@openbsd.org

      I've built a floppy with ssh/sshd on it and let me say it doesn't have much room for drivers and/or programs linking in libcrypto/libssl/etc. This is without kerberos as well! Unfortunately, there is a lack of a space efficient secure install method. I would be happy to be corrected, of course.

    2. By Christian Gruber () cgruber@israfil.net on mailto:cgruber@israfil.net

      Try HTTP installs, if FTP goes. ;)

      But I don't think killing FTP is necessary, just never EVER enable clear-text passwords, and use it for public things.

    3. By RC () on

      FTP/SFTP combo isn't needed. What is needed is a simple configuration option for the sshd server that will make some folder available to users, without giving them a shell on the box, or allowing them to do port forwarding.

      THAT is what is needed to make SSH replace FTP and Telnet.

    4. By Anonymous Cat () on

      Why not download a ssh client with whatever else is needed, during th einstall? You only need the floppy to boot the host, then you can get aa much as you need to complete the install, even if you have to run part of it.

      Comments

      1. By vincent () vincen at igc ethz ch on mailto:vincen at igc ethz ch

        personally, i download the whole floppy during the boot process.
        via sftp, by the way.

        cheers to logic,
        v.

    5. By pravus () on

      i have to admit, this seems almost ludicrous. yes, as we all know, the security minded user would stray away from the commands. however, i've found that in many IT shops, security is of the lowest concern. maybe it shouldn't be that way, but the reality is that many companies only spend time securing their exterior and little time on their interior.

      perhaps the OpenBSD team might think of leaving the tools on the system but just put them in another directory with non-executable permissions? that way you have to manually enable them to use them. or, perhaps leave the tools in the source tree, but don't compile them by default?

      i don't know what would be best, but i don't think leaving them out is it.

    6. By Gunnar Wolf () gwolf@gwolf.cx on http://www.gwolf.cx

      The r*-commands can be ditched - Please, go ahead and do so, as they are completely useless with their secure counterparts available and free! However, I would never remove telnet. Why? Because it is a very useful debugging tool. Although I haven't used telnet to port 23 in ages, I often (daily at least) use it to check services on different ports. Any TCP-based protocol can be debugged with telnet.

      Comments

      1. By Anonymous Coward () on

        I totally agree with you. It's good to remove the r*-commands and telnetd, but it would be nice to leave the telnet client in.
        Or at least make it possible to add it using a package/port, so that people who want it can have it.
        Or you could also make telnet display a huge security warning whenever you start it ;-)

      2. By Adam Lazur () laz@clustermonkey.org on mailto:laz@clustermonkey.org

        Surely telnet should be ditched.

        If you need to debug network protocols, I suggest you check out nc(1). It has a superset of telnet's features in the sense that you'd want to use it.

        The only advantage telnet has over nc is the interactive command prompt stuff. But you wouldn't need that if you're just using it for network debugging ;)

        Comments

        1. By Anonymous Coward () on

          I *certainly* don't see the advantage of getting rid of the FTP and TELNET *client* software. As long as I am not running them on *my* servers, why would you prevent me from getting to an FTP site out there on the web to download something from someplace that perhaps isn't so "enlightened"?

          Sure, SSH is pretty standard these days, but there are still people out there running FTP servers, and I would like to be able to get to them still.

      3. By Dalin Owen () dowen@pstis.com on mailto:dowen@pstis.com

        Use Netcat for that. Actually Netcat *should* be built into the OS. I use it in place of telnet for debugging (connecting to raw sockets by hand).

    7. By Anonymous Coward () on

      See a similar announcement by FreeBSD as d/o Slashdot/bsd

  2. By Anonymous Coward () on

    Continuus (version control system by telelogic
    needs r-tools). So bye-bye OpenBSD from some (very) big telco where I work - we use RedHat.

    Comments

    1. By Anonymous Coward () on

      Who gives a flying fuck?!? (very) big telcos suck anyway, and you suck for working for one.

    2. By Anonymous Coward () on

      This is rediculous...

      Instead of getting rid of r- utilities and software that uses them, they say "Bye bye OpenBSD and security". I don't care if your vendor/policy/agreement/hardware does not allow/support/whatever normal security practices - it's about time to do something about it!

      If you can not do anything in your situation - quit your job and find a better place to work for. That's what I would do.

      Comments

      1. By Anonymous Coward () on

        I love that logic. Ok, so presuming I'm 50 years old (I'm not, but I love a good argument) and have worked for a Telco for 20 years, have like 5 weeks of vacation, and the economy and job market sucks right now...

        oh yeah, they won't use OpenBSD because the software package they've used for years won't run on it... so screw the 5 weeks vacation, the job security (ok.. for what it is in this market), and just quit and have no income for the next few months while you look for a new job...

        hoping you find one.. because, of course, the job market is starting to rebound, but not a lot yet. Oh, and that mortgage?? Ahh, well, so it takes a little longer and they foreclose on your house.. a tent works just fine for the wife and 3 kids, right?

        Besides which, I would presume your machines are behind a firewalll and/or in a DMZ.

        But, then again, I don't rush to spend lots of money and replace things that are working fine behind our firewall just because someone else tells me I should.

        And, then again... I don't work at McDonalds, either.

        Comments

        1. By Anonymous Cowherd () on


          >Besides which, I would presume your machines are >behind a firewalll and/or in a DMZ.

          >But, then again, I don't rush to spend lots of >money and replace things that are working fine >behind our firewall just because someone else >tells me I should.

          "It's behind a firewall" is a lame excuse for not patching security problems. If an outsider can penetrate a machine, so can an insider. And from all the data I've seen, inside jobs are far more common.

          And by the way, not to sound harsh, but I don't see "compatibility with commercial applications" anywhere on the OpenBSD project goals page. If all security concerns were sacrificed to backward compatability, we'd end up with something like, well, Windows.

          The "quit your job" thing is obviously a troll, however. Someone tell me when they find a corporation that *doesn't* institutionalize stupidity, and I'll be first in line at HR.

        2. By Anonymous Coward () on

          It's not 5, it's 6 week vacation :-) And i've been searching for that job 4 months, living first on my money and then on my dad's money. So sure, I'll screw this job and go looking for another 60000 people telco, which would be using OpenBSD and ssh ;-)

          /Alex

          PS: And the guy who told there is no Continuus for Linux: check the facts, idiot.

    3. By Anonymous Coward () on

      Good for you sucky telco. If they're too stupid too use real tools, screw them. They deserve to burn in hell for all eternity.

    4. By Anonymous Coward () on

      Not to be too much of a troll, but I think I have to call BS on this one.

      We use Telelogic CM Synergy (the new name of Continuus) and I haven't seen it run on anything but HP-UX, Solaris, and Windows. There doesn't exist a Linux port, at all (excepting the next version, which is supposed to be Java-based, and hence more platform-agnostic.)

      Comments

      1. By Simon Chappell () simon.chappell@landsend.com on mailto:simon.chappell@landsend.com

        I'm using Telelogic CM Synergy 6.2 client (the latest) on my RedHat Linux laptop and it works just fine. During the evaluation of the product, we ran it (the server version) on Linux for a couple of months (they decided to put it on AIX for the production useage).

        Talking to their principle engineers, Linux is a first tier platform for them. In fact they release the Linux version before the AIX version! :-)

        I'll have to ask them about an OpenBSD version. That'd be neat.

        Simon

    5. By Emiliano () emile@iris-advies.nl on mailto:emile@iris-advies.nl

      Well then, good news, eh? _Anything_ that means you can't use Continuus is good news.

      Comments

      1. By Anonymous Coward () on

        No, it means OpenBSD won't be used.

    6. By Anonymous Coward () on

      I want to know what company you work for, so I can never spend money with them again. Thats the lamest thing I've heard in a loooong time.

  3. By Anonomous Coward () on

    I take care of approximately 100 OBSD boxes and
    when I upgrade I feed them all a boot floopy and
    use RSH to pull down an image. This could be done
    with SSH but as Tood Fries has stated with SSH
    on a floppy there is not much room for anything
    else. I could burn a bunch of CDs but floppies
    are rewritable and faster to produce. Until SSH fits on a floppy with a kernel and other utils (ifconfig, restore, etc), keep rsh.

    Comments

    1. By Anonymous Coward () on

      I take care of about 25 OBSD boxes and almost never use floppies. I ftp the bsd.rd file to / and then reboot, typing in boot hd0a:/bsd.rd at the boot> prompt. Then I get the nearly equivalent of the CD upgrade, (still have to ftp the *.tgz files, but hey we have a fast connection here) even if the PC does not have a CD drive or a supported one.

      Of course, once you start the upgrade or install, if you have problems, it's back to a floppy or CD, if the disk gets messed up.

      Oh and I'm looking at about 25 CDs of OpenBSD, which I purchase to support the project, and almost never use for installs.

      I'm nearly always running snapshots, because they WORK and work better than the Energizer bunny. In fact I have a 2.8 system that has been up for 400+ days, that I'll soon upgrade the same way.

    2. By Anonymous Coward () on

      You SUCKING IDIOT! If you're such a damn dump troll, that is not able to modify the openbsd build process to that r-tools are included, go away fuck your self and use SuSE or Mandrake or some other sucking ape-compatible Linux-distribution.

      Bye. You stink.

      Comments

      1. By Anonymous Coward () on

        Scotty, beam us up, there is no evidence of intelligent life in this quadrant.

  4. By Anonomous Coward () on

    I take care of approximately 100 OBSD boxes and
    when I upgrade I feed them all a boot floopy and
    use RSH to pull down an image. This could be done
    with SSH but as Tood Fries has stated with SSH
    on a floppy there is not much room for anything
    else. I could burn a bunch of CDs but floppies
    are rewritable and faster to produce. Until SSH fits on a floppy with a kernel and other utils (ifconfig, restore, etc), keep rsh.

  5. By Ken Crandall () ken.crandall@mindspring.com on http://www.mindspring.com/~ken.crandall

    It seems to me that the most politically correct thing to do would be to move the r* tools into ports.

    I think what Theo and co. want to do is remove something from their plates that is inherantly insecure and they've been having to patch since day 1.

    If it's moved into ports, those who need it can use it and maintain it themselves.

  6. By Grey - Digital Target () on

    Did all you complainers actually read this?

    http://www.sigmasoft.com/~openbsd/archive/openbsd-tech/200205/msg00067.html

    "Log message:
    rlogind and rexecd go away"

    The -daemons- are being removed, not the clients.

    Maybe I'm mistaken, but I'm assuming that none of you gripers actually edit your OpenBSD installations to permit rlogind, et al to run as services on your OpenBSD machines.

    The clients are still there to connect to decrepit old machines from OpenBSD. Hopefully none of you work in an environment where you need to connect -to- you OpenBSD machines via these protocols. Connecting -from- OpenBSD shouldn't be a problem.

    If I'm wrong, and you're actually concerned about the dissappearance of a couple of cleartext daemons let me know.

    Comments

    1. By Grey - Digital Target () on

      Ignore the above... I should've read a bit further in the thread:

      "No, the clients are gone too I'm afraid.

      - todd"

  7. By mra () on

    Not that many people here use it, but another approach which has a similar effect is being done on Tru64. On that OS the r*'s can be configured to be captured in libc and forced to use an SSH tunnel to do their connection. The end result is that connections still use the same clients (which mean you don't have to change any scripts) but the session is using SSH hostbased authentication for security, all without even having to tell your users.

    Now that HP bought Compaq this functionality will probably show up in HP-UX, and since that OS is OpenSSH based it therefore will be easily ported to other platforms.

  8. By Anon-telco admin () verizon on mailto:verizon

    Almost all telco hardware, either CDMA/3g/etc uses telnet? Its funny seeing bsd mach kernel based hardware only using telnet. And to make it bad enough, we have to put telnet proxies in to reach the hardware. Seems the same for anything not running a true os. We try to put a box as close to the hardware then ssh into it, and telnet out. But damn, no big vendors are supporting SSH.

    Comments

    1. By grey () on

      Hmmm, albeit my telco experience was mostly with regards to cellular & SS7 equipment - but only our DSC (now Alcatel) HLR's were running any form of unix (a somewhat quirky version of solaris that was compatible with Sun's discontinued FT-Sparcs). With those you could telnet, run X sessions remotely, presumably even install ssh.

      The rest of the gear - Tekelec STP's, Summa4 [now cisco] switches (for trunk handling, not the layer2 things), Inet Protocol analysers (this one ran DOS - woohoo), etc. all needed to be accessed via console - they had no IP stacks that I ever encountered and thus no remote IP-based management tools.

      So at least from that perspective - there's quite a lot of telco hardware that doesn't use telnet - or anything else TCP/IP related. ;)

      The pieces that do, are of quite a bit of concern however - as are notions of tunnelling SS7 traffic over TCP/IP [they are doing this sort of thing already in some areas]. That could be a future bad scenario.

    2. By Anonymous Coward () on

      Assuming you are reffering to embeded network hardware, there is at lease one company I know doing ssh. One of the major factors in some major purchases we've made was that ExtremeNetworks support ssh2 protocol to get to the command prompt. I've used ssh on their boxes for a couple years; it works well.

  9. By Anonymous Coward () on

    Did anyone READ the changelog info? It's just the SERVER bits that are going away. The clients are staying.

    Comments

    1. By Anonymous Coward () on

      No, no!
      It's been said several times - clients go as well. Well, rsh stays for a while, but rlogin is gone.

  10. By RC () on

    People don't seem to remember IPSec. While it may not be widely used at the moment, it can be used on just about every platform out there, and WILL be used once IPv6 is adopted.

    What does that mean on this topic?
    Telnet over IPSec will be more secure than SSH over TCP/IP. So, why get rid of the utilities that communicate in clear-text? Over IPSec, those same utilities are secure as well.

    Seems like an unreasonable move at this point.

    Comments

    1. By Bogomips () bogomips@nirvanet.net on mailto:bogomips@nirvanet.net

      You make me laughing. yes, everything buggy is secured once encrypted... You're right.

      Bogomips

  11. By x () krisna@core.group.bsd.freak.com on y

    Remove uucp Remove rlogind, Remove rexecd remove sendmail, remove fingerd and remove .. remove remove. Where is The Great OpenBSD Code Auditing Team?.

    Comments

    1. By Anonymous Hero () on

      It is easyer to remove than fix the problemt. This must be the reason.

      BUT how usefull is an OS without any utilities?
      I would rather that the problems were fixed instead of just removing the utilities.

      OK, clean text password over the net is NOT OK.
      But over IPSec they are secure as well.

      Sure remove the servers, but NOT the clients.
      If telnet goes how am I suposed to telnet into my cisco router and configure it - NO SSH support.

      It is not a big deal to make a secure OS. Just remove everything except what is needed to boot the machine. But how usefull is that?

      What the heck the security record is the most important. Even if every user first installes some utilities that they need and it turns out that there are a security Vulnerability. It IS NOT IN THE DEAFULT INSTALL so we are happy and OpenBSD is still the most secure OS.

      Security matters but usefullnes does not. We simply don't care we only care about security.

      >Where is The Great OpenBSD Code Auditing Team?.
      They turned in to The Great OpenBSD Remove Team.

      Yea, security on the behalf of usefullness!
      Way to go, NOT!

      Comments

      1. By Anonymous Coward () on

        Deafult install, no network and hence no remote security Vulnerability.

        Is that going to happen in the next OpenBSD release?

        Comments

        1. By Anonymous Coward () on

          You again?? Please get a hold of the cds and instaall
          the OS. You will find.
          network running
          portmap running
          sshd running
          inetd running
          ---
          Yes it is.

  12. By Anonymous Coward () on

    Good, now we can have a pure OS that is secure without the clutter.

    Comments

    1. By Anonymous Coward () on

      Yeah right. I'm still waiting to see a release of either OpenSSH or OpenBSD that isn't followed quickly thereafter with a security patch.

Latest Articles

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]