port forwarding timeouts - SSH

This is a discussion on port forwarding timeouts - SSH ; Hi all, I'm trying this command: ssh -v -L 8000:10.101.41.127:8000 root@200.222.29.35 My localhost - 10.101.41.127 shows 8000 as open: /root> nmap -p8000 localhost Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2006-01-17 18:12 BRST Interesting ports on localhost (127.0.0.1): PORT STATE ...

+ Reply to Thread
Results 1 to 11 of 11

Thread: port forwarding timeouts

  1. port forwarding timeouts

    Hi all,

    I'm trying this command:

    ssh -v -L 8000:10.101.41.127:8000 root@200.222.29.35

    My localhost - 10.101.41.127 shows 8000 as open:

    /root> nmap -p8000 localhost

    Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2006-01-17
    18:12 BRST
    Interesting ports on localhost (127.0.0.1):
    PORT STATE SERVICE
    8000/tcp open http-alt

    The remote machine - 10.222.29.35 - also shows 8000 open:

    After a couple of minutes trying to connect to localhost:8000 , I get
    these messages:

    debug1: Connection to port 8000 forwarding to 10.101.41.127 port 8000
    requested.
    debug1: channel 3: new [direct-tcpip]
    channel 7: open failed: connect failed: Connection timed out
    debug1: channel 7: free: direct-tcpip: listening port 8000 for
    10.101.41.127 port 8000, connect from 127.0.0.1 port 1773, nchannels 5
    debug1: Connection to port 8000 forwarding to 10.101.41.127 port 8000
    requested.
    debug1: channel 4: new [direct-tcpip]

    channel 3: open failed: connect failed: Connection timed out
    debug1: channel 3: free: direct-tcpip: listening port 8000 for
    10.101.41.127 port 8000, connect from 127.0.0.1 port 1774, nchannels 5
    channel 4: open failed: connect failed: Connection timed out
    debug1: channel 4: free: direct-tcpip: listening port 8000 for
    10.101.41.127 port 8000, connect from 127.0.0.1 port 1775, nchannels 4

    I can, however, run telnet (just a test of course) :

    /root> telnet localhost 8000
    Trying 127.0.0.1...
    Connected to localhost.
    Escape character is '^]'.

    Any ideas?
    iksrazal


  2. Re: port forwarding timeouts


    > Hi all,
    > I'm trying this command:
    >
    > ssh -v -L 8000:10.101.41.127:8000 root@200.222.29.35
    >
    > My localhost - 10.101.41.127 shows 8000 as open:


    The address between the colons should be the server host, not the client.
    The forwarded connection is trying to connect back to the client host,
    whose port 8000 is presumably firewalled off or otherwise unreachable.

    --
    Richard Silverman
    res@qoxp.net


  3. Re: port forwarding timeouts

    Richard E. Silverman wrote:
    >>Hi all,
    >>I'm trying this command:
    >>
    >>ssh -v -L 8000:10.101.41.127:8000 root@200.222.29.35


    ??? root@x.y.z.zz ??
    this can be configure to deny access and personally would never
    allow this connection.

    be advised!


    --
    ---
    Jeff B (remove the No-Spam to reply)

  4. Re: port forwarding timeouts

    >>>>> "JB" == Jeff B writes:

    JB> Richard E. Silverman wrote:
    >>> Hi all, I'm trying this command:
    >>>
    >>> ssh -v -L 8000:10.101.41.127:8000 root@200.222.29.35


    JB> ??? root@x.y.z.zz ?? this can be configure to deny access and
    JB> personally would never allow this connection.

    JB> be advised!

    Why?

    --
    Richard Silverman
    res@qoxp.net


  5. Re: port forwarding timeouts

    Richard E. Silverman wrote:
    >>>>>>"JB" == Jeff B writes:

    >
    >
    > JB> Richard E. Silverman wrote:
    > >>> Hi all, I'm trying this command:
    > >>>
    > >>> ssh -v -L 8000:10.101.41.127:8000 root@200.222.29.35

    >
    > JB> ??? root@x.y.z.zz ?? this can be configure to deny access and
    > JB> personally would never allow this connection.
    >
    > JB> be advised!
    >
    > Why?
    >


    fundament concept: *never* allow root access remotely.
    If it's truely necessary, login as joe_user and then
    use SU or SUDO

    --
    ---
    Jeff B (remove the No-Spam to reply)

  6. Re: port forwarding timeouts

    >>>>> "JB" == Jeff B writes:

    JB> fundament concept: *never* allow root access remotely.

    As it happens, I'm fairly conversant with fundamental concepts of Unix
    systems administration, as well as SSH -- which is related to the number
    of times in the past few months that I've corrected your repeated errors
    in advice to people on SSH. Which I also note that you mostly ignore.

    Thanks for your concern, though.

    JB> If it's truely necessary, login as joe_user and then use SU or SUDO

    Automated jobs frequently require remote root access, and can't type in a
    password to su or sudo. You can make specific NOPASSWD sudo entries for
    those jobs, but a lot of people are uncomfortable with that. Also, it's
    not clear that that provides any more security than restricting the job
    with a publickey forced command -- though of course, if there's an
    existing discipline in place of using sudo for such things, consistency
    may be reason enough.

    --
    Richard Silverman
    res@qoxp.net


  7. Re: port forwarding timeouts

    Richard E. Silverman sez:
    >>>>>> "JB" == Jeff B writes:

    >
    > JB> fundament concept: *never* allow root access remotely.
    >
    > As it happens, I'm fairly conversant with fundamental concepts of Unix
    > systems administration, as well as SSH -- which is related to the number
    > of times in the past few months that I've corrected your repeated errors
    > in advice to people on SSH. Which I also note that you mostly ignore.
    >
    > Thanks for your concern, though.
    >
    > JB> If it's truely necessary, login as joe_user and then use SU or SUDO
    >
    > Automated jobs frequently require remote root access, and can't type in a
    > password to su or sudo. You can make specific NOPASSWD sudo entries for
    > those jobs, but a lot of people are uncomfortable with that.


    Also, there are some handy GUI apps out there and X forwarding
    with su is a major pain.

    Dima
    --
    Relativity, Uncertainty, Incompleteness, Undecidability: choose any four

  8. Re: port forwarding timeouts

    Richard E. Silverman wrote:
    >>>>>>"JB" == Jeff B writes:

    >
    >
    > JB> fundament concept: *never* allow root access remotely.
    >
    > As it happens, I'm fairly conversant with fundamental concepts of Unix
    > systems administration, as well as SSH
    >
    > JB> If it's truely necessary, login as joe_user and then use SU or SUDO
    >
    > Automated jobs frequently require remote root access,


    hum; automated remote access. Another (imo) conceptual error.

    I'm not going to engage in a p***ing contest with you. There are a
    great too many predisposed to that game already.

    We all make choices and have opinions. consequences may (highly) vary.


    --
    ---
    Jeff B (remove the No-Spam to reply)

  9. Re: port forwarding timeouts

    >>>>> "JB" == Jeff B writes:

    JB> Richard E. Silverman wrote:
    >>>>>>> "JB" == Jeff B writes:

    JB> fundament concept: *never* allow root access remotely. As it
    >> happens, I'm fairly conversant with fundamental concepts of Unix
    >> systems administration, as well as SSH JB> If it's truely
    >> necessary, login as joe_user and then use SU or SUDO Automated jobs
    >> frequently require remote root access,


    JB> hum; automated remote access. Another (imo) conceptual error.

    So, no cron job should ever communicate with another host? I don't
    understand: how do you manage a large number of machines? Do you
    personally sit 24 hours per day at a terminal running all jobs by hand
    under your personal credentials (ssh-agent, Kerberos, hostbased,
    whatever)? How about backups; do we need to attach a tape drive to every
    computer on Earth? Please explain.

    Btw, another good reason for remote root access has nothing to do with
    automation, if that disturbs you generally. Say you need to restart a
    daemon on 100 machines, and it requires root access to do so. You type
    something like:

    $ for host in `netgroup foo-hosts` do; ssh root@$host /etc/init.d/foo restart; done

    If I understand you, you would prefer:

    ssh $host sudo /etc/init.d/foo restart

    .... meaning you will have to type your password 100 times. That is not
    workable. Nor can you reasonably anticipate every possible remote command
    sequence you might need to execute as some other uid and create specific,
    locked-down, NOPASSWD sudo rules for them. How would you deal with this
    frequent need in the life of a sysadmin?

    Note that Kerberos can solve this problem nicely, by providing securely
    forwarded, session-limited credentials you can use to authorize changing
    uid on the remote host. However, I haven't seen you suggest this or a
    similar mechanism yet.

    JB> I'm not going to engage in a p***ing contest with you. There are
    JB> a great too many predisposed to that game already.

    There is no contest. In any event, I am merely pointing out that you
    repeatedly make factually inaccurate statements regarding SSH, in an SSH
    newsgroup, and do not acknowledge when you've been corrected -- indeed,
    you sometimes continue to make the same mistakes in subsequent posts.
    Which suggests you might do well to spend more time learning from others'
    posts and less time writing misleading ones.

    --
    Richard Silverman
    res@qoxp.net


  10. Re: port forwarding timeouts

    Richard E. Silverman wrote:
    >>>>>>"JB" == Jeff B writes:

    >
    >
    > JB> Richard E. Silverman wrote:
    > >>>>>>> "JB" == Jeff B writes:

    > JB> fundament concept: *never* allow root access remotely. As it
    > >> happens, I'm fairly conversant with fundamental concepts of Unix
    > >> systems administration, as well as SSH JB> If it's truely
    > >> necessary, login as joe_user and then use SU or SUDO Automated jobs
    > >> frequently require remote root access,

    >
    > JB> hum; automated remote access. Another (imo) conceptual error.
    >
    > So, no cron job should ever ...


    let's be clear.
    1) this is totally off topic
    2) admin within the domain is very different from remote admin, eg from
    the Internet through the Corp firewall. Remote access is well served
    via VPN or its SSH sister. These tools are not (or should not be
    necessary unless you have an Class A Security environment (see the
    Yellow Book).

    as for the rest of the trivel ... the blackboard is all yours ... have
    fun :-)

    --
    ---
    Jeff B (remove the No-Spam to reply)

  11. Re: port forwarding timeouts


    "Jeff B" wrote in message
    news:9uqdnTOz1sx-33XeRVn-jw@adelphia.com...
    > Richard E. Silverman wrote:
    >>>>>>>"JB" == Jeff B writes:

    >>
    >>
    >> JB> Richard E. Silverman wrote:
    >> >>>>>>> "JB" == Jeff B writes:

    >> JB> fundament concept: *never* allow root access remotely. As it
    >> >> happens, I'm fairly conversant with fundamental concepts of Unix
    >> >> systems administration, as well as SSH JB> If it's truely
    >> >> necessary, login as joe_user and then use SU or SUDO Automated

    >> jobs
    >> >> frequently require remote root access,

    >>
    >> JB> hum; automated remote access. Another (imo) conceptual error.
    >>
    >> So, no cron job should ever ...

    >
    > let's be clear.
    > 1) this is totally off topic
    > 2) admin within the domain is very different from remote admin, eg from
    > the Internet through the Corp firewall. Remote access is well served via
    > VPN or its SSH sister. These tools are not (or should not be necessary
    > unless you have an Class A Security environment (see the Yellow Book).
    >
    > as for the rest of the trivel ... the blackboard is all yours ... have fun
    > :-)


    It's on topic, because it addressed your specific reasons for giving what is
    some unfortunately bad advice which it's clear you yourself do not or cannot
    follow in even a medium sized environment. You handwaved "never log in as
    root remotely" while leaving out the part "from outside the domain". Such
    cavalier advice can lead newbies down some unfortunate paths that will
    frustrate them and waste their limited time.

    I believe Richard is also correct in that you make factual errors. Please
    think out and maybe even look up your answers before you try to give them,
    rather than force someone else here to correct your post and help the
    newbie. It's hard.



+ Reply to Thread