f



Mac-to-Mac VPN?

Years ago, I set up a Mac network (under OS9) with a VPN router and some 
software on a remote PowerBook that allowed VPN access. I'm not terribly 
familiar with OSX yet, but I understand that much of this functionality 
is now built in. Can anybody steer me in the right direction as far as 
hardware, software and configuration? Here's the setup I envision:

 - Small LAN running two Macs and a printer with a DSL 
   connection through a router.
 - Remote PowerBook connected to the net varyingly with 
   dial-up, DSL (wired), and AirPort.
 - Use the PowerBook to securely connect to at least one 
   of the machines on the LAN for file transfers, 
   contact/calendar sync (through Now server software), 
   and if possible, remote access.

Note that, at times, BOTH sides of this connection will have dynamic IP 
addresses, so there's got to be a way to "find" the office LAN remotely, 
and the security protocols of the VPN setup cannot limit the incoming IP 
to a specific address. Also note that I don't need to connect both ways, 
just to initiate from the PowerBook.

I'm not opposed to buying a VPN router, or any other hardware, if it 
makes the system more stable/reliable/simple. Thanks very much in 
advance for any help you can provide.

Steve
0
6/5/2005 11:50:02 AM
comp.sys.mac.comm 3057 articles. 0 followers. Post Follow

16 Replies
2032 Views

Similar Articles

[PageSpeed] 8

On 2005-06-05, Steve C <newsgroups@primedigital.com> wrote:
> Note that, at times, BOTH sides of this connection will have dynamic IP 
> addresses, so there's got to be a way to "find" the office LAN remotely,

Seems to me you have to have a fixed name, at least.  Fortunately this
is easy and free. See, among other solutions, http://www.dynds.org

This will give your lan router a name that can always be found,
regardless of the numeric ip.  Depending on the router, you might need
to run some software on one of the lan machines to keep the name in
sync.  If you have a modern router it may be able to handle this task
itself.

At this point your router is accessible from anywhere, via a fixed
symbolic hostname.

Now pick one of the lan machines to act as a public server, and
configure the lan router to forward requests on port 22 to that server.
This will give you ssh access to the server, which in turn will give you
access to all the other lan machines.  If you ssh from the remote PB to
the fixed symbolic hostname for the lan router, you'll find yourself
talking to the designated server machine on the lan. 

As for vpn, standard OSX includes vpn client support, but not vpn server
support.  For the latter either you need OSX Server, or you need to use
third-party vpn tools.  The simple, expensive solution is to run OSX
Server on the designated server machine and run the vpn server there.

The somewhat more complicated but completely free solution is to use
openvpn.  You'll have to use it on both ends, client as well as server,
since the builtin OSX vpn client can't talk to openvpn servers.
Configuring openvpn isn't too bad but it's not trivial either. I can
guide you through this if you're willing to use the command line.

A third possible solution is another freeware vpn package called
openswan.  I haven't used this myself but as I understand it, the
builtin OSX vpn client can talk to openswan servers.  The downside is
that openswan is supposedly much more complicated to configure than
openvpn is.

I'm not sure you really need a vpn at all - you might be able to do
everything you want to do via ssh.  If you do decide you need vpn, then
either you need the router to forward another port to the designated
server, or you need to tunnel the vpn connection through ssh.  The
second approach adds some overhead but it has the definite advantage of
leaving only one port open, rather than two.


>  - Use the PowerBook to securely connect to at least one of the
>  machines on the LAN for file transfers,

You don't need a vpn for this.  Just use scp/sftp, with or without a gui
wrapper.  You can also do AFP (Apple file-sharing) without a vpn by
tunneling it through an ssh connection.  So again only ssh is needed.

 
>    contact/calendar sync (through Now server software)

I don't use Now so I have no idea what the requirements are.

 
>    and if possible, remote access.

Exactly what kind of access are you thinking of?
0
schreberdp (707)
6/5/2005 1:45:26 PM
Thanks for the detailed response.

Is buying a VPN router another possible solution to the VPN Server 
issue? Again, I'm looking for stability foremost, as I may be on the 
road with the PowerBook for months at a time. If a hardware solution 
will require less maintenance than the software one, I'll spend the 
extra money.

When using a router/firewall, Now requires that two specific ports be 
opened and forwarded to the machine hosting the server software. Without 
a router, you just have to configure the remote machine with the correct 
IP address. Seems pretty straightforward, but I don't know how it will 
work with encryption.

On the remote access issue, I was thinking about Timbuktu, because I've 
used it before effectively. However, I'm open to other suggestions. I've 
heard mentions of RDC. What's that?

As far as VPN vs. SSH, I have to admit that I don't really know what I'm 
talking about here. I'll have to do some research. My concern is that I 
will have a number of open ports (for Now, remote control, file sharing, 
possibly iChat, and some other stuff) on a LAN that is exposed to the 
internet without me being there to monitor it. I want to be able to 
communicate remotely AND securely... that is, without people being able 
to snoop on my connection, and without people being able to easily 
exploit my network when I'm not around. If I can do that with SSH, or 
any other protocol that's simpler to set up than a full VPN, all the 
better.

Thanks again for the help.

Steve



In article <toCdncyJKqlrnD7fRVn-sg@comcast.com>,
 D P Schreber <schreberdp@rayban.net> wrote:

> On 2005-06-05, Steve C <newsgroups@primedigital.com> wrote:
> > Note that, at times, BOTH sides of this connection will have dynamic IP 
> > addresses, so there's got to be a way to "find" the office LAN remotely,
> 
> Seems to me you have to have a fixed name, at least.  Fortunately this
> is easy and free. See, among other solutions, http://www.dynds.org
> 
> This will give your lan router a name that can always be found,
> regardless of the numeric ip.  Depending on the router, you might need
> to run some software on one of the lan machines to keep the name in
> sync.  If you have a modern router it may be able to handle this task
> itself.
> 
> At this point your router is accessible from anywhere, via a fixed
> symbolic hostname.
> 
> Now pick one of the lan machines to act as a public server, and
> configure the lan router to forward requests on port 22 to that server.
> This will give you ssh access to the server, which in turn will give you
> access to all the other lan machines.  If you ssh from the remote PB to
> the fixed symbolic hostname for the lan router, you'll find yourself
> talking to the designated server machine on the lan. 
> 
> As for vpn, standard OSX includes vpn client support, but not vpn server
> support.  For the latter either you need OSX Server, or you need to use
> third-party vpn tools.  The simple, expensive solution is to run OSX
> Server on the designated server machine and run the vpn server there.
> 
> The somewhat more complicated but completely free solution is to use
> openvpn.  You'll have to use it on both ends, client as well as server,
> since the builtin OSX vpn client can't talk to openvpn servers.
> Configuring openvpn isn't too bad but it's not trivial either. I can
> guide you through this if you're willing to use the command line.
> 
> A third possible solution is another freeware vpn package called
> openswan.  I haven't used this myself but as I understand it, the
> builtin OSX vpn client can talk to openswan servers.  The downside is
> that openswan is supposedly much more complicated to configure than
> openvpn is.
> 
> I'm not sure you really need a vpn at all - you might be able to do
> everything you want to do via ssh.  If you do decide you need vpn, then
> either you need the router to forward another port to the designated
> server, or you need to tunnel the vpn connection through ssh.  The
> second approach adds some overhead but it has the definite advantage of
> leaving only one port open, rather than two.
> 
> 
> >  - Use the PowerBook to securely connect to at least one of the
> >  machines on the LAN for file transfers,
> 
> You don't need a vpn for this.  Just use scp/sftp, with or without a gui
> wrapper.  You can also do AFP (Apple file-sharing) without a vpn by
> tunneling it through an ssh connection.  So again only ssh is needed.
> 
>  
> >    contact/calendar sync (through Now server software)
> 
> I don't use Now so I have no idea what the requirements are.
> 
>  
> >    and if possible, remote access.
> 
> Exactly what kind of access are you thinking of?
0
6/5/2005 6:07:30 PM
On 2005-06-05, Steve C <newsgroups@primedigital.com> wrote:
> Is buying a VPN router another possible solution to the VPN Server 
> issue? 

I have no experience with these devices, so I can't comment.


> Again, I'm looking for stability foremost, as I may be on the 
> road with the PowerBook for months at a time. If a hardware solution 
> will require less maintenance than the software one

I use openvpn regularly and it requires no maintenance at all.  On the
other hand my usage pattern requires the vpn to be up for hours at a
time, not months.  I honestly can't say how openvpn would perform in
your situation.


> When using a router/firewall, Now requires that two specific ports be 
> opened and forwarded to the machine hosting the server software. Without 
> a router, you just have to configure the remote machine with the correct 
> IP address. Seems pretty straightforward, but I don't know how it will 
> work with encryption.

Whether you tunnel through a vpn or through an ssh connection, the
encryption will be transparent to the final endpoints on both ends.


> As far as VPN vs. SSH, I have to admit that I don't really know what I'm 
> talking about here. 

If the remote machine only needs to use a few specific services on
specific lan hosts, and especially if for any one service it only needs
to contact one lan host, then you can easily tunnel the service
connections through ssh. If you need essentially full access to the lan,
vpn is a better choice.

Going through ssh is _much_ easier to configure. If you can get by with
that, you should imo. 


> I'll have to do some research. My concern is that I will have a number
> of open ports (for Now, remote control, file sharing, possibly iChat,
> and some other stuff) on a LAN that is exposed to the internet without
> me being there to monitor it.

You don't need all these services to be open in general.  They only need
to be open to other lan machines, since that's what the tunneled
connections from your remote machine will look like.  The only services
that have to be publicly accessible are ssh and/or the vpn. 

You can also tunnel the vpn connection itself through ssh, at least with
openvpn.  This is how I use it.  The result is that I can use both forms
of connection with only one service port open.  Depending on what I'm
doing at any particular time, I either tunnel specific service ports
through ssh, or I tunnel vpn through ssh.  It's not exactly efficient,
but it's certainly secure.

0
schreberdp (707)
6/5/2005 7:13:02 PM
In article <5OGdnRQK9u0j0z7fRVn-jw@comcast.com>,
 D P Schreber <schreberdp@rayban.net> wrote:

> If the remote machine only needs to use a few specific services on
> specific lan hosts, and especially if for any one service it only needs
> to contact one lan host, then you can easily tunnel the service
> connections through ssh. If you need essentially full access to the lan,
> vpn is a better choice.
> 
> Going through ssh is _much_ easier to configure. If you can get by with
> that, you should imo. 

Sounds like I can. I'll try to set it up with just ssh. If I run into 
configuration problems, I may take you up on your offer of help.

Thanks again. You're a gentleman and a scholar... well, in truth, I 
don't know if you're either, but you sure are helpful!  :-)

Steve
0
6/6/2005 2:47:22 AM
On 2005-06-06, Steve C <newsgroups@primedigital.com> wrote:
>  D P Schreber <schreberdp@rayban.net> wrote:
>> to contact one lan host, then you can easily tunnel the service
>> connections through ssh

Let me amend this slightly.  You can easily set up the tunnels, but
depending on the specific service, they might or might not be easy to
use when configured that way.  In general it depends how flexible the
client apps are about specifying non-standard ports. 
0
schreberdp (707)
6/6/2005 11:13:30 AM
+ D P Schreber <schreberdp@rayban.net>:

| I use openvpn regularly and it requires no maintenance at all.

It probably works fine so long as the network connections are pretty
reliable.  But I gather that there is a potential problem when
connectivity becomes flaky, as when you're using a WLAN at the limits
of its usability or your ISP is dropping packets due to traffic
congestion.  In a nutshell, the problem is that you are effectively
tunneling one TCP connection through another TCP connection.  Since
each deals with packet loss by a complicated algorithm of variable
timeouts and retransmissions, interaction between the two means that
the traffic could slow to a crawl when the connection is somewhat
unreliable.  There is a reason why most VPNs are UDP based.

Disclaimer: I am by no means a networking expert, so the above should
be taken with a healthy dose of salt.  But I did not invent the above
scenario: I read about it somewhere, though I don't remember where -
and I know just enough about TCP/IP networking to know that the theory
is plausible.  And as I said, so long as connectivity is good, it is
probably not a big deal.  Seek independent confirmation if optimal
performance under adverse conditions is important to you.

-- 
* Harald Hanche-Olsen     <URL:http://www.math.ntnu.no/~hanche/>
- Debating gives most of us much more psychological satisfaction
  than thinking does: but it deprives us of whatever chance there is
  of getting closer to the truth.  -- C.P. Snow

0
hanche (791)
6/6/2005 1:52:15 PM
On 2005-06-06, Harald Hanche-Olsen <hanche@math.ntnu.no> wrote:
> [openvpn] probably works fine so long as the network connections are
> pretty reliable.  

That's a fair assessement.  My networks are very reliable; I can't say
anything about how well openvpn would behave in flakier situations. 


> There is a reason why most VPNs are UDP based.

You can run openvpn over udp.  I happen not to be able to, for various
reasons, but I would if I could.
0
schreberdp (707)
6/6/2005 2:28:54 PM
In article
<newsgroups-565A0E.11072805062005@corp-radius.supernews.com>, Steve C
<newsgroups@primedigital.com> wrote:

> I'm looking for stability foremost, as I may be on the 
> road with the PowerBook for months at a time. If a hardware 
> solution  will require less maintenance than the software one, 
> I'll spend the  extra money.

       - - - and - - -

> On the remote access issue, I was thinking about Timbuktu, 
> because I've used it before effectively.


In my case, I decided to go with Timbuktu  (TB2)  - - -  _and_  some
hardware called "PowerKey Pro" from Sophisticated Circuits.

Like you, I plan to be on the road for months at a time, so I need full
control of all my remote Macs and PCs.


In my case, there is a further batch of complications, one of which is
that I am rapidly getting senile.   (76 years old)

I have trouble lately even finding the "on" switch of my computers,
much less configuring routers and such.

The latest versions of TB2 are the easiest way I have found so far, as
regards configuration and operation of a remote network of computers.

Latest version is 8.0.1 for Macs, version 8.0.0.1113 for PCs, as of
right now.

SSH is trivial to set up using TB2, even I can do it.




As regards reliability, consider what I would do if the Internet
connections I rely on were not available.  I then have all those remote
computers with their ports wide open, waiting for the first bad guy to
try to break into them.

In my case, I would place ordinary phone calls to the PowerKey hardware
of all my remote networks, and the PowerKey hardware would shut off the
main power to all those remote computers, printers, ext' drives, etc.,
etc., using a safe sequence of shutdown.

No Internet connection needed.

I imagine it could be rigged so that if a remote network did not hear
from me after a long period of time, that the remote network could
automatically shut itself down.



I especially like the ability to regain control of a completely frozen
computer, via forced main power off using PowerKey.

Naturally, later I could power-on all my remote computers, with another
batch of ordinary phone calls to the PowerKey hardware.



I am fairly certain that all the remote networks can also be powered
back on via the Internet also (using TB2) - but I have not tried it
yet.




One neat feature of the most recent version 8.0.1 of TB2, is that I can
install TB2 into  _any_   remote Mac that does not presently have TB2.

All that is necessary is that the remote computer has its "Remote
Access" turned on, and that the remote Mac user allows me enough
"privileges" to install TB2 into his Mac.

Directly upon my finishing the installation, I have control of the
remote Mac, as much or as little control as the remote user allows me.

If I deem it necessary, I also can limit him as to what he can do with
his newly installed TB2, so any usage restrictions apply both ways,
either one of us can limit the other person.

This remote install feature, called "push install", opens up a lot of
nice possibilities.

Any remote trusted Mac person would then be able to control  _my_  Mac,
or any of my network Macs or PCs that I saw fit to allow him to
control.

Very useful for demonstration and instructional purposes.



The down side of using TB2 is that $100 has to be shelled out for each
Mac or PC in the network - - - or $60 if the 30 pack is bought.

BTW, push install only works Mac to Mac, won't work for remote install
on a PC.

BTW#2, presently I am having fun running Tiger 10.4.1 on this old
Lombard powerbook, full screen, while I am typing this post to you.

(I am controlling a 17-inch Mac powerbook, from the old Lombard)


Mark-
Proud member of IEEE, ACM, and AAAI computer organizations.
(they do not yet know that I am senile,
     imagine their surprise when they find out)
0
NoSpamDammit (843)
6/6/2005 7:51:15 PM
In article <060620051251471616%NoSpamDammit@invalid.com>,
 Mark Conrad <NoSpamDammit@invalid.com> wrote:

> As regards reliability, consider what I would do if the Internet
> connections I rely on were not available.  I then have all those remote
> computers with their ports wide open, waiting for the first bad guy to
> try to break into them.

If you configure SSH to deny access other than PubKeyAuthentication then 
only machines which have participated in a public key exchange could 
connect to the remotes.  If, in addition, you arranged to tunnel all 
other network connections through the SSH port, the computers wouldn't 
have their ports wide open waiting for the bad guys.

-- 
Tom Stiller

PGP fingerprint =  5108 DDB2 9761 EDE5 E7E3 
                   7BDA 71ED 6496 99C0 C7CF
0
tomstiller (3053)
6/6/2005 9:11:44 PM
+ D P Schreber <schreberdp@rayban.net>:

| You can run openvpn over udp.

Ah, good.  I must have been to quick in my reading about it.
I'll definitely have another look, then.  Thanks.

-- 
* Harald Hanche-Olsen     <URL:http://www.math.ntnu.no/~hanche/>
- Debating gives most of us much more psychological satisfaction
  than thinking does: but it deprives us of whatever chance there is
  of getting closer to the truth.  -- C.P. Snow
0
hanche (791)
6/6/2005 9:22:43 PM
In article <tomstiller-9A8DA3.17114406062005@comcast.dca.giganews.com>,
Tom Stiller <tomstiller@comcast.net> wrote:

> If, in addition, you arranged to tunnel all 
> other network connections through the SSH port, the computers wouldn't 
> have their ports wide open waiting for the bad guys.

I was not aware that all the other ports could "go through" the one SSH
port, such that a cracker who tried to ping those ports would fail to
get any response.

For example, TB2 uses port 407 almost exclusively, whenever Timbuktu is
running.

If a cracker tried to ping a computer that was 'behind' the SSH system,
would the cracker be able to tell if TB2 was actively running on that
computer?

If that is true, it certainly would be worth my while to attempt to
learn how to configure the SSH system to achieve that desirable result
of hiding all the ports behind the one SSH port.

Whether I have enough smarts to learn all that geeky stuff is
questionable.    I don't have that much confidence in myself.



> If you configure SSH to deny access other than PubKeyAuthentication
> then only machines which have participated in a public key exchange 
> could connect to the remotes.

PublicKeyAuthentication is definitely more secure that the regular
password system used by OS X.

I am slowly trying to learn how to use it, but so far only know bits
and pieces, like how to generate brand new public keys from Terminal.

A few things puzzle me, like why it is supposedly "better" to use
pass-phrases as part of the Public Key system.

I thought that only two things were "necessary", namely each computer
owner creates his own Public Key via Terminal, then somehow private
keys are created.

I don't understand how pass-phrases enter into the picture.

Perhaps I am confusing the issue, maybe pass-phrases are not a part of
the PublicKeyAuthentication system.

I understand that the computers themselves send out their public keys
automatically at the very start of any connection attempt, then they
"listen" to see if the other computer automatically responds with an
"approved" private key.

I imagine that several weeks of intense Googling will clear up all
these mysteries for me.



Anyhow, when I  _think_  I have learned PublcKeyAuthentication, I would
like to test my new found knowledge on an in-house network of two Macs
connected to each other via an Ethernet cable. (no Internet connection)

Problem is, I don't think such an in-house system will work as a test,
because somehow I got the impression that a dedicated SSH public server
computer was a necessary part of any PublicKeyAuthentication system.

As you can readily see, I know very little about the subject.

Mark-
0
NoSpamDammit (843)
6/7/2005 8:40:12 AM
On 2005-06-07, Mark Conrad <NoSpamDammit@invalid.com> wrote:
> If a cracker tried to ping a computer that was 'behind' the SSH system,
> would the cracker be able to tell if TB2 was actively running on that
> computer?

Not unless you go out of your way to allow it.
0
schreberdp (707)
6/7/2005 11:33:23 AM
In article <070620050141054733%NoSpamDammit@invalid.com>,
 Mark Conrad <NoSpamDammit@invalid.com> wrote:

> In article <tomstiller-9A8DA3.17114406062005@comcast.dca.giganews.com>,
> Tom Stiller <tomstiller@comcast.net> wrote:
> 
> > If, in addition, you arranged to tunnel all 
> > other network connections through the SSH port, the computers wouldn't 
> > have their ports wide open waiting for the bad guys.
> 
> I was not aware that all the other ports could "go through" the one SSH
> port, such that a cracker who tried to ping those ports would fail to
> get any response.
> 
> For example, TB2 uses port 407 almost exclusively, whenever Timbuktu is
> running.
> 
> If a cracker tried to ping a computer that was 'behind' the SSH system,
> would the cracker be able to tell if TB2 was actively running on that
> computer?

No.  The tunnel works by defining two ports, one local and the other for 
the remote machine.  The remote machine listens in its port (e.g. 407) 
and the local machine connects to its port (whatever you choose).  The 
tunnel intercepts traffic directed to the local port, reroutes it over 
the secure channel, and presents it to the specified port on the remote 
machine.
> 
[snip]
> 
> 
> > If you configure SSH to deny access other than PubKeyAuthentication
> > then only machines which have participated in a public key exchange 
> > could connect to the remotes.
> 
> PublicKeyAuthentication is definitely more secure that the regular
> password system used by OS X.
> 
> I am slowly trying to learn how to use it, but so far only know bits
> and pieces, like how to generate brand new public keys from Terminal.
> 
> A few things puzzle me, like why it is supposedly "better" to use
> pass-phrases as part of the Public Key system.
> 
> I thought that only two things were "necessary", namely each computer
> owner creates his own Public Key via Terminal, then somehow private
> keys are created.
> 
> I don't understand how pass-phrases enter into the picture.

Keys are generated in pairs, one public and one private.  The 
pass-phrase is simply a (local) "shorthand" for the long binary string 
that constitutes the private key.  It would be a real burden to have to 
remember the hexadecimal representation of a 2048 bit key.
> 
> Perhaps I am confusing the issue, maybe pass-phrases are not a part of
> the PublicKeyAuthentication system.
> 
> I understand that the computers themselves send out their public keys
> automatically at the very start of any connection attempt, then they
> "listen" to see if the other computer automatically responds with an
> "approved" private key.

A simplified sequence is: the local machine sends a connection message 
encrypted with its private key.  The remote machine decrypts the message 
using the sender's public key (which it must have) and, if the decrypted 
result is legitimate, the remote machine responds with a message 
encrypted with _its_ private key.  The local machine decrypts that 
message using the remote machine's public key (which it must have).  If 
the result is legitimate, the connection is established and subsequent 
traffic is encrypted both ways with a private key cipher (much faster 
than the public key systems) using a key negotiated in the connection 
sequence.
> 
> I imagine that several weeks of intense Googling will clear up all
> these mysteries for me.
> 
> 
> Anyhow, when I  _think_  I have learned PublcKeyAuthentication, I would
> like to test my new found knowledge on an in-house network of two Macs
> connected to each other via an Ethernet cable. (no Internet connection)
> 
> Problem is, I don't think such an in-house system will work as a test,
> because somehow I got the impression that a dedicated SSH public server
> computer was a necessary part of any PublicKeyAuthentication system.

A server is _not_ required and, in fact, would introduce a possible 
point of failure in the system, opening the door for a man-in-the-middle 
attack.  To test the configurations, you just have to exchange the 
machines' public keys.  I use SSH tunnels on my local network, even 
though it's behind a firewall, just for the practice of "safe" 
networking.

-- 
Tom Stiller

PGP fingerprint =  5108 DDB2 9761 EDE5 E7E3 
                   7BDA 71ED 6496 99C0 C7CF
0
tomstiller (3053)
6/7/2005 11:54:46 AM
In article <tomstiller-82C1D3.07544607062005@comcast.dca.giganews.com>,
Tom Stiller <tomstiller@comcast.net> wrote:

> > If a cracker tried to ping a computer that was 'behind' the SSH system,
> > would the cracker be able to tell if TB2 was actively running on that
> > computer?
> 
> No.  The tunnel works by defining two ports, one local and the other for 
> the remote machine.  The remote machine listens in its port (e.g. 407) 
> and the local machine connects to its port (whatever you choose).  The 
> tunnel intercepts traffic directed to the local port, reroutes it over 
> the secure channel, and presents it to the specified port on the remote 
> machine.

Okay, that is excellent.  The cracker would then have no way of knowing
that a computer using Timbuktu was in the network.

That is what I want, to hide the fact that I am using Timbuktu.



> > I don't understand how pass-phrases enter into the picture.
> 
> Keys are generated in pairs, one public and one private.  The 
> pass-phrase is simply a (local) "shorthand" for the long binary string 
> that constitutes the private key.  It would be a real burden to have to 
> remember the hexadecimal representation of a 2048 bit key.

Okay, if I understand you correctly, here is a simple example:
(using fewer bits in the binary string, of course)

Pass Phrase is  "A BEE" is used to represent the following 39 bit
binary string that constitutes the private key:
(spaces added for clarity)

1000  0010  0100  0000  1000  0100  1000  1010  1000  101



A             B    E     E     <---Pass Phrase   "A BEE"
41  20  42  45  45    <---hexadecimal representation of "A BEE"


4120424545   <--- same hexadecimal without spaces, used to 
                                     represent the 39 bit private key,
                                     shown this time without spaces:

100000100100000010000100100010101000101



I assume, if all the above is correct, that I have to enter a Pass
Phrase of my choice  _before_  the public-key/private-key pair can be
created by the computer.   There are probably rules somewhere about how
to come up with good pass phrases, and what characters are acceptable
in a pass phrase, and how long a pass phrase should be.




> > I understand that the computers themselves send out their public keys
> > automatically at the very start of any connection attempt, then they
> > "listen" to see if the other computer automatically responds with an
> > "approved" private key.
> 
> A simplified sequence is: the local machine sends a connection message 
> encrypted with its private key.  The remote machine decrypts the
> message 
> using the sender's public key (which it must have) and, if the
> decrypted 
> result is legitimate, the remote machine responds with a message 
> encrypted with _its_ private key.  The local machine decrypts that 
> message using the remote machine's public key (which it must have).  If 
> the result is legitimate, the connection is established and subsequent 
> traffic is encrypted both ways with a private key cipher (much faster 
> than the public key systems) using a key negotiated in the connection 
> sequence.

Okay, I had it all bass ackwards, thanks for the clarification.


This certainly gives me a good running start in understanding the
subject of PublicKeyAuthentication, thanks.

Mark-
0
NoSpamDammit (843)
6/8/2005 8:35:25 AM
In article <080620050135489254%NoSpamDammit@invalid.com>,
 Mark Conrad <NoSpamDammit@invalid.com> wrote:

> In article <tomstiller-82C1D3.07544607062005@comcast.dca.giganews.com>,
> Tom Stiller <tomstiller@comcast.net> wrote:
> 
[snip]

> > Keys are generated in pairs, one public and one private.  The 
> > pass-phrase is simply a (local) "shorthand" for the long binary string 
> > that constitutes the private key.  It would be a real burden to have to 
> > remember the hexadecimal representation of a 2048 bit key.
> 
> Okay, if I understand you correctly, here is a simple example:
> (using fewer bits in the binary string, of course)
> 
> Pass Phrase is  "A BEE" is used to represent the following 39 bit
> binary string that constitutes the private key:
> (spaces added for clarity)
> 
> 1000  0010  0100  0000  1000  0100  1000  1010  1000  101
> 
> 
> 
> A             B    E     E     <---Pass Phrase   "A BEE"
> 41  20  42  45  45    <---hexadecimal representation of "A BEE"
> 
> 
> 4120424545   <--- same hexadecimal without spaces, used to 
>                                      represent the 39 bit private key,
>                                      shown this time without spaces:
> 
> 100000100100000010000100100010101000101
> 
> 
> 
> I assume, if all the above is correct, that I have to enter a Pass
> Phrase of my choice  _before_  the public-key/private-key pair can be
> created by the computer.   There are probably rules somewhere about how
> to come up with good pass phrases, and what characters are acceptable
> in a pass phrase, and how long a pass phrase should be.
> 
It's not incorrect; it just doesn't clarify anything.  The passphrase is 
chosen at key generation time and may be changed later.  See the man 
page for "ssh-keygen" for additional details.
> 
[snip]

-- 
Tom Stiller

PGP fingerprint =  5108 DDB2 9761 EDE5 E7E3 
                   7BDA 71ED 6496 99C0 C7CF
0
tomstiller (3053)
6/8/2005 11:13:54 AM
In article <tomstiller-816178.07135408062005@comcast.dca.giganews.com>,
Tom Stiller <tomstiller@comcast.net> wrote:

> > I assume, if all the above is correct, that I have to enter a Pass
> > Phrase of my choice  _before_  the public-key/private-key pair can be
> > created by the computer.   There are probably rules somewhere about how
> > to come up with good pass phrases, and what characters are acceptable
> > in a pass phrase, and how long a pass phrase should be.
> > 
> It's not incorrect; it just doesn't clarify anything.  The passphrase is 
> chosen at key generation time and may be changed later.  See the man 
> page for "ssh-keygen" for additional details.

Damn, if there is any possible way to misunderstand a subject, then I
will find it  :-(

Where I was going wrong was in thinking that any particular private key
is a direct slave of the pass phrase, that is incorrect.

In fact, many  _different_  pass phrases can be used to retrieve any
specific private key.

The pass phrase is merely like a password to help a user retrieve a 
_specific_  private key, when there are several private keys.

Except unlike a password, a pass phrase can be an easily remembered
phrase, like:

"Mares eat oats, and does eat oats, and little lambs eat ivy."

( "does", as pertaining to female deer)


How do I manage to get so screwed up when it comes to understanding a
subject.

Makes me glad I presented my example to you, so you could spot the
error in my thinking.



> See the man page for "ssh-keygen" for additional details.

That suggestion really helped me, thanks.

....except now I am  _really_  worried, because when I start to make
sense out of the man pages, there is no hope for me.

I might wind up on the bottom rung of the Unixy geek ladder, and that
is a fate I would not wish on a puppy dog.

Mark-
0
NoSpamDammit (843)
6/8/2005 7:19:38 PM
Reply: