PLINK and/or PuTTY -- Logon to Linux with no Privileges - SSH

This is a discussion on PLINK and/or PuTTY -- Logon to Linux with no Privileges - SSH ; I need a forwarding application that people I'm working with can run from behind restrictive firewalls so VNC can be tunneled through it. I figured it would be possible to use putty or plink on port 443 so it would ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: PLINK and/or PuTTY -- Logon to Linux with no Privileges

  1. PLINK and/or PuTTY -- Logon to Linux with no Privileges

    I need a forwarding application that people I'm working with can run from
    behind restrictive firewalls so VNC can be tunneled through it. I figured
    it would be possible to use putty or plink on port 443 so it would look
    like HTTPS to a firewall (is that right -- will the firewall think
    encrypted data from putty/plink is the same as HTTPS?).

    The biggest problem I see is that I'll have several different people using
    putty or plink to log into my system and there is no need for them to
    actually have access to anything (other than the ability to log out). All
    I need is the port forwarding.

    I'm running Linux. Is there a way to set up a restricted login (even if I
    have to kill it with a kill command instead of them logging out) for putty
    or plink? Or is there a way to set up an account for others to log in to
    that has no rights except the ability to log out?

    Thanks for any help, links or info on this.

    Hal

  2. Re: PLINK and/or PuTTY -- Logon to Linux with no Privileges


    "Hal Vaughan" wrote in message
    news:ftSdnSyGnf_rF4LZnZ2dnUVZ_s6dnZ2d@comcast.com. ..
    >I need a forwarding application that people I'm working with can run from
    > behind restrictive firewalls so VNC can be tunneled through it. I figured
    > it would be possible to use putty or plink on port 443 so it would look
    > like HTTPS to a firewall (is that right -- will the firewall think
    > encrypted data from putty/plink is the same as HTTPS?).


    There are firewalls that can detect this sort of thing, but not many that
    bother with that sort of smarts.

    > The biggest problem I see is that I'll have several different people using
    > putty or plink to log into my system and there is no need for them to
    > actually have access to anything (other than the ability to log out). All
    > I need is the port forwarding.


    Hmm. Does your network staff know you're doing this sort of stunt? Perhaps
    you can convince them to open up the standard VNC ports for you instead of
    trying to work around them, rather than having to sneak behind their backs
    and maybe cause them to get really cranky at you if they find you're
    drilling holes past their firewalls without their knowledge? Your desire is
    reasonable: I hope your network staff is reasonable and can help you get it
    done.

    It's possible to set up SSH in a chroot cage for more thorough restriction,
    or to use a sort-of-restrictive shell for the users. Check out the projects
    on sourceforge like http://sourceforge.net/projects/chrootssh. But I highly
    recommend Richard Silverman's book on SSH for this sort of detailed
    question. He spends time on this newsgroup, and it's well worth the price of
    the book for the depth and breadth of its information.

    > I'm running Linux. Is there a way to set up a restricted login (even if I
    > have to kill it with a kill command instead of them logging out) for putty
    > or plink? Or is there a way to set up an account for others to log in to
    > that has no rights except the ability to log out?


    Not..... trivially. It's theoretically possible, for example, to set up a
    restricted login binary to do just this, but a lot of "restricted shells"
    have just been badly written shell scripts that were easily broken out of
    because, well, they're shell scripts! And it can get complex if you are
    using a universal authentication method like LDAP to manage accounts, since
    the information about their login from LDAP\06 conflict with the setup you
    want to have them restricted to.



  3. Re: PLINK and/or PuTTY -- Logon to Linux with no Privileges

    Nico Kadel-Garcia wrote:

    >
    > "Hal Vaughan" wrote in message
    > news:ftSdnSyGnf_rF4LZnZ2dnUVZ_s6dnZ2d@comcast.com. ..
    >>I need a forwarding application that people I'm working with can run from
    >> behind restrictive firewalls so VNC can be tunneled through it. *I
    >> figured it would be possible to use putty or plink on port 443 so it
    >> would look like HTTPS to a firewall (is that right -- will the firewall
    >> think encrypted data from putty/plink is the same as HTTPS?).

    >
    > There are firewalls that can detect this sort of thing, but not many that
    > bother with that sort of smarts.


    Now that I'm thinking about it -- and I don't know much about this -- I
    would think one type of encrypted data would look like any other. *We've
    tried just regular VNC, with no luck, then tried it on port 80, with no
    luck. *My best guess is that it's not only filtering based on ports, but on
    the type of data or packets. *If so, from what I understand, encrypted data
    on port 443 will seem close enough to HTTPS that it should go through.
    That makes me wonder, though, if I could just run VNC normally on port 443
    and it would likely go through. *Is that likely? *My guess on this is that
    it's hard to check encrypted data so not much checking would be done on
    that port anyway. *Is that at all close to fact or is there any basis for
    that idea?

    >> The biggest problem I see is that I'll have several different people
    >> using putty or plink to log into my system and there is no need for them
    >> to
    >> actually have access to anything (other than the ability to log out).
    >> All I need is the port forwarding.

    >
    > Hmm. Does your network staff know you're doing this sort of stunt? Perhaps
    > you can convince them to open up the standard VNC ports for you instead of
    > trying to work around them, rather than having to sneak behind their backs
    > and maybe cause them to get really cranky at you if they find you're
    > drilling holes past their firewalls without their knowledge? Your desire
    > is reasonable: I hope your network staff is reasonable and can help you
    > get it done.


    Actually, I'm dealing with admin people who have authority over IT people
    and basically would prefer me do this than change the firewall. *In one
    case there's a Cisco router handling it and a history of having trouble
    finding anyone who knows IOS to program it, so the feeling is, "The
    firewall's working. *Nobody's touching it. *If you can find a way to work
    with it, great."

    > It's possible to set up SSH in a chroot cage for more thorough
    > restriction, or to use a sort-of-restrictive shell for the users. Check
    > out the projects
    > on sourceforge like http://sourceforge.net/projects/chrootssh. *But I
    > highly recommend Richard Silverman's book on SSH for this sort of detailed
    > question. He spends time on this newsgroup, and it's well worth the price
    > of the book for the depth and breadth of its information.


    I never knew any of that was possible. *Do you have Silverman's book title?
    I'm searching the local bookstores for it, in hopes I can get a copy today.
    I've been working on this for a few weeks and I really need to get it
    resolved before more work piles up. *I've found one he co-authored, "SSH,
    the Secure Shell: The Definitive Guide". *Is that it?

    >> I'm running Linux. *Is there a way to set up a restricted login (even if
    >> I have to kill it with a kill command instead of them logging out) for
    >> putty
    >> or plink? *Or is there a way to set up an account for others to log in to
    >> that has no rights except the ability to log out?

    >
    > Not..... trivially. It's theoretically possible, for example, to set up a
    > restricted login binary to do just this, but a lot of "restricted shells"
    > have just been badly written shell scripts that were easily broken out of
    > because, well, they're shell scripts! And it can get complex if you are
    > using a universal authentication method like LDAP to manage accounts,
    > since the information about their login from LDAP6 conflict with the
    > setup you want to have them restricted to.


    So what kind of search terms are best on this? *Restricted shell?
    Restricted login? *I can understand why a script would be bad. *I figured
    this either had to be done by some special shell or something special with
    permissions and the group the user is in, but this is not an area I know
    much about. *I do know enough to know that what you don't know in security
    can nail you, which is why I'm asking all of this.

    Thanks for the answers and help.

    Hal

  4. Re: PLINK and/or PuTTY -- Logon to Linux with no Privileges

    >>>>> "HV" == Hal Vaughan writes:

    HV> My guess on this is that it's hard to check encrypted data so not
    HV> much checking would be done on that port anyway. *Is that at all
    HV> close to fact or is there any basis for that idea?

    If it were just "encrypted data," it might be, but detecting which
    protocol is in use is easy, among other reasons because the connection
    setup is, perforce, not encrypted.

    HV> Actually, I'm dealing with admin people who have authority over IT
    HV> people and basically would prefer me do this than change the
    HV> firewall. *In one case there's a Cisco router handling it and a
    HV> history of having trouble finding anyone who knows IOS to program
    HV> it, so the feeling is, "The firewall's working. *Nobody's touching
    HV> it. *If you can find a way to work with it, great."

    Well-run shop.

    HV> I never knew any of that was possible. *Do you have Silverman's
    HV> book title? I'm searching the local bookstores for it, in hopes I
    HV> can get a copy today. I've been working on this for a few weeks
    HV> and I really need to get it resolved before more work piles
    HV> up. *I've found one he co-authored, "SSH, the Secure Shell: The
    HV> Definitive Guide". *Is that it?

    Yes, that's it. Along with Dan Barrett, and Bob Byrnes on the second
    edition.

    http://www.ora.com/catalog/sshtdg2/

    >>> I'm running Linux. *Is there a way to set up a restricted login
    >>> (even if I have to kill it with a kill command instead of them
    >>> logging out) for putty or plink? *Or is there a way to set up an
    >>> account for others to log in to that has no rights except the
    >>> ability to log out?


    Actually, this is easy, since the client does not have to start a shell to
    do port forwarding. The account can have /bin/false as the shell. The
    client should do the equivalent of OpenSSH "ssh -N -L x:y:z server-host".
    Note this requires SSH protocol version 2.

    --
    Richard Silverman
    res@qoxp.net


  5. Re: PLINK and/or PuTTY -- Logon to Linux with no Privileges

    Hal Vaughan wrote:
    > Nico Kadel-Garcia wrote:
    >
    >>
    >> "Hal Vaughan" wrote in message
    >> news:ftSdnSyGnf_rF4LZnZ2dnUVZ_s6dnZ2d@comcast.com. ..
    >>> I need a forwarding application that people I'm working with can
    >>> run from behind restrictive firewalls so VNC can be tunneled
    >>> through it. I figured it would be possible to use putty or plink on
    >>> port 443 so it would look like HTTPS to a firewall (is that right
    >>> -- will the firewall think encrypted data from putty/plink is the
    >>> same as HTTPS?).

    >>
    >> There are firewalls that can detect this sort of thing, but not many
    >> that bother with that sort of smarts.

    >
    > Now that I'm thinking about it -- and I don't know much about this --
    > I would think one type of encrypted data would look like any other.
    > We've tried just regular VNC, with no luck, then tried it on port 80,
    > with no luck. My best guess is that it's not only filtering based on
    > ports, but on the type of data or packets. If so, from what I
    > understand, encrypted data on port 443 will seem close enough to
    > HTTPS that it should go through. That makes me wonder, though, if I
    > could just run VNC normally on port 443 and it would likely go
    > through. Is that likely? My guess on this is that it's hard to check
    > encrypted data so not much checking would be done on that port
    > anyway. Is that at all close to fact or is there any basis for that
    > idea?


    Nope. SSH session traffic, for example, tends to be both ways as opposed to
    HTTPS, which is mostly download. And the beginning of both connections where
    keys are passed around and collected look rather different.

    But running VNC on port 443 is feasiable. Running services on ports below
    1024, at least on Linux, requires root privelege. Perhaps 8080 is open? And
    less likely to be in use on the target machine?

    >> Hmm. Does your network staff know you're doing this sort of stunt?
    >> Perhaps you can convince them to open up the standard VNC ports for
    >> you instead of trying to work around them, rather than having to
    >> sneak behind their backs and maybe cause them to get really cranky
    >> at you if they find you're drilling holes past their firewalls
    >> without their knowledge? Your desire is reasonable: I hope your
    >> network staff is reasonable and can help you get it done.

    >
    > Actually, I'm dealing with admin people who have authority over IT
    > people and basically would prefer me do this than change the
    > firewall. In one case there's a Cisco router handling it and a
    > history of having trouble finding anyone who knows IOS to program it,
    > so the feeling is, "The firewall's working. Nobody's touching it. If
    > you can find a way to work with it, great."


    I detect weasel wording. Does the *IT* staff know you're doing this? They're
    the ones whose job it is to keep things running. If you leave something
    running that they don't even know about, or they're gathering information to
    plan an upgrade of the Cisco router to something more manageable, this is
    information that could help them avoid a problem down the road.

    > I never knew any of that was possible. Do you have Silverman's book
    > title? I'm searching the local bookstores for it, in hopes I can get
    > a copy today. I've been working on this for a few weeks and I really
    > need to get it resolved before more work piles up. I've found one he
    > co-authored, "SSH, the Secure Shell: The Definitive Guide". Is that
    > it?


    Yes, Richard responded on this. I highly recommend it.

    >>> I'm running Linux. Is there a way to set up a restricted login
    >>> (even if I have to kill it with a kill command instead of them
    >>> logging out) for putty
    >>> or plink? Or is there a way to set up an account for others to log
    >>> in to that has no rights except the ability to log out?

    >>
    >> Not..... trivially. It's theoretically possible, for example, to set
    >> up a restricted login binary to do just this, but a lot of
    >> "restricted shells" have just been badly written shell scripts that
    >> were easily broken out of because, well, they're shell scripts! And
    >> it can get complex if you are using a universal authentication
    >> method like LDAP to manage accounts, since the information about
    >> their login from LDAP6 conflict with the setup you want to have
    >> them restricted to.

    >
    > So what kind of search terms are best on this? Restricted shell?
    > Restricted login? I can understand why a script would be bad. I
    > figured this either had to be done by some special shell or something
    > special with permissions and the group the user is in, but this is
    > not an area I know much about. I do know enough to know that what you
    > don't know in security can nail you, which is why I'm asking all of
    > this.


    Good man. *WISE* man. Somebody get this guy a cookie! We want to encourage
    sensible people to actually ask questions.

    I like Richard's "use /bin/false as their shell and have the client do the
    port forwarding setup".



  6. Re: PLINK and/or PuTTY -- Logon to Linux with no Privileges

    Nico Kadel-Garcia wrote:

    > Hal Vaughan wrote:
    >> Nico Kadel-Garcia wrote:
    >>
    >>>
    >>> "Hal Vaughan" wrote in message
    >>> news:ftSdnSyGnf_rF4LZnZ2dnUVZ_s6dnZ2d@comcast.com. ..
    >>>> I need a forwarding application that people I'm working with can
    >>>> run from behind restrictive firewalls so VNC can be tunneled
    >>>> through it. I figured it would be possible to use putty or plink on
    >>>> port 443 so it would look like HTTPS to a firewall (is that right
    >>>> -- will the firewall think encrypted data from putty/plink is the
    >>>> same as HTTPS?).
    >>>
    >>> There are firewalls that can detect this sort of thing, but not many
    >>> that bother with that sort of smarts.

    >>
    >> Now that I'm thinking about it -- and I don't know much about this --
    >> I would think one type of encrypted data would look like any other.
    >> We've tried just regular VNC, with no luck, then tried it on port 80,
    >> with no luck. My best guess is that it's not only filtering based on
    >> ports, but on the type of data or packets. If so, from what I
    >> understand, encrypted data on port 443 will seem close enough to
    >> HTTPS that it should go through. That makes me wonder, though, if I
    >> could just run VNC normally on port 443 and it would likely go
    >> through. Is that likely? My guess on this is that it's hard to check
    >> encrypted data so not much checking would be done on that port
    >> anyway. Is that at all close to fact or is there any basis for that
    >> idea?

    >
    > Nope. SSH session traffic, for example, tends to be both ways as opposed
    > to HTTPS, which is mostly download. And the beginning of both connections
    > where keys are passed around and collected look rather different.


    Okay. Thanks for clearing that up for me. I've never had as much trouble
    finding answers as when I started to deal with this topic, including
    finding out how to build some static binaries for Linux. Any help and
    answers are highly appreciated.

    > But running VNC on port 443 is feasiable. Running services on ports below
    > 1024, at least on Linux, requires root privelege. Perhaps 8080 is open?
    > And less likely to be in use on the target machine?


    It can vary. Right now I'm dealing directly with two people with
    restrictive firewalls. On one we actually got SSH through and that was a
    huge relief. It seems all ports but the general ones (POP, SMTP, HTTP,
    HTTPS, and a few like that) are blocked off. Right now I'm trying to come
    up with a solution I can use for these two situations but will likely work
    for others in the future. I've had no trouble (on my network) running VNC
    or different tunnelers on 443. It seems the problem is running a server
    socket on 443, but 1) that's on my workstation where I can do what I want,
    and 2) I can always change the port on the firewall when it's forwarded
    through.

    >>> Hmm. Does your network staff know you're doing this sort of stunt?
    >>> Perhaps you can convince them to open up the standard VNC ports for
    >>> you instead of trying to work around them, rather than having to
    >>> sneak behind their backs and maybe cause them to get really cranky
    >>> at you if they find you're drilling holes past their firewalls
    >>> without their knowledge? Your desire is reasonable: I hope your
    >>> network staff is reasonable and can help you get it done.

    >>
    >> Actually, I'm dealing with admin people who have authority over IT
    >> people and basically would prefer me do this than change the
    >> firewall. In one case there's a Cisco router handling it and a
    >> history of having trouble finding anyone who knows IOS to program it,
    >> so the feeling is, "The firewall's working. Nobody's touching it. If
    >> you can find a way to work with it, great."

    >
    > I detect weasel wording. Does the *IT* staff know you're doing this?
    > They're the ones whose job it is to keep things running. If you leave
    > something running that they don't even know about, or they're gathering
    > information to plan an upgrade of the Cisco router to something more
    > manageable, this is information that could help them avoid a problem down
    > the road.


    No weasel wording. At this time I'm still broke because I'm still starting
    the business and finishing all the software, so I can't add all the
    customers I'd like, but I deal with small businesses or people who work in
    small businesses and can directly effect their bottom line, so they really
    want to work with me. That means I'm dealing with the boss who tells IT
    what to do or someone who has the boss' willing cooperation. The idea is
    to have scripts for Windows and Linux and have RealVNC as well as what I
    use for tunneling (likely plink at this point, but I have a
    problem/question about libraries and/or static binaries) on the install CD,
    so they do not go on the actual computer. When there's a problem, my
    customer can run the script that creates the tunnel and runs RealVNC as a
    server, adding my system as a client. They only do that when I tell them
    to because I also have to be there AND I have to open my firewall port
    (normally closed). When I'm done, I run a script that kills both RealVNC
    and plink, as well as (of course) breaking my connection. Then they take
    the CD out so neither program is there for exploits or bad employees to use
    for bad things.

    Generally it ends up that the business owner has hired IT people part time,
    or as needed, and would rather me run a tunnel than pay to have anything
    changed on the firewall and often I've gotten to know the IT people, at
    least in passing, so I can (if they aren't overly secretive) find out what
    they've done. In some cases, though, I'm dealing with people who won't say
    a thing, and I suspect it's more because they can't remember or
    subcontracted it because they're clueless.

    ....
    >> So what kind of search terms are best on this? Restricted shell?
    >> Restricted login? I can understand why a script would be bad. I
    >> figured this either had to be done by some special shell or something
    >> special with permissions and the group the user is in, but this is
    >> not an area I know much about. I do know enough to know that what you
    >> don't know in security can nail you, which is why I'm asking all of
    >> this.

    >
    > Good man. *WISE* man. Somebody get this guy a cookie! We want to encourage
    > sensible people to actually ask questions.


    Thanks. I've been chewed out in a few forums for asking newbie questions.
    In the past I've found (in Usenet groups) Perl programmers will always get
    your question answered, but may be rather arrogant about it, Java
    programmers always provide detailed and professional help, but when I've
    asked any C questions, it's RTFM unless you know the secret handshake --
    and they seem loathe to even say which FM or where it's located. (At least
    that's my current experience.) I'm very appreciative of the help I'm
    getting here. This is an area I have not explored yet, and I'm in a
    situation where I have to get a working solution, then after this phase is
    done, I'll have time to sit and read a full book or two on it.

    > I like Richard's "use /bin/false as their shell and have the client do the
    > port forwarding setup".


    So do I. I had found Iron Bars Shell, and was looking into that and had
    tried it, but /bin/false works much better and doesn't give the person a
    chance to even try any shell commands. A perfect *nix type solution.

    Thank you both for all the help. I'll let you know how it turns out.

    Hal

+ Reply to Thread