Re: ssh
Francesco Pietra wrote: That's odd. I am able to get commands to work over SSH without a password. I copied the contents of ~/.ssh/id_rsa.pub on my work computer into ~/.ssh/authorized_keys on my home computer. Now I can SSH from my work computer to my home computer like this: ssh m...@myhomepc date And it logs into my home computer and then runs the date command. I did not have to do anything with the authorized_keys file on my work computer to make this happen. That's all appropriate. You only need to modify authorized_keys in both places if you want the symmetric relationship that either machine can log into the other. Correct. I mentioned that I did not have to alter the authorized_keys file on my work PC in response to the OP's statement: I know how to solve the issue, i.e. by cross appending the authorized_keys files, in order that each machine knows itself. But there must be a simpler way. I have no idea why you would need to do something like that. I have never had to cross-append anything in order to make this work. I just wanted to clarify for the OP that the keys only need to be shared in one direction to do this. He seems to indicate that the passwordless login works just fine unless he tries to run a command through the ssh command line. I don't know why that would make a difference. Big difference for me. As I said in my original post, certain computational parallelized codes (from major supercomputer centers, latest versions) do not work unless the two machines talking to one another also know themselves. Usually, the two machines are my desktop (let say deb32) and my parallel computer (let say deb64) talking to one another via a router.The only way I found (perhaps suggested by the author of the code, I don't remember) to login passwordless (my arrangement is also passfraseless) to the parallel computer - and vice versa - while requesting the date, is to take the deb32 keys from deb64 and append them to those of deb32 itself, and vice versa. I admit that most codes do not care about that, but it happens that I am using at this very moment a code that has such idiosyncrasy. When I said there must be a simpler way, I meant to make that appending intrinsic in the configuration of ssh. Otherwise, I have to stay to ssh if I want (as I need) also to access supercomputers. I am surprised that others are able to login while running a command by simply sending one-way the keys. As I am no system expert, I assume that I am not setting up correctly ssh. regards francesco Francesco, If I understand you correctly, you are trying to ssh from your PC running 32-bit Lenny to a node in a parallel computing cluster running 64-bit Lenny. Is this correct? I'm not sure why a simple one-way shared key would not work if you are trying to run a command on the parallel computer from your PC. You shouldn't need two-way authentication unless the parallel computer needs to run something on your machine using the same tunnel. But I might be misunderstanding how you have things set up. - Dave P.S. I sent this reply back to the lists so this conversation wouldn't go completely off-list, in case someone else is interested too. -- Dave Parker Utica College Integrated Information Technology Services (315) 792-3229 Registered Linux User #408177 -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ssh
Is any 'send file' command to make so that two machines (an amd64 multisocket and a simple i386, both lenny) talk scp with one another through a router (attached to adsl) fully without asking the password? With 'fully' I mean that command: ssh target_machine_name date gives the date without asking a password. The mere sending id_rsa.pub to create the authorized_keys file only works (without asking the password) for command: ssh target_machine_name but if 'date' is also requested, the password is needed (at least in my hands). I know how to solve the issue, i.e. by cross appending the authorized_keys files, in order that each machine knows itself. But there must be a simpler way. That's odd. I am able to get commands to work over SSH without a password. I copied the contents of ~/.ssh/id_rsa.pub on my work computer into ~/.ssh/authorized_keys on my home computer. Now I can SSH from my work computer to my home computer like this: ssh m...@myhomepc date And it logs into my home computer and then runs the date command. I did not have to do anything with the authorized_keys file on my work computer to make this happen. - Dave -- Dave Parker Utica College Integrated Information Technology Services (315) 792-3229 Registered Linux User #408177 -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ssh
Christopher Browne wrote: On Tue, Jan 20, 2009 at 11:06 AM, David A. Parker dpar...@utica.edu wrote: Is any 'send file' command to make so that two machines (an amd64 multisocket and a simple i386, both lenny) talk scp with one another through a router (attached to adsl) fully without asking the password? With 'fully' I mean that command: ssh target_machine_name date gives the date without asking a password. The mere sending id_rsa.pub to create the authorized_keys file only works (without asking the password) for command: ssh target_machine_name but if 'date' is also requested, the password is needed (at least in my hands). I know how to solve the issue, i.e. by cross appending the authorized_keys files, in order that each machine knows itself. But there must be a simpler way. That's odd. I am able to get commands to work over SSH without a password. I copied the contents of ~/.ssh/id_rsa.pub on my work computer into ~/.ssh/authorized_keys on my home computer. Now I can SSH from my work computer to my home computer like this: ssh m...@myhomepc date And it logs into my home computer and then runs the date command. I did not have to do anything with the authorized_keys file on my work computer to make this happen. That's all appropriate. You only need to modify authorized_keys in both places if you want the symmetric relationship that either machine can log into the other. Correct. I mentioned that I did not have to alter the authorized_keys file on my work PC in response to the OP's statement: I know how to solve the issue, i.e. by cross appending the authorized_keys files, in order that each machine knows itself. But there must be a simpler way. I have no idea why you would need to do something like that. I have never had to cross-append anything in order to make this work. I just wanted to clarify for the OP that the keys only need to be shared in one direction to do this. He seems to indicate that the passwordless login works just fine unless he tries to run a command through the ssh command line. I don't know why that would make a difference. He also mentioned scp, and I think the better alternative would be to run sftp with a batch file. - Dave -- Dave Parker Utica College Integrated Information Technology Services (315) 792-3229 Registered Linux User #408177 -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
KDE and Etch/Testing
Hello, Looking through the archives, there was recently a post about KDE not being available yet. Does anyone know if this has been fixed yet? I tried 'apt-get install kde' today and got the same result: The following packages have unmet dependencies. kdebase: Depends: kappfinder (= 4:3.5.2-2) but it is not going to be installed Depends: kate (= 4:3.5.2-2) but it is not going to be installed Depends: kcontrol (= 4:3.5.2-2) but it is not going to be installed Depends: kdebase-bin (= 4:3.5.2-2) but it is not going to be installed Depends: kdebase-kio-plugins (= 4:3.5.2-2) but it is not going to be installed Depends: kdepasswd (= 4:3.5.2-2) but it is not going to be installed Depends: kdeprint (= 4:3.5.2-2) but it is not going to be installed Depends: kdesktop (= 4:3.5.2-2) but it is not going to be installed Depends: kfind (= 4:3.5.2-2) but it is not going to be installed Depends: khelpcenter (= 4:3.5.2-2) but it is not going to be installed Depends: kicker (= 4:3.5.2-2) but it is not going to be installed Depends: klipper (= 4:3.5.2-2) but it is not going to be installed Depends: kmenuedit (= 4:3.5.2-2) but it is not going to be installed Depends: konqueror-nsplugins (= 4:3.5.2-2) but it is not going to be installed Depends: konqueror (= 4:3.5.2-2) but it is not going to be installed Depends: konsole (= 4:3.5.2-2) but it is not going to be installed Depends: kpager (= 4:3.5.2-2) but it is not going to be installed Depends: kpersonalizer (= 4:3.5.2-2) but it is not going to be installed Depends: ksmserver (= 4:3.5.2-2) but it is not going to be installed Depends: ksplash (= 4:3.5.2-2) but it is not going to be installed Depends: ksysguard (= 4:3.5.2-2) but it is not going to be installed Depends: ktip (= 4:3.5.2-2) but it is not going to be installed Depends: kwin (= 4:3.5.2-2) but it is not going to be installed Depends: libkonq4 (= 4:3.5.2-2) but it is not going to be installed E: Broken packages Thanks! Dave -- Dave Parker Utica College Department of Integrated Information Technology Services Data Processing Office (315) 792-3229 Registered Linux User #408177 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
