I am trying to set up a secure PPP tunnel between an OpenSSH client and server, and am having problems establishing the tunnel. ----------------------------------------------------------------------------- Server information: Stock Redhat 6.1 machine running a 2.2.12 kernel OpenSSH version 2.2.0p1 (downloaded as Redhat RPMs, revision 2) OpenSSL version 0.9.5a (downloaded as Redhat RPMs, revision 3) PPP version 2.3.10 One exposed external IP address (for this list, assume to be 100.100.100.100) /etc/ssh/sshd_config: Port 22 Protocol 2,1 ListenAddress 0.0.0.0 HostKey /etc/ssh/ssh_host_key HostDSAKey /etc/ssh/ssh_host_dsa_key ServerKeyBits 768 LoginGraceTime 600 KeyRegenerationInterval 3600 PermitRootLogin no IgnoreRhosts yes StrictModes yes X11Forwarding no X11DisplayOffset 10 PrintMotd yes KeepAlive yes /etc/ppp/options: lock local noauth proxyarp Client information: *Stock Redhat 6.2 machine running a 2.2.17pre20 kernel OpenSSH version 2.2.0p1 (downloaded as Redhat RPMs, revision 2) OpenSSL version 0.9.5a (downloaded as Redhat RPMs, revision 3) PPP version 2.3.11 /etc/ssh/ssh_config: Empty (default) /etc/ppp/options: lock noauth * This has also failed on Redhat 6.1 (kernel 2.2.12) and Redhat 6.9.5 (kernel 2.2.16) machines with the same results. ----------------------------------------------------------------------------------------- What happens: We attempt to connect to the OpenSSH server with the following command, run in a terminal: /usr/sbin/pppd -detach lcp-echo-failure 600 lcp-echo-interval 600 local passive pty "ssh -t -l <username> 100.100.100.100 /usr/sbin/pppd file /etc/ppp/options-<username>" (The options-username file on the server simply contains an IP address, such that the client machine is set up with a static IP to attach to the server.) When executed, OpenSSH asks for the password to gain entry to the server, after which the connection appears to hang while negotiating a PPP connection. PPPd on the client side eventually fails with 'LCP: timeout sending Config-Requests'. This behavior remains constant whether the '-e none' option is provided to ssh or not, on the client side. However, the pppd command on the server IS executed, as shown by its server logs, so we know the ssh session is being established. At this point, we are lead to suspect that either the virtual tty allocation or emulation is not sending binary characters through properly, or that some sort of character sequence is being interpreted by openssh despite the '-e none' option specified. The OpenSSH client seems to be suspect, because when the commercial SSH RPM available at (ftp://ftp.ssh.com/pub/ssh/rpms/ssh-2.3.0-1.i386.rpm) is called upon to perform the same command on the client side, the ppp tunnel is successfully established with the OpenSSH server -- whether run in a terminal or inside a script. I've tried compiling the OpenSSH RPM from source on multiple client machines in case that was an issue; it had no effect on the problem. I'll try to provide any debugging information if needed; please advise. Robert Steinfeldt -- robert.steinfeldt at steeleye.com
Yo Robert! OpenSSH and SSH tunnel IP. PPP is a layer underneath IP used for point to point connections. OpenSSH does not tunnel PPP or any other protocol under IP. If you need PPP then you need to find a way to tunnel it inside IP and then tunnel that IP in SSH. RGDS GARY --------------------------------------------------------------------------- Gary E. Miller Rellim 20340 Empire Ave, Suite E-3, Bend, OR 97701 gem at rellim.com Tel:+1(541)382-8588 Fax: +1(541)382-8676 On Fri, 8 Sep 2000, Robert Steinfeldt wrote:> I am trying to set up a secure PPP tunnel between an OpenSSH client and > server, and am having problems establishing the tunnel.
Either you need to use a userspace PPP software (which you may find on
www.freshmeat.net) or I suggest checking out the the
following Linux howtos:
http://www.linux.org/docs/ldp/howto/VPN-HOWTO.html
http://www.linux.org/docs/ldp/howto/VPN-Masquerade-HOWTO.html
The first one explains SSH and PPP Theories in VPNing.
I believe the much more prefered method of connection distance networks
is really IPSec (Which requires a patch to the 2.{0,2,4} kernels).
On Fri, 8 Sep 2000, Robert Steinfeldt wrote:
> I am trying to set up a secure PPP tunnel between an OpenSSH client and
> server, and am having problems establishing the tunnel.
>
>
-----------------------------------------------------------------------------
>
> Server information:
> Stock Redhat 6.1 machine running a 2.2.12 kernel
> OpenSSH version 2.2.0p1 (downloaded as Redhat RPMs, revision 2)
> OpenSSL version 0.9.5a (downloaded as Redhat RPMs, revision 3)
> PPP version 2.3.10
> One exposed external IP address (for this list, assume to be
> 100.100.100.100)
>
> /etc/ssh/sshd_config:
> Port 22
> Protocol 2,1
> ListenAddress 0.0.0.0
> HostKey /etc/ssh/ssh_host_key
> HostDSAKey /etc/ssh/ssh_host_dsa_key
> ServerKeyBits 768
> LoginGraceTime 600
> KeyRegenerationInterval 3600
> PermitRootLogin no
> IgnoreRhosts yes
> StrictModes yes
> X11Forwarding no
> X11DisplayOffset 10
> PrintMotd yes
> KeepAlive yes
>
> /etc/ppp/options:
> lock
> local
> noauth
> proxyarp
>
> Client information:
> *Stock Redhat 6.2 machine running a 2.2.17pre20 kernel
> OpenSSH version 2.2.0p1 (downloaded as Redhat RPMs, revision 2)
> OpenSSL version 0.9.5a (downloaded as Redhat RPMs, revision 3)
> PPP version 2.3.11
>
> /etc/ssh/ssh_config:
> Empty (default)
>
> /etc/ppp/options:
> lock
> noauth
>
> * This has also failed on Redhat 6.1 (kernel 2.2.12) and Redhat 6.9.5
> (kernel 2.2.16) machines with the same results.
>
>
-----------------------------------------------------------------------------------------
>
> What happens:
> We attempt to connect to the OpenSSH server with the following command,
> run in a terminal:
>
> /usr/sbin/pppd -detach lcp-echo-failure 600 lcp-echo-interval 600 local
> passive pty "ssh -t -l <username> 100.100.100.100 /usr/sbin/pppd
file
> /etc/ppp/options-<username>"
>
> (The options-username file on the server simply contains an IP address,
> such that the client machine is set up with a static IP to attach to the
> server.)
>
> When executed, OpenSSH asks for the password to gain entry to the
> server, after which the connection appears to hang while negotiating a
> PPP connection. PPPd on the client side eventually fails with 'LCP:
> timeout sending Config-Requests'. This behavior remains constant
whether
> the '-e none' option is provided to ssh or not, on the client side.
> However, the pppd command on the server IS executed, as shown by its
> server logs, so we know the ssh session is being established. At this
> point, we are lead to suspect that either the virtual tty allocation or
> emulation is not sending binary characters through properly, or that
> some sort of character sequence is being interpreted by openssh despite
> the '-e none' option specified.
>
> The OpenSSH client seems to be suspect, because when the commercial SSH
> RPM available at (ftp://ftp.ssh.com/pub/ssh/rpms/ssh-2.3.0-1.i386.rpm)
> is called upon to perform the same command on the client side, the ppp
> tunnel is successfully established with the OpenSSH server -- whether
> run in a terminal or inside a script. I've tried compiling the OpenSSH
> RPM from source on multiple client machines in case that was an issue;
> it had no effect on the problem. I'll try to provide any debugging
> information if needed; please advise.
>
> Robert Steinfeldt -- robert.steinfeldt at steeleye.com
>
Yo Ben! I guess I have to take my foot out of my mouth. There it is in black and white. On Fri, 8 Sep 2000, Ben Lindstrom wrote:> Either you need to use a userspace PPP software (which you may find on > www.freshmeat.net) or I suggest checking out the the > following Linux howtos: > > http://www.linux.org/docs/ldp/howto/VPN-HOWTO.html > http://www.linux.org/docs/ldp/howto/VPN-Masquerade-HOWTO.html > > The first one explains SSH and PPP Theories in VPNing.RGDS GARY --------------------------------------------------------------------------- Gary E. Miller Rellim 20340 Empire Ave, Suite E-3, Bend, OR 97701 gem at rellim.com Tel:+1(541)382-8588 Fax: +1(541)382-8676