SSH Key generation question
in [General Linux]
|
From: Keith Keller on 20 Jun 2010 23:38 On 2010-06-20, Todd <todd(a)invalid.com> wrote: > On 06/20/2010 01:49 PM, Maxwell Lol wrote: >> Todd<todd(a)invalid.com> writes: >> >>> I would have to point out that the workstation is the >>> one who initiate the network packet as state=new, not the >>> number cruncher. >> >> Wrong. > > Good luck with your firewall rules. If you're tunneling X11 through ssh, firewall rules are irrelevant, since everything goes through the already-initiated channel. --keith -- kkeller-usenet(a)wombat.san-francisco.ca.us (try just my userid to email me) AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt see X- headers for PGP signature information
From: Keith Keller on 21 Jun 2010 00:03 On 2010-06-20, Todd <todd(a)invalid.com> wrote: > > My beef still holds. The cruncher is still responding > to requests from the workstation, including setting > the DISPLAY variable and asking gkrellm to fire up and > send stuff to it. The cruncher was the first machine to send out an X11 request. Just because communication is bidirectional doesn't mean that where you're sitting happens to be the client. Here's what happens: the cruncher's *sshd* responds to the workstation's *ssh* client requests. When the workstation asks for a gkrellm from the cruncher, the cruncher then *initiates* an X11 request to the workstation's X11. Thus, the cruncher is the X11 client, and the workstation the X11 server. And, as John notes, someone sitting at the cruncher's keyboard could, with properly (perhaps insecurely) configured X11 configuration/auth files, request an X11 client be displayed on your workstation, with no previous communication from the workstation before. (It sounds like you may have done this with your xroach prank. BTW, there's no obvious reason it shouldn't run in CentOS--find the source code and compile it to try it!) > The naming should have been chosen based on the functional > outcome of the processes. Not the nitty gritty on one of > the processes. The functional outcome is not always obvious, so it's more consistent to call the listener the server and the initiator the client. (Of course, often with X11 the client and server are the same machine.) And this isn't the ''nitty gritty on one of the processes''--it is at the heart of any network communication![0] Practically any software that communicates over a network needs a listener and an initiator. So it makes perfect sense to use that as the criterion for naming one side the server and the other the client. > Also, vncserver does the same thing. Thankfully, they choose > to name things base on the functional outcome. The VNC people almost certainly used the same criterion as the X11 people when determining the client and server, since vncserver, like an X11 server, listens for requests from clients. (And I doubt they'd have any qualms about how the X11 folks decided to name their software components.) --keith [0] Not really, since some network protocols simply broadcast, and a peer-to-peer network could use UDP to blur the idea of a client-server communication. But in general most TCP-based protocols, and many UDP-based ones, work this way. -- kkeller-usenet(a)wombat.san-francisco.ca.us (try just my userid to email me) AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt see X- headers for PGP signature information
From: Keith Keller on 21 Jun 2010 00:20 On 2010-06-20, Kenny McCormack <gazelle(a)shell.xmission.com> wrote: > > You people are completely wrong in your thinking. Not in what you post, > mind you - we all understand how they defined and how that terminology > works "inside the box" - but you are wrong in acting like it is some > kind of moral failing to not lovingly embrace X's terminology. I.e., to > not realize that it is "backwards" vis a vie the rest of the world. I'm not sure I know anyone who's "lovingly embraced" X! Here's just one of the fortune entries which "lovingly embrace" X: %% X windows: Something you can be ashamed of. 30%% more entropy than the leading window system. The first fully modular software disaster. Rome was destroyed in a day. Warn your friends about it. Climbing to new depths. Sinking to new heights. An accident that couldn't wait to happen. Don't wait for the movie. Never use it after a big meal. Need we say less? Plumbing the depths of human incompetence. It'll make your day. Don't get frustrated without it. Power tools for power losers. A software disaster of Biblical proportions. Never had it. Never will. The software with no visible means of support. More than just a generation behind. Hindenburg. Titanic. Edsel. X windows. Ouch! If you have fortune installed, try fortune -m 'X windows' You may have to name the fortune database explicitly; on my Slackware 13.0 box it's in fortune2: fortune -m 'X windows' fortune2 The other fortunes are equally "loving". --keith -- kkeller-usenet(a)wombat.san-francisco.ca.us (try just my userid to email me) AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt see X- headers for PGP signature information
From: Todd on 21 Jun 2010 01:43 On 06/20/2010 09:03 PM, Keith Keller wrote: > And, as John notes, someone sitting at the cruncher's keyboard could, > with properly (perhaps insecurely) configured X11 configuration/auth > files, request an X11 client be displayed on your workstation, with no > previous communication from the workstation before. (It sounds like you > may have done this with your xroach prank. BTW, there's no obvious > reason it shouldn't run in CentOS--find the source code and compile it > to try it!) I tried installing the gnome version, but the RPM had too many broken dependencies. Probably a good thing anyway: I may have got my a-- fired for infesting some of my humor impaired customers. Hysterical, but not worth loosing a job over. > The VNC people almost certainly used the same criterion as the X11 > people when determining the client and server, since vncserver, like an > X11 server, listens for requests from clients. (And I doubt they'd have > any qualms about how the X11 folks decided to name their software > components.) You have a strong point. My point is that the outcome is the same, Terminal Services included. The naming conversions should also match. -T
From: TomB on 21 Jun 2010 05:49
On 2010-06-20, the following emerged from the brain of General Schvantzkoph: > On Sun, 20 Jun 2010 14:26:57 +0000, TomB wrote: > >> On 2010-06-20, the following emerged from the brain of J G Miller: >>> On Sat, 19 Jun 2010 22:31:36 -0700, Todd wrote: >>>> If I create his keys for him on my server >>> >>> You do NOT create the keys for him on your server. >>> >>> He creates his own keys on his own machine, and if it is running >>> Windoze, he uses puttygen which comes as part of the PuTTY >>> package. >> >> I never tried it myself, but I suppose one could also use the >> openssh package provided by cygwin to generate a keypair. > > Cygwin works fine for that purpose. You can pretty much do anything > that an ssh client can do on Linux, create a keypair, ssh into a > remote machine, do rsyncs, run CVS over ssh. Cygwin uses an > identical ~/.ssh directory and the identical ~/.ssh/config files. Thanks for confirming. I do use cygwin on my Windows servers for rsync and remote console access, but I never bothered to use it for key generation. -- BOFH excuse #224: Jan 9 16:41:27 huber su: 'su root' succeeded for .... on /dev/pts/1 |