PLINK and/or PuTTY -- Logon to Linux with no Privileges
Hal Vaughan
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
Nico Kadel-Garcia
"Hal Vaughan" <h...@thresholddigital.com> wrote in message
news:ftSdnSyGnf_rF4LZ...@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説
Hal Vaughan
>
> "Hal Vaughan" <h...@thresholddigital.com> wrote in message
> news:ftSdnSyGnf_rF4LZ...@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 LDAP à6 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
Richard E. Silverman
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
r...@qoxp.net
Nico Kadel-Garcia
> Nico Kadel-Garcia wrote:
>
>>
>> "Hal Vaughan" <h...@thresholddigital.com> wrote in message
>> news:ftSdnSyGnf_rF4LZ...@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 LDAP説6 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".
Hal Vaughan
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