Professional Web Applications Themes

SSH - Sun Solaris

In <3f826566$0$3668$sunrise.ch> "UNIX admin" <com> writes:    [/ref]   the commercial version is very slow in login when You have many users (1000) and use nis+. They request line per line form the NIS+ - Server's groupfile. Change requested I think in 2001, nothing done....

  1. #41

    Default Re: SSH

    In <3f826566$0$3668$sunrise.ch> "UNIX admin" <com> writes:
     
     [/ref]
     

    the commercial version is very slow in login when You have
    many users (1000) and use nis+. They request line per line
    form the NIS+ - Server's groupfile. Change requested I think
    in 2001, nothing done.

    Horst Guest

  2. #42

    Default Re: SSH

    On Tue, 07 Oct 2003 09:14:19 +0200, UNIX admin wrote:
     

    OpenSSH plays quite well with SSH clients IME, although a key translation
    is required. SSH servers do not play well at all with OpenSSH clients.
     

    I did not observe any "hanging" on exit from the ssh session nor has the
    one remote client using SSH.

    Dave Guest

  3. #43

    Default Re: SSH

    "Dave Uhring" <com> schrieb im Newsbeitrag
    news:com... 

    I wish I had been that lucky, that's all I have to say about that.
     

    I did. Tested platforms were IRIX 6.5.14m, 6.5.17f, Solaris7, 8 and 9 on
    SPARC, HP-UX 10.20, 11.00 and 11i.


    UNIX Guest

  4. #44

    Default Re: SSH

    Dave Uhring sez: 
    .... 
    >
    > I did not observe any "hanging" on exit from the ssh session nor has the
    > one remote client using SSH.[/ref]

    Consider yourself lucky. About any client will hang on exit with IRIX
    OpenSSH 2.9 server. It happens less frequently with newer versions of
    OpenSSH & other OSen. It happens more frequently with tunnelled stuff
    (e.g. CVS server over ssh) than with plain remote logins.

    We had a seriously ed up system at one time because hanging ssh
    connections filled up cron run queue... (and then there's IRIX where
    cron run queue size >= process table size. Ouchie.)

    The best part is that they're left hanging on purpose & it'll never
    be fixed. And OpenSSH folks won't even put a timeout in there.

    Dima
    --
    We're sysadmins. Sanity happens to other people. -- Chris King
    Dimitri Guest

  5. #45

    Default Re: SSH

    "UNIX admin" <com> writes:
     
    [...]

    You mean like a remote access point so you don't have to drive to the
    office in the middle of the night to do maintenance? Or how about a
    bastion host so students can work from home in a university/college
    setting? How about a CVS repository that uses SSH tunneling so that
    access to propriatary information is kept confidential, but still
    accessible when people are away from the office?

    Three situations in which I've dealt with personally.

    There are perfectly valid reasons for having remote access. Of course
    there are risks with said remote access.

    --
    David Magda <dmagda at ee.ryerson.ca>, http://www.magda.ca/
    Because the innovator has for enemies all those who have done well under
    the old conditions, and lukewarm defenders in those who may do well
    under the new. -- Niccolo Machiavelli, _The Prince_, Chapter VI
    David Guest

  6. #46

    Default Re: SSH

    "UNIX admin" <com> writes:
     

    Closed source has really helped Microsoft, and Cisco IOS, and Lotus,
    and Oracle, and Alcatel... (Just going through the CERT advisories.)
     
    [...]

    Just because a bug is not known does not mean it's not there. I can
    see your reasoning, but personally I would rather have a bug found
    and fixed then lying in wait. SSH.com has a much smaller 'market
    share' than OpenSSH so it would be a less likely a target.

    To each his own.

    --
    David Magda <dmagda at ee.ryerson.ca>, http://www.magda.ca/
    Because the innovator has for enemies all those who have done well under
    the old conditions, and lukewarm defenders in those who may do well
    under the new. -- Niccolo Machiavelli, _The Prince_, Chapter VI
    David Guest

  7. #47

    Default Re: SSH

    On Tue, 07 Oct 2003 06:44:57 -0500, com wrote: 

    it depends on your shell, I think.
    try changing it to ksh, then do


    $ sleep 1000&
    $ exit




    --
    http://www.blastwave.org/ for solaris pre-packaged binaries with pkg-get
    Organized by the author of pkg-get
    [Trim the no-bots from my address to reply to me by email!]
    S.1618 http://thomas.loc.gov/cgi-bin/bdquery/z?d105:SN01618:D
    http://www.spamlaws.com/state/ca1.html
    Philip Guest

  8. #48

    Default Re: SSH

    On Tue, 07 Oct 2003 22:45:31 +0000, Philip Brown wrote:
     
    >
    > it depends on your shell, I think.
    > try changing it to ksh, then do
    >
    >
    > $ sleep 1000&
    > $ exit[/ref]

    My remote client, and I mean really remote, does use ksh on Solaris 2.5.1
    and SSH2. He has reported no problems on exit.

    I'm using openssh on Solaris 8 x86 on the server with an OpenBSD PF
    firewall with ssh holes for only that client's IP address. His shell on
    the server is /usr/bin/ksh.

    Dave Guest

  9. #49

    Default Re: SSH

    On Tue, 07 Oct 2003, Dimitri Maziuk <0.0.1> wrote: 

    I've found the '-n' option to be very handy when scripting ssh.
    I had a situation similar to yours, where an openssh upgrade
    broke a bunch of cron scripts.

    --

    Leach
    Leach Guest

  10. #50

    Default Re: SSH

    On Wed, 08 Oct 2003 02:37:47 GMT, invalid wrote: 

    drat. I was very hopefull.
    Unfortunately, I see the same 10 second wait, whether I use

    ssh remote-keyed-host 'sleep 10 &'
    or
    ssh -n remote-keyed-host 'sleep 10 &'

    Hmm. but oddly, if I force tty allocation,

    ssh -t remote-keyed-host 'sleep 10 &'


    THAT seems to avoid the delay waiting for the sub-process to end.
    very counter-intuitive

    --
    http://www.blastwave.org/ for solaris pre-packaged binaries with pkg-get
    Organized by the author of pkg-get
    [Trim the no-bots from my address to reply to me by email!]
    S.1618 http://thomas.loc.gov/cgi-bin/bdquery/z?d105:SN01618:D
    http://www.spamlaws.com/state/ca1.html
    Philip Guest

  11. #51

    Default Re: SSH

    Philip Brown wrote:
     

    This has been discussed on the OpenSSH dev mailing list. OpenSSH refuses
    to cut the connection if a tty is still open (and potentially still in
    use). The philosophy the OpenSSH dev team is following is that
    absolutely no output should go missing. So, it depends really on the
    applications that are started via ssh. If they behave correctly, ssh
    will not hang.

    /l

    Just Guest

  12. #52

    Default Re: SSH

    On Wed, 08 Oct 2003 11:23:40 -0400, invalid wrote: 

    "correctly" is in the eye of the beholder.
    And this eye says that ssh is not behaving correctly.

    There is an option for just about everything else in openssh... I'm
    surprised there isnt some kind of option tweak for this as well.



    --
    http://www.blastwave.org/ for solaris pre-packaged binaries with pkg-get
    Organized by the author of pkg-get
    [Trim the no-bots from my address to reply to me by email!]
    S.1618 http://thomas.loc.gov/cgi-bin/bdquery/z?d105:SN01618:D
    http://www.spamlaws.com/state/ca1.html
    Philip Guest

  13. #53

    Default Re: SSH

    Philip Brown sez: 
    >
    > "correctly" is in the eye of the beholder.
    > And this eye says that ssh is not behaving correctly.[/ref]

    My understanding is that it does i/o over line-buffered pty
    and there's no guarantee that os will flush that last line
    when application exits (or ever, as practice shows). Where
    that really bites is scp: if you throw away that last line,
    you end up with corrupt file.

    Apparently OpenSSH folks prefer to err on the side of caution,
    and their idea of erring on the side of caution is to always
    wait for that last line. Forever.

    Dima
    --
    "Mirrors and copulation are abominable because they increase the number of
    entities." -- corollary to Occam's Razor
    Dimitri Guest

  14. #54

    Default Re: SSH

    [UNIX admin]: 

    how do you think those freeware guys would react if you said: "there's
    a problem with your software. I'll pay you $150,000 to fix it." my
    guess is: "yes, Mr. UNIX admin, Sir!" even $10,000 would in most
    cases be enough to get that response.

    --
    Kjetil T. | read and make up your own mind
    | http://www.cactus48.com/truth.html
    Kjetil Guest

  15. #55

    Default Re: SSH

    Kjetil Torgrim Homme wrote: 

    Y'know, I wonder if one could make a living this way. If you could
    get the marketing right and get a steady stream of clients, you could
    fix two or three relatively small bugs per month for $2000 each.
    There's no reason to restrict yourself to one freeware app, either.
    You could be available to fix a bug in almost anything open source.
    Naturally, part of the agreement would be to return the bugfix to
    the community, since this benefits everyone. (Even the customer,
    since it means they will have the bugfix in the next release.)

    - Logan

    Logan Guest

  16. #56

    Default Re: SSH

    [Philip Brown]: 

    I use detach(1) for this, a classic program originally written by Don
    Bennett, Howard Chu and Wes Craig. hmm, can't find it on the net
    anymore, so I put it up at

    http://folk.uio.no/kjetilho/hacks/detach.shar

    in this simple case

    ssh host "(command &) >/dev/null 2>&1"

    will also work.
    --
    Kjetil T. | read and make up your own mind
    | http://www.cactus48.com/truth.html
    Kjetil Guest

  17. #57

    Default Re: SSH

    [Philip Brown]: 
    >
    > "correctly" is in the eye of the beholder. And this eye says that
    > ssh is not behaving correctly.
    >
    > There is an option for just about everything else in openssh...
    > I'm surprised there isnt some kind of option tweak for this as
    > well.[/ref]

    type ~. to close the connection regardless. (add the appropriate
    number of tildes if you use ssh within ssh.)

    --
    Kjetil T. | read and make up your own mind
    | http://www.cactus48.com/truth.html
    Kjetil Guest

  18. #58

    Default Re: SSH

    "Rob" <com> writes:
     

    Just edit /etc/inet/inetd.conf and comment out the telnet line, then send
    the running 'inetd' process a SIGHUP using:

    kill -SIGHUP `pgrep inetd`

    After that attempts to connect via telnet will be rejected.

    Sun's SSH release is automatically available for use once it's installed and
    the machine has been rebooted.

    Craig.

    --
    SUN RIPENED KERNELS - Surplus Sun Microsystems Equipment, Parts + Accessories
    Waterfall, NSW, Australia - Operated by Craig Dewick - Founded in 1996
    Main site: www.sunrk.com.au - Ebay Shop: www.ebayshops.com.au/sunripenedkernels
    Ph: +612-9520-2547 - Fax: +612-9520-2557 - Mobile: 04-2163-0547 (int. +614)
    Kralizec Guest

  19. #59

    Default Re: SSH

    On Fri, 10 Oct 2003 21:08:31 +0200, ifi.uio.no wrote: 

    That doesnt help if the problem is with a script, that sometimes closes,
    and sometimes does not.
    and its extra difficult if it's not you writing the script, but
    "application developers", and then you have to attempt to explain
    workarounds to them.
    arg


    --
    http://www.blastwave.org/ for solaris pre-packaged binaries with pkg-get
    Organized by the author of pkg-get
    [Trim the no-bots from my address to reply to me by email!]
    S.1618 http://thomas.loc.gov/cgi-bin/bdquery/z?d105:SN01618:D
    http://www.spamlaws.com/state/ca1.html
    Philip Guest

Page 3 of 3 FirstFirst 123

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139