Re: passwordless SSH
On Thu 03 Jun 2021 at 17:23:43 (-0400), Frank Pikelner wrote: > It is much better to use SSH certificates, not a great deal of extra work, > but well worth it. Simplifies management and works well for automation. Thanks for the top-posted explanation. The references were useful too. > On Thu, Jun 3, 2021 at 5:15 PM David Wright> wrote: > > On Sat 29 May 2021 at 18:25:50 (-0400), Bob Weber wrote: > > > > > Now follow the instructions at: > > > > > > https://linuxize.com/post/how-to-setup-passwordless-ssh-login/ Cheers, David.
Re: passwordless SSH
It is much better to use SSH certificates, not a great deal of extra work, but well worth it. Simplifies management and works well for automation. Best, Frank On Thu, Jun 3, 2021 at 5:15 PM David Wright wrote: > On Sat 29 May 2021 at 18:25:50 (-0400), Bob Weber wrote: > > > Now follow the instructions at: > > > > https://linuxize.com/post/how-to-setup-passwordless-ssh-login/ > > > > You will need to follow those instructions for each linux server you > > want to backup. The .ssh directory will be under the directory listed > > in the passwd file (/var/lib/backuppc).? DO NOT USE A PASSWORD TO > > create the key pair files! They should go into the > > /var/lib/backuppc/.ssh directory (only do this ONCE!). In step 03. > > the username should be root@ip-address (you will need root access on > > that machine to backup all files from the backuppc user on the > > backuppc server). In step 04 you should be able to "ssh > > root@ip-address" without a password. > > I do this as a matter of course when I set up my machines … > > > THESE COMMANDS ARE RUN ON EACH SERVER TO BE BACKED UP. > > … (not the backuppc stuff, but just the passwordless login) … > > > If yyou can't "ssh root@ip-address" without a password you may also > need the line > > > > "PermitRootLogin yes" > > > > in the /etc/ssh/sshd_config file on each server to be backed up. > > I avoid this wrinkle with a trick that's especially simple when it's > done first thing after installation (but it's easy at any time). > > On machine A: > > # ssh-copy-id -i ~/.ssh/id_rsa.pub @hostB > > where the sysadminuser¹ is as yet unconfigured for passwordless > login by ssh. On machine B, as sysadminuser: > > $ /bin/su - > # mv -i /home//.ssh/authorized_keys /root/.ssh/ > # chown 0.0 /root/.ssh/authorized_keys > > If sysadminuser already had some keys in authorized_keys, > then root will need to edit the key from the last line of > /home//.ssh/authorized_keys rather than just > moving the file (and make sure you don't leave behind a > backup in /home//.ssh/authorized_keys~). > > Alternatively, you can move sysadminuser's authorized_keys > out of the way while you type the lines shown above, and then > move it back. (Stay logged in to sysadminuser while you do this.) > > > If you want to you can follow the instructions at "Disabling SSH > > Password Authentication". Be very careful to follow the instructions > > closely. These are not needed to get backuppc running! You will need > > to be able to sudo into root from an unprivileged user to get root > > access so be VERY careful to follow the instructions. > > ¹ I'm assuming root and sysadminuser are the same person, and others > don't (yet) have access to the machine. > > Cheers, > David. > >
Re: passwordless SSH
On Sat 29 May 2021 at 18:25:50 (-0400), Bob Weber wrote: > Now follow the instructions at: > > https://linuxize.com/post/how-to-setup-passwordless-ssh-login/ > > You will need to follow those instructions for each linux server you > want to backup. The .ssh directory will be under the directory listed > in the passwd file (/var/lib/backuppc).? DO NOT USE A PASSWORD TO > create the key pair files! They should go into the > /var/lib/backuppc/.ssh directory (only do this ONCE!). In step 03. > the username should be root@ip-address (you will need root access on > that machine to backup all files from the backuppc user on the > backuppc server). In step 04 you should be able to "ssh > root@ip-address" without a password. I do this as a matter of course when I set up my machines … > THESE COMMANDS ARE RUN ON EACH SERVER TO BE BACKED UP. … (not the backuppc stuff, but just the passwordless login) … > If yyou can't "ssh root@ip-address" without a password you may also need the > line > > "PermitRootLogin yes" > > in the /etc/ssh/sshd_config file on each server to be backed up. I avoid this wrinkle with a trick that's especially simple when it's done first thing after installation (but it's easy at any time). On machine A: # ssh-copy-id -i ~/.ssh/id_rsa.pub @hostB where the sysadminuser¹ is as yet unconfigured for passwordless login by ssh. On machine B, as sysadminuser: $ /bin/su - # mv -i /home//.ssh/authorized_keys /root/.ssh/ # chown 0.0 /root/.ssh/authorized_keys If sysadminuser already had some keys in authorized_keys, then root will need to edit the key from the last line of /home//.ssh/authorized_keys rather than just moving the file (and make sure you don't leave behind a backup in /home//.ssh/authorized_keys~). Alternatively, you can move sysadminuser's authorized_keys out of the way while you type the lines shown above, and then move it back. (Stay logged in to sysadminuser while you do this.) > If you want to you can follow the instructions at "Disabling SSH > Password Authentication". Be very careful to follow the instructions > closely. These are not needed to get backuppc running! You will need > to be able to sudo into root from an unprivileged user to get root > access so be VERY careful to follow the instructions. ¹ I'm assuming root and sysadminuser are the same person, and others don't (yet) have access to the machine. Cheers, David.
Re: passwordless SSH
On 5/29/21 16:12, Gary L. Roach wrote: Operating System: Debian GNU/Linux 10 KDE Plasma Version: 5.14.5 Qt Version: 5.11.3 KDE Frameworks Version: 5.54.0 Kernel Version: 4.19.0-16-amd64 OS Type: 64-bit Processors: 4 à AMD FX(tm)-4350 Quad-Core Processor Memory: 15.6 GiB of RAM I have been trying to setup passwordless SSH for a Backuppc system. I have three Debian 10 systems (including the server) . SSH sets up fine on one of the client machine and "ssh backu...@192.168.254.xx starts without asking for a password. The other machine (supposedly identical) not only asks for a password but will not accept any of the known passwords. If I go to the offending machine and attempt to su to the backuppc user , I am asked for a password and no passwords work. This doesn't allow the use of ssh-copy-id for transfering the encryption key to that machine. I have tried to reset the backuppc password three times but did not solve the problem. In both systems the public key is stored in /var/lib/backuppc/.ssh as id_rsa.pub. I also have a Windoz 7 laptop that I want to include and have managed to get ssh and rsync installed (what a mess that was). I have not tried to get passwordless access to that yet. For later. Any insights? Gary R. The servers that are being backed up do not have a backuppc user. They need to have root access to access all the files you may need to backup. These commands will get the proper root access on each server being backed up from the backuppc server and backuppc user. You didn't say whether the working password less ssh was working on the host (backuppc machine) or not. So I will give you general instructions here. Some commands will need root access on the backuppc server to run. THESE COMMANDS WILL BE RUN ON THE BACKUPPC SERVER FOR EACH MACHINE TO BACKUP. First make sure you can login to the backuppc user. Look at your passwd file in /etc. It will have an entry for backuppc ... it should have a user home directory and user command interpreter listed. Look at your own entry to see how the entries are formatted or look at "man 5 passwd". The directory should be the backuppc base directory /var/lib/backuppc and command interpreter /bin/bash. Create a password for the backuppc user (as root) with "passwd backuppc". Now login to the backuppc user with that password (or just "su - backuppc" from root). Now follow the instructions at: https://linuxize.com/post/how-to-setup-passwordless-ssh-login/ You will need to follow those instructions for each linux server you want to backup. The .ssh directory will be under the directory listed in the passwd file (/var/lib/backuppc). DO NOT USE A PASSWORD TO create the key pair files! They should go into the /var/lib/backuppc/.ssh directory (only do this ONCE!). In step 03. the username should be root@ip-address (you will need root access on that machine to backup all files from the backuppc user on the backuppc server). In step 04 you should be able to "ssh root@ip-address" without a password. THESE COMMANDS ARE RUN ON EACH SERVER TO BE BACKED UP. If yyou can't "ssh root@ip-address" without a password you may also need the line "PermitRootLogin yes" in the /etc/ssh/sshd_config file on each server to be backed up. If you want to you can follow the instructions at "Disabling SSH Password Authentication". Be very careful to follow the instructions closely. These are not needed to get backuppc running! You will need to be able to sudo into root from an unprivileged user to get root access so be VERY careful to follow the instructions. ...Bob
Re: passwordless SSH
On 2021-05-29 21:12, Gary L. Roach wrote: Operating System: Debian GNU/Linux 10 KDE Plasma Version: 5.14.5 Qt Version: 5.11.3 KDE Frameworks Version: 5.54.0 Kernel Version: 4.19.0-16-amd64 OS Type: 64-bit Processors: 4 × AMD FX(tm)-4350 Quad-Core Processor Memory: 15.6 GiB of RAM I have been trying to setup passwordless SSH for a Backuppc system. I have three Debian 10 systems (including the server) . SSH sets up fine on one of the client machine and "ssh backu...@192.168.254.xx starts without asking for a password. The other machine (supposedly identical) not only asks for a password but will not accept any of the known passwords. If I go to the offending machine and attempt to su to the backuppc user , I am asked for a password and no passwords work. This doesn't allow the use of ssh-copy-id for transfering the encryption key to that machine. I have tried to reset the backuppc password three times but did not solve the problem. In both systems the public key is stored in /var/lib/backuppc/.ssh as id_rsa.pub. I also have a Windoz 7 laptop that I want to include and have managed to get ssh and rsync installed (what a mess that was). I have not tried to get passwordless access to that yet. For later. Any insights? Gary R. You want to make keys without a passphrase and copy the public key to user at otherpc's .authorized_keys mick -- Key ID4BFEBB31
passwordless SSH
Operating System: Debian GNU/Linux 10 KDE Plasma Version: 5.14.5 Qt Version: 5.11.3 KDE Frameworks Version: 5.54.0 Kernel Version: 4.19.0-16-amd64 OS Type: 64-bit Processors: 4 × AMD FX(tm)-4350 Quad-Core Processor Memory: 15.6 GiB of RAM I have been trying to setup passwordless SSH for a Backuppc system. I have three Debian 10 systems (including the server) . SSH sets up fine on one of the client machine and "ssh backu...@192.168.254.xx starts without asking for a password. The other machine (supposedly identical) not only asks for a password but will not accept any of the known passwords. If I go to the offending machine and attempt to su to the backuppc user , I am asked for a password and no passwords work. This doesn't allow the use of ssh-copy-id for transfering the encryption key to that machine. I have tried to reset the backuppc password three times but did not solve the problem. In both systems the public key is stored in /var/lib/backuppc/.ssh as id_rsa.pub. I also have a Windoz 7 laptop that I want to include and have managed to get ssh and rsync installed (what a mess that was). I have not tried to get passwordless access to that yet. For later. Any insights? Gary R.
Re: passwordless ssh root logins stopped working after testing dist-upgrade
Hello Russel, I am suspecting an issue on the server side. Can you provide a verbose log of the server side, Regards, Franklin On Tue, 2010-04-06 at 20:00 -0700, Russell L. Carter wrote: On my main system I have two user accounts, 'rcarter' and 'sardine'. I remove the .ssh directories from 'rcarter', 'sardine', and 'root'. I create a new rsa key for rcarter (creates ~rcarter/.ssh) and then ssh-copy-id -i the new key to sard...@localhost and r...@localhost, which creates a new .ssh directory with authorized_keys for each. Then I ssh-add the new key to the agent as rcarter. 1. $ ssh sard...@localhost logs in w/o password 2. $ ssh r...@localhost asks for password This is reproducible on two 'testing' systems that have worked flawlessly for at least two years each, but were both dist-upgraded yesterday, and they now exhibit this same behavior. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1270897313.3786.878.ca...@solid.paris.klabs.be
Re: passwordless ssh root logins stopped working after testing dist-upgrade
On 10-04-06 16:06:14, d.sastre.med...@gmail.com wrote: On Tue, Apr 06, 2010 at 03:24:04PM -0400, Tony Nelson wrote: On 10-04-06 14:12:19, Russell L. Carter wrote: r...@feyerabend diff -u ssh_config ssh_config.dpkg-dist --- ssh_config 2010-04-05 21:14:26.172871668 -0700 +++ ssh_config.dpkg-dist2010-01-04 09:05:12.0 -0700 @@ -17,8 +17,8 @@ # ssh_config(5) man page. Host * -ForwardAgent yes -ForwardX11 yes +# ForwardAgent no +# ForwardX11 no # ForwardX11Trusted yes # RhostsRSAAuthentication no # RSAAuthentication yes I don't see any PermitRootLogin without-password line in your diff. Hello, That would disable password login for root, but does not enable per- se pubkey auth (AFAIK). man sshd_config explain this: PermitRootLogin, PubkeyAuthentication and AuthorizedKeysFile entries. Oops, yes, sorry. -- TonyN.:' mailto:tonynel...@georgeanelson.com ' http://www.georgeanelson.com/ -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/127031.66...@localhost.localdomain
passwordless ssh root logins stopped working after testing dist-upgrade
I dist-upgraded yesterday and ssh root logins started requiring a password. I also tweaked some other stuff and installed calibre and miro to check them out and they came with a boatload of dependencies so maybe there's something lurking there. Regular user ssh logins work just fine. I decided that it would be a good time to update my keys and redid everything very carefully from scratch. VERY CAREFULLY checked .ssh and authorized_keys permissions, etc. No change. This affects both user-r...@localhost ssh logins and to remote hosts. It smells like an ssh-agent problem, but then why would regular user ssh logins continue to work? Tia for any clues. I won't be surprised if I did something dumb... I've got a stock /etc/ssh/sshd_config and very long time modified ssh_config: r...@feyerabend diff -u ssh_config ssh_config.dpkg-dist --- ssh_config 2010-04-05 21:14:26.172871668 -0700 +++ ssh_config.dpkg-dist2010-01-04 09:05:12.0 -0700 @@ -17,8 +17,8 @@ # ssh_config(5) man page. Host * -ForwardAgent yes -ForwardX11 yes +# ForwardAgent no +# ForwardX11 no # ForwardX11Trusted yes # RhostsRSAAuthentication no # RSAAuthentication yes -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bbb7983.2010...@pinyon.org
Re: passwordless ssh root logins stopped working after testing dist-upgrade
On Tue, Apr 06, 2010 at 11:12:19AM -0700, Russell L. Carter wrote: VERY CAREFULLY checked .ssh and authorized_keys permissions, etc. No change. This affects both user-r...@localhost ssh logins Hello, Could you try to add a new user in the box you want to log in, and create a ~/.ssh/authorized_keys with your ~/.ssh/id_dsa.pub and see what happens. A ssh -vvv output would be fine too. Remember to chmod 600 authorized_keys file and chmod 700 .ssh directory (probably less restrictive also work, but this JWFFM). Regards. -- Huella de clave = 943C D77F 0CB0 02FE 166E E06F D13A A2E1 98A5 C953 pgpvMuKPj9i9M.pgp Description: PGP signature
Re: passwordless ssh root logins stopped working after testing dist-upgrade
On 10-04-06 14:12:19, Russell L. Carter wrote: I dist-upgraded yesterday and ssh root logins started requiring a password. ... ... r...@feyerabend diff -u ssh_config ssh_config.dpkg-dist --- ssh_config 2010-04-05 21:14:26.172871668 -0700 +++ ssh_config.dpkg-dist2010-01-04 09:05:12.0 -0700 @@ -17,8 +17,8 @@ # ssh_config(5) man page. Host * -ForwardAgent yes -ForwardX11 yes +# ForwardAgent no +# ForwardX11 no # ForwardX11Trusted yes # RhostsRSAAuthentication no # RSAAuthentication yes I don't see any PermitRootLogin without-password line in your diff. -- TonyN.:' mailto:tonynel...@georgeanelson.com ' http://www.georgeanelson.com/ -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1270581844.2448...@localhost.localdomain
Re: passwordless ssh root logins stopped working after testing dist-upgrade
On Tue, Apr 06, 2010 at 03:24:04PM -0400, Tony Nelson wrote: On 10-04-06 14:12:19, Russell L. Carter wrote: r...@feyerabend diff -u ssh_config ssh_config.dpkg-dist --- ssh_config 2010-04-05 21:14:26.172871668 -0700 +++ ssh_config.dpkg-dist2010-01-04 09:05:12.0 -0700 @@ -17,8 +17,8 @@ # ssh_config(5) man page. Host * -ForwardAgent yes -ForwardX11 yes +# ForwardAgent no +# ForwardX11 no # ForwardX11Trusted yes # RhostsRSAAuthentication no # RSAAuthentication yes I don't see any PermitRootLogin without-password line in your diff. Hello, That would disable password login for root, but does not enable per-se pubkey auth (AFAIK). man sshd_config explain this: PermitRootLogin, PubkeyAuthentication and AuthorizedKeysFile entries. Regards. -- Huella de clave = 943C D77F 0CB0 02FE 166E E06F D13A A2E1 98A5 C953 pgp7kWyK2Ko2u.pgp Description: PGP signature
Re: passwordless ssh root logins stopped working after testing dist-upgrade
Run this command as the user you would like to login with via ssh and send back the results: ssh - hostname Ryan Manikowski ]] Devision Media Services LLC [[ www.devision.us r...@devision.us | 716.771.2282 On 4/6/2010 4:06 PM, d.sastre.med...@gmail.com wrote: On Tue, Apr 06, 2010 at 03:24:04PM -0400, Tony Nelson wrote: On 10-04-06 14:12:19, Russell L. Carter wrote: r...@feyerabend diff -u ssh_config ssh_config.dpkg-dist --- ssh_config 2010-04-05 21:14:26.172871668 -0700 +++ ssh_config.dpkg-dist2010-01-04 09:05:12.0 -0700 @@ -17,8 +17,8 @@ # ssh_config(5) man page. Host * -ForwardAgent yes -ForwardX11 yes +# ForwardAgent no +# ForwardX11 no # ForwardX11Trusted yes # RhostsRSAAuthentication no # RSAAuthentication yes I don't see any PermitRootLogin without-password line in your diff. Hello, That would disable password login for root, but does not enable per-se pubkey auth (AFAIK). man sshd_config explain this: PermitRootLogin, PubkeyAuthentication and AuthorizedKeysFile entries. Regards. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bbb95ea.8010...@devision.us
Re: passwordless ssh root logins stopped working after testing dist-upgrade
On Tue, 6 Apr 2010 14:12:19 -0400 (EDT), Russell L. Carter wrote: I dist-upgraded yesterday and ssh root logins started requiring a password. OK, I'll bite. Not that this is any of my business, but why do you allow *root* logins via *ssh* _without_ a password. Isn't that dangerous? At my shop, our policy is that root is not allowed to login via ssh at all. root can only login from the system console. To login as root via ssh, one must login as a normal user first, then su to root. But you not only allow root to login via ssh, you don't even require a password! That sounds like a security hole big enough to drive a tank through! Would you mind explaining why you do this? -- .''`. Stephen Powellzlinux...@wowway.com : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1646579125.1476531270584888497.javamail.r...@md01.wow.synacor.com
Re: passwordless ssh root logins stopped working after testing dist-upgrade
On Tue, Apr 6, 2010 at 4:14 PM, Stephen Powell zlinux...@wowway.com wrote: On Tue, 6 Apr 2010 14:12:19 -0400 (EDT), Russell L. Carter wrote: I dist-upgraded yesterday and ssh root logins started requiring a password. OK, I'll bite. Not that this is any of my business, but why do you allow *root* logins via *ssh* _without_ a password. Isn't that dangerous? At my shop, our policy is that root is not allowed to login via ssh at all. root can only login from the system console. To login as root via ssh, one must login as a normal user first, then su to root. But you not only allow root to login via ssh, you don't even require a password! That sounds like a security hole big enough to drive a tank through! Would you mind explaining why you do this? -- What the PermitRootLogin without-password actually does is restrict root login to key authentication only. This (imo), is more secure than the default configuration as public keys are much more difficult to bruteforce than passwords. Also, your typical botnet (based on my own experiences/logs) is usually attempting to brute-force passwords. Also, you can add a passphrase to your public key so that it requires both a key and password. This also works with without-password but will create issues when you have scripts that need to be able to authenticate non-interactively. The sshd_config manpage does not do a very good job of explaining this. Hope that clears up some confusion Stephen. -- Jordan Metzmeier -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/k2w50e5edd51004061323sd611d044oe3ea02d3dfb03...@mail.gmail.com
Re: passwordless ssh root logins stopped working after testing dist-upgrade
First, I'm new to this list and how do you all want me to handle replies? Rather than the two individuals that show up with reply-all, I've just replied directly to the list. If that's not what you want, please let me know. Ryan Manikowski wrote: Run this command as the user you would like to login with via ssh and send back the results: ssh - hostname Thanks Ryan... In this session I've ssh-added my regular key (rsa), and then ssh-copy-id'ed it as follows. I've tried both rsa and dsa keys, appended is the debug output with an rsa key. I also just verified that I can ssh without a password into a new ordinary user account (after ssh-copy-id). rcar...@feyerabend ssh-copy-id r...@localhost r...@localhost's password: Now try logging into the machine, with ssh 'r...@localhost', and check in: .ssh/authorized_keys to make sure we haven't added extra keys that you weren't expecting. rcar...@feyerabend ssh r...@localhost r...@localhost's password: rcar...@feyerabend ssh - r...@localhost OpenSSH_5.3p1 Debian-3, OpenSSL 0.9.8n 24 Mar 2010 debug1: Reading configuration data /home/rcarter/.ssh/config debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug2: ssh_connect: needpriv 0 debug1: Connecting to localhost [::1] port 22. debug1: Connection established. debug1: identity file /home/rcarter/.ssh/identity type -1 debug3: Not a RSA1 key file /home/rcarter/.ssh/id_rsa. debug2: key_type_from_name: unknown key type '-BEGIN' debug3: key_read: missing keytype debug2: key_type_from_name: unknown key type 'Proc-Type:' debug3: key_read: missing keytype debug2: key_type_from_name: unknown key type 'DEK-Info:' debug3: key_read: missing keytype debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug2: key_type_from_name: unknown key type '-END' debug3: key_read: missing keytype debug1: identity file /home/rcarter/.ssh/id_rsa type 1 debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048 debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048 debug1: identity file /home/rcarter/.ssh/id_dsa type -1 debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3p1 Debian-3 debug1: match: OpenSSH_5.3p1 Debian-3 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_5.3p1 Debian-3 debug2: fd 3 setting O_NONBLOCK debug1: SSH2_MSG_KEXINIT sent debug3: Wrote 792 bytes for a total of 824 debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-...@lysator.liu.se debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-...@lysator.liu.se debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac...@openssh.com,hmac-ripemd160,hmac-ripemd...@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac...@openssh.com,hmac-ripemd160,hmac-ripemd...@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,z...@openssh.com,zlib debug2: kex_parse_kexinit: none,z...@openssh.com,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-...@lysator.liu.se debug2: kex_parse_kexinit:
Re: passwordless ssh root logins stopped working after testing dist-upgrade
On Tue, 6 Apr 2010 16:23:35 -0400 (EDT), Jordan Metzmeier wrote: On Tue, Apr 6, 2010 at 4:14 PM, Stephen Powell wrote: On Tue, 6 Apr 2010 14:12:19 -0400 (EDT), Russell L. Carter wrote: I dist-upgraded yesterday and ssh root logins started requiring a password. OK, I'll bite. Not that this is any of my business, but why do you allow *root* logins via *ssh* _without_ a password. Isn't that dangerous? At my shop, our policy is that root is not allowed to login via ssh at all. root can only login from the system console. To login as root via ssh, one must login as a normal user first, then su to root. But you not only allow root to login via ssh, you don't even require a password! That sounds like a security hole big enough to drive a tank through! Would you mind explaining why you do this? What the PermitRootLogin without-password actually does is restrict root login to key authentication only. This (imo), is more secure than the default configuration as public keys are much more difficult to bruteforce than passwords. Also, your typical botnet (based on my own experiences/logs) is usually attempting to brute-force passwords. Also, you can add a passphrase to your public key so that it requires both a key and password. This also works with without-password but will create issues when you have scripts that need to be able to authenticate non-interactively. The sshd_config manpage does not do a very good job of explaining this. Hope that clears up some confusion Stephen. So the idea is that both the server *and* the client authenticate to each other via SSL? (I.e. both server and client have a public key / private key pair?) And only someone in possession of the client's private key would be able to authenticate to the server? Is that basically what you're saying? -- .''`. Stephen Powellzlinux...@wowway.com : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1848932970.1488811270587743225.javamail.r...@md01.wow.synacor.com
Re: passwordless ssh root logins stopped working after testing dist-upgrade
On 4/6/2010 4:37 PM, Russell L. Carter wrote: First, I'm new to this list and how do you all want me to handle replies? Rather than the two individuals that show up with reply-all, I've just replied directly to the list. If that's not what you want, please let me know. Ryan Manikowski wrote: Run this command as the user you would like to login with via ssh and send back the results: ssh - hostname Thanks Ryan... In this session I've ssh-added my regular key (rsa), and then ssh-copy-id'ed it as follows. I've tried both rsa and dsa keys, appended is the debug output with an rsa key. I also just verified that I can ssh without a password into a new ordinary user account (after ssh-copy-id). rcar...@feyerabend ssh-copy-id r...@localhost r...@localhost's password: Now try logging into the machine, with ssh 'r...@localhost', and check in: .ssh/authorized_keys to make sure we haven't added extra keys that you weren't expecting. rcar...@feyerabend ssh r...@localhost r...@localhost's password: rcar...@feyerabend ssh - r...@localhost OpenSSH_5.3p1 Debian-3, OpenSSL 0.9.8n 24 Mar 2010 debug1: Reading configuration data /home/rcarter/.ssh/config debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug2: ssh_connect: needpriv 0 debug1: Connecting to localhost [::1] port 22. debug1: Connection established. debug1: identity file /home/rcarter/.ssh/identity type -1 debug3: Not a RSA1 key file /home/rcarter/.ssh/id_rsa. debug2: key_type_from_name: unknown key type '-BEGIN' debug3: key_read: missing keytype debug2: key_type_from_name: unknown key type 'Proc-Type:' debug3: key_read: missing keytype debug2: key_type_from_name: unknown key type 'DEK-Info:' debug3: key_read: missing keytype debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug2: key_type_from_name: unknown key type '-END' debug3: key_read: missing keytype debug1: identity file /home/rcarter/.ssh/id_rsa type 1 debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048 debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048 debug1: identity file /home/rcarter/.ssh/id_dsa type -1 debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3p1 Debian-3 debug1: match: OpenSSH_5.3p1 Debian-3 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_5.3p1 Debian-3 debug2: fd 3 setting O_NONBLOCK debug1: SSH2_MSG_KEXINIT sent debug3: Wrote 792 bytes for a total of 824 debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-...@lysator.liu.se debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-...@lysator.liu.se debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac...@openssh.com,hmac-ripemd160,hmac-ripemd...@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac...@openssh.com,hmac-ripemd160,hmac-ripemd...@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,z...@openssh.com,zlib debug2: kex_parse_kexinit: none,z...@openssh.com,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-...@lysator.liu.se debug2: kex_parse_kexinit:
Re: passwordless ssh root logins stopped working after testing dist-upgrade
Ryan Manikowski wrote: On 4/6/2010 4:37 PM, Russell L. Carter wrote: What you're trying to do here is login to the 'root' account using your non-root account to initiate the ssh connection. It is reading the 'id_rsa.pub' pubkey file from /home/user/.ssh/ and this is why it is failing. The non-root account on the remote side (in this case, your localhost) does not have access to ANY files in /root/ so it will never work. Ryan Manikowski Ok, if that is the correct explanation, why does ssh to another regular user account work? Why does ssh root@some_other_older_system just work? I just performed the following steps: On my main system I have two user accounts, 'rcarter' and 'sardine'. I remove the .ssh directories from 'rcarter', 'sardine', and 'root'. I create a new rsa key for rcarter (creates ~rcarter/.ssh) and then ssh-copy-id -i the new key to sard...@localhost and r...@localhost, which creates a new .ssh directory with authorized_keys for each. Then I ssh-add the new key to the agent as rcarter. 1. $ ssh sard...@localhost logs in w/o password 2. $ ssh r...@localhost asks for password This is reproducible on two 'testing' systems that have worked flawlessly for at least two years each, but were both dist-upgraded yesterday, and they now exhibit this same behavior. HOWEVER! I ssh-copy-id the new key created by rcarter to root on two systems that I haven't dist-upgraded in several weeks and then ssh root@systemname works fine, as it always has. I diffed the ssh_config and sshd_configs and the only difference were comments. So the problem would seem to be in sshd. transcript: (I removed root and sardine's .ssh dirs before) rcar...@feyerabend pwd /home/rcarter/.ssh rcar...@feyerabend cd .. rcar...@feyerabend mv .ssh dot.ssh rcar...@feyerabend ssh-keygen Generating public/private rsa key pair. Enter file in which to save the key (/home/rcarter/.ssh/id_rsa): Created directory '/home/rcarter/.ssh'. Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/rcarter/.ssh/id_rsa. Your public key has been saved in /home/rcarter/.ssh/id_rsa.pub. The key fingerprint is: 54:06:d2:08:a4:6d:26:9e:e0:0f:01:1a:1f:67:ff:91 rcar...@feyerabend The key's randomart image is: +--[ RSA 2048]+ |o ..=..o..o | |oo * + | |o.+ + . E| |.o.= o . | | oo S| | o | | . | | | | | +-+ rcar...@feyerabend ssh-copy-id -i sard...@localhost sard...@localhost's password: Now try logging into the machine, with ssh 'sard...@localhost', and check in: .ssh/authorized_keys to make sure we haven't added extra keys that you weren't expecting. rcar...@feyerabend ssh-copy-id -i r...@localhost r...@localhost's password: Now try logging into the machine, with ssh 'r...@localhost', and check in: .ssh/authorized_keys to make sure we haven't added extra keys that you weren't expecting. rcar...@feyerabend slogin sard...@localhost Enter passphrase for key '/home/rcarter/.ssh/id_rsa': rcar...@feyerabend ssh-add Enter passphrase for /home/rcarter/.ssh/id_rsa: Identity added: /home/rcarter/.ssh/id_rsa (/home/rcarter/.ssh/id_rsa) rcar...@feyerabend slogin sard...@localhost Linux feyerabend 2.6.32-3-amd64 #1 SMP Wed Feb 24 18:07:42 UTC 2010 x86_64 The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. Last login: Tue Apr 6 16:36:06 2010 from localhost sard...@feyerabend exit logout Connection to localhost closed. rcar...@feyerabend slogin r...@localhost r...@localhost's password: rcar...@feyerabend ]] Devision Media Services LLC [[ www.devision.us r...@devision.us | 716.771.2282 Ryan Manikowski ]] Devision Media Services LLC [[ www.devision.us r...@devision.us | 716.771.2282 On 4/6/2010 4:06 PM, d.sastre.med...@gmail.com wrote: On Tue, Apr 06, 2010 at 03:24:04PM -0400, Tony Nelson wrote: On 10-04-06 14:12:19, Russell L. Carter wrote: r...@feyerabend diff -u ssh_config ssh_config.dpkg-dist --- ssh_config 2010-04-05 21:14:26.172871668 -0700 +++ ssh_config.dpkg-dist2010-01-04 09:05:12.0 -0700 @@ -17,8 +17,8 @@ # ssh_config(5) man page. Host * -ForwardAgent yes -ForwardX11 yes +# ForwardAgent no +# ForwardX11 no # ForwardX11Trusted yes # RhostsRSAAuthentication no # RSAAuthentication yes I don't see any PermitRootLogin without-password line in your diff. Hello, That would disable password login for root, but does not enable per-se pubkey auth (AFAIK). man sshd_config explain this: PermitRootLogin, PubkeyAuthentication and AuthorizedKeysFile entries. Regards. -- To UNSUBSCRIBE, email to
passwordless ssh
Other alternatives (that doesn't work as well over internet) - and only if there is a limited number of programs that you need access to would be to use snmp or inetd. SNMP: Set up a own oid to return the values you are asking for. Inetd/Xinetd: telnet to a specific port - will start a program on the master that returns some output. But if we are talking about a arbitrary program - and especially over the internet - ssh with exchanged keys are preferable. If you find any of the above alternatives attractive - please let me know and I can give you some examples. Johan Elmerfjord Manager, Unix Systems Administration EMEA Omniture -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Passwordless SSH setup
On Wed, Jun 02, 2004 at 12:42:38AM -0500, Will Trillich wrote: /usr/bin/rsync \ -vaz\ -e /usr/bin/ssh \ --delete\ /home/office/ \ 10.1.1.5:/home/shared/ this assumes passwordless ssh connections are already set up, of course. (ssh-agent, ssh-keygen, which see.) okay, that was a bit terse... for passwordless SSH-ing, try this (and feel free to augment or correct if i overlook something)-- localbox$ ssh-keygen -t dsa after some qa (just answer with blanks, for passwordless connections) this creates a ~/.ssh/id_dsa.pub file that you can append to your remote systems' ~/.ssh/authorized_keys files: localbox$ scp ~/.ssh/id_dsa.pub [EMAIL PROTECTED]:~/.ssh/localboxKey localbox$ ssh [EMAIL PROTECTED] password remotebox$ cd ~/.ssh remotebox$ cat localboxKey authorized_keys remotebox$ chmod 600 authorized_keys remotebox$ rm localboxKey remotebox$ logout localbox$ poof! localbox$ ssh [EMAIL PROTECTED] no password needed! remotebox$ now you're all set for passwordless login! -- I use Debian/GNU Linux version 3.0; Linux boss 2.4.18-bf2.4 #1 Son Apr 14 09:53:28 CEST 2002 i586 unknown DEBIAN NEWBIE TIP #18 from Will Trillich [EMAIL PROTECTED] : How do you DISABLE A NETWORK SERVICE? There are several ways network services are made available: for inetd items, modify /etc/inetd.conf and then /etc/init.d/inetd restart. For independently-running daemons, try /etc/init.d/daemon stop (or to permanently zap them, apt-get --purge remove daemon). Also see http://newbieDoc.sourceForge.net/ ... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Passwordless SSH setup
On Wed, Jun 02, 2004 at 01:02:08AM -0500, Will Trillich wrote: for passwordless SSH-ing, try this (and feel free to augment or correct if i overlook something)-- localbox$ ssh-keygen -t dsa after some qa (just answer with blanks, for passwordless connections) this creates a ~/.ssh/id_dsa.pub file that you can append to your remote systems' ~/.ssh/authorized_keys files: localbox$ scp ~/.ssh/id_dsa.pub [EMAIL PROTECTED]:~/.ssh/localboxKey localbox$ ssh [EMAIL PROTECTED] password remotebox$ cd ~/.ssh remotebox$ cat localboxKey authorized_keys remotebox$ chmod 600 authorized_keys remotebox$ rm localboxKey remotebox$ logout localbox$ For password-less keys I think they should be single use only. My original question was about doing this to a machine running SSH Corp's version. Unfortunately, that machine has SSH Secure Shell 3.2.3 on it -- and in that version the manual pages were not updated to explain how to create a single use key. I emailed their tech support and they sent me to http://www.ssh.com/documents/32/ssh2_40.html which explains the options. And in case anyone finds this in the archive, on SSH Secure Shell you need to convert the keys. So on Debian, create a keypair called rsync and rsync.pub $ ssh-keygen -t dsa -f rsync Then convert and copy to the other machine: $ ssh-keygen -e -f rsync.pub | ssh remotehost 'cat - .ssh2/rsync.pub' and in your .ssh/config file add something like this to use this single-use key (needed because if you already have a key for the remote host managed by ssh-agent then it will be used instead): Host rsync User foo HostName remote.host.name IdentitiesOnly yes IdentityFile ~/.ssh/rsync which says to use only the identity (key) file(s) listed in the config file. man ssh_config(5) Then, on the remote host in .ssh/authorization set the rsync.pub key for running a single command: key rsync.pub Options command=rsync --server --daemon --config=rsync.conf . And setup rsync.conf as explained in the rsync manual [foo_dir] comment = Provides read-only access to foo path = /path/to/foo read only = yes exclude = logs # can't chroot since running as a regular user use chroot = no Then back on the Debian machine: $ rsync -av --rsh=ssh rsync ::foo_dir local_dir or use whatever options you need when using rsync. -- Bill Moseley [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Passwordless SSH setup
very nicely explained! (interested in fleshing this out some to make a newbiedoc out of it? :) On Wed, Jun 02, 2004 at 07:37:42AM -0700, Bill Moseley wrote: And in case anyone finds this in the archive, on SSH Secure Shell you need to convert the keys. So on Debian, create a keypair called rsync and rsync.pub $ ssh-keygen -t dsa -f rsync Then convert and copy to the other machine: $ ssh-keygen -e -f rsync.pub | ssh remotehost 'cat - .ssh2/rsync.pub' and in your .ssh/config file add something like this to use this single-use key (needed because if you already have a key for the remote host managed by ssh-agent then it will be used instead): Host rsync User foo HostName remote.host.name IdentitiesOnly yes IdentityFile ~/.ssh/rsync which says to use only the identity (key) file(s) listed in the config file. man ssh_config(5) Then, on the remote host in .ssh/authorization set the rsync.pub key for running a single command: key rsync.pub Options command=rsync --server --daemon --config=rsync.conf . And setup rsync.conf as explained in the rsync manual [foo_dir] comment = Provides read-only access to foo path = /path/to/foo read only = yes exclude = logs # can't chroot since running as a regular user use chroot = no Then back on the Debian machine: $ rsync -av --rsh=ssh rsync ::foo_dir local_dir or use whatever options you need when using rsync. -- Bill Moseley [EMAIL PROTECTED] -- I use Debian/GNU Linux version 3.0; Linux boss 2.4.18-bf2.4 #1 Son Apr 14 09:53:28 CEST 2002 i586 unknown DEBIAN NEWBIE TIP #88 from Jesse Goerz [EMAIL PROTECTED] : Ever wondered WHAT DOCUMENTATION IS ON YOUR SYSTEM? And if there was an easy way to browse it? apt-get install dhelp dhelp or for those running the testing distribution, try doc-central as well. Also see http://newbieDoc.sourceForge.net/ ... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: passwordless ssh-login
Am Mi, den 03.12.2003 schrieb Vineet Kumar um 21:32: * Joerg Johannes ([EMAIL PROTECTED]) [031203 08:08]: Am Di, den 02.12.2003 schrieb Joerg Johannes um 09:25: I am starting Debian X environment using gdm, but after logging in, I can't find ssh-agent in ps -ae. Only see it after starting it by hand. How are you starting it? The best way to do this is to start your x session under ssh-agent; for example, the default debian Xsession scripts on my machine have me running /usr/bin/ssh-agent x-window-manager. Do you have a local ~/.Xsession? If not, you should try to figure out why the system-wide one on your system is not running ssh-agent (check /etc/X11/Xsession.options for a line that says 'use-ssh-agent'). If so, it's probably just a matter of invoking ssh-agent properly in your X session. Hmmm. I don't have ~/.Xsession, and in /etc/X11/Xsession.option the use-ssh-agent line is present. Still, it is not used. Again, how did you run ssh-agent? Try something like this: ssh-agent x-terminal-emulator and then try ssh-add from the new terminal window that pops up. There it should work. Yes, that works. So ssh-agent is at least not broken... The reason is that ssh-agent sets up environment variables that all of its child processes inherit. If you're trying to use it in some process that doesn't have those variables set up, it's just not going to work. Thank you for this explanation. I'm starting to understand the procedure now. Maybe related to that: I have tried setting up passwordless login to another machine using the steps mentioned in the micro-howto: Succeeded. I don't have to enter my password any more. Even worse: I have to enter my passPHRASE for the key... Aaargh. Is this because ssh-agent doesn't listen to me? Yes, I'd say that this is better, not worse. You've gotten key-based authentication working; now it's just a matter of setting up your agent properly. I poked around a bit and changed my /etc/gdm/Sessions/Icewm. It now contains exec /usr/bin/ssh-agent /usr/bin/icewm and now it works. But I still don't know why the global Xinitrc is not used. (BTW, in the meantime (until you've gotten your ssh-agent set up properly) if you don't want to type a passphrase, you should be able to just hit enter and then be prompted for a password instead). Hehe, good to know -- this saves a lot of typing (the passphrase is ~10 times longer than the password). good times, Vineet Thanks, joerg -- Gib GATES keine Chance! signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: passwordless ssh-login
* Joerg Johannes ([EMAIL PROTECTED]) [031204 07:36]: Am Mi, den 03.12.2003 schrieb Vineet Kumar um 21:32: Hmmm. I don't have ~/.Xsession, and in /etc/X11/Xsession.option the use-ssh-agent line is present. Still, it is not used. I poked around a bit and changed my /etc/gdm/Sessions/Icewm. It now contains exec /usr/bin/ssh-agent /usr/bin/icewm and now it works. But I still don't know why the global Xinitrc is not used. Okay, I think I understand what's happening now. In gdm, you're selecting the 'Icewm' session, instead of the 'Debian' session. I bet it would work if you used the Debian session. If the Debian session starts something other than Icewm, and you want it to be icewm instead, do 'update-alternatives --config x-window-manager'. Actually, this will still not work right if you have gnome-session (or any other x-session-manager) installed, since the Debian session gives precedence to x-session-manager over x-window-manager. In that case (and if you don't want to simply uninstall gnome-session, etc.) your solution of modifying the Icewm session to include ssh-agent is probably the best. I'm glad you figured it out and got it working. good times, Vineet -- http://www.doorstop.net/ -- http://www.debian.org/ signature.asc Description: Digital signature
Re: passwordless ssh-login
Am Di, den 02.12.2003 schrieb Joerg Johannes um 09:25: Am Mo, den 01.12.2003 schrieb Greg Folkert um 21:22: On Mon, 2003-12-01 at 12:29, Joerg Johannes wrote: Hi everybody Is it possible to use different login names on different machines in combination with passwordless ssh logins? My situation is the following: I have my notebook, where my user account is called jorg. On the university network, I have different user names on several Unix machines. I'd like to be able to log into each of these using ssh, but not typing my password every time. I tried setting up ssh as described in this document: http://www.cs.umd.edu/~arun/misc/ssh.html but the one machine I tried so far asked me for my password even after generating keys and copying to the machine over there. Can someboy help me setting this up? Are you running Debian X environment? If you are they have already setup an ssh-agent for your login. I am starting Debian X environment using gdm, but after logging in, I can't find ssh-agent in ps -ae. Only see it after starting it by hand. run: ssh-add for you various keys... and voila you are good. [EMAIL PROTECTED]:~$ ssh-add Could not open a connection to your authentication agent. [EMAIL PROTECTED]:~$ ps -ae snip 1172 ?00:00:00 ssh-agent snip And now? You still have to enter the passphrase initially for each key, but then after which you don't. I dont't get that far... :( Maybe related to that: I have tried setting up passwordless login to another machine using the steps mentioned in the micro-howto: Succeeded. I don't have to enter my password any more. Even worse: I have to enter my passPHRASE for the key... Aaargh. Is this because ssh-agent doesn't listen to me? joerg -- Gib GATES keine Chance! signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: passwordless ssh-login
On Wed, 03 Dec 2003 17:06:13 +0100 Joerg Johannes [EMAIL PROTECTED] wrote: ... Maybe related to that: I have tried setting up passwordless login to another machine using the steps mentioned in the micro-howto: Succeeded. I don't have to enter my password any more. Even worse: I have to enter my passPHRASE for the key... Aaargh. Is this because ssh-agent doesn't listen to me? ... Hi As far as I now, this is as it should be...if you do not want to enter any password, you will have to create a key without password (thich means that anybody with access to the key will be able to connect to that host with your username) yours Albert -- Albert Dengg [EMAIL PROTECTED] pgp0.pgp Description: PGP signature
Re: passwordless ssh-login
* Joerg Johannes ([EMAIL PROTECTED]) [031203 08:08]: Am Di, den 02.12.2003 schrieb Joerg Johannes um 09:25: I am starting Debian X environment using gdm, but after logging in, I can't find ssh-agent in ps -ae. Only see it after starting it by hand. How are you starting it? The best way to do this is to start your x session under ssh-agent; for example, the default debian Xsession scripts on my machine have me running /usr/bin/ssh-agent x-window-manager. Do you have a local ~/.Xsession? If not, you should try to figure out why the system-wide one on your system is not running ssh-agent (check /etc/X11/Xsession.options for a line that says 'use-ssh-agent'). If so, it's probably just a matter of invoking ssh-agent properly in your X session. [EMAIL PROTECTED]:~$ ssh-add Could not open a connection to your authentication agent. [EMAIL PROTECTED]:~$ ps -ae snip 1172 ?00:00:00 ssh-agent snip And now? Again, how did you run ssh-agent? Try something like this: ssh-agent x-terminal-emulator and then try ssh-add from the new terminal window that pops up. There it should work. The reason is that ssh-agent sets up environment variables that all of its child processes inherit. If you're trying to use it in some process that doesn't have those variables set up, it's just not going to work. You still have to enter the passphrase initially for each key, but then after which you don't. I dont't get that far... :( Maybe related to that: I have tried setting up passwordless login to another machine using the steps mentioned in the micro-howto: Succeeded. I don't have to enter my password any more. Even worse: I have to enter my passPHRASE for the key... Aaargh. Is this because ssh-agent doesn't listen to me? Yes, I'd say that this is better, not worse. You've gotten key-based authentication working; now it's just a matter of setting up your agent properly. (BTW, in the meantime (until you've gotten your ssh-agent set up properly) if you don't want to type a passphrase, you should be able to just hit enter and then be prompted for a password instead). good times, Vineet -- http://www.doorstop.net/ -- --Nick Moffitt A: No. Q: Should I include quotations after my reply? signature.asc Description: Digital signature
Re: passwordless ssh-login
Am Mo, den 01.12.2003 schrieb Greg Folkert um 21:22: On Mon, 2003-12-01 at 12:29, Joerg Johannes wrote: Hi everybody Is it possible to use different login names on different machines in combination with passwordless ssh logins? My situation is the following: I have my notebook, where my user account is called jorg. On the university network, I have different user names on several Unix machines. I'd like to be able to log into each of these using ssh, but not typing my password every time. I tried setting up ssh as described in this document: http://www.cs.umd.edu/~arun/misc/ssh.html but the one machine I tried so far asked me for my password even after generating keys and copying to the machine over there. Can someboy help me setting this up? Are you running Debian X environment? If you are they have already setup an ssh-agent for your login. I am starting Debian X environment using gdm, but after logging in, I can't find ssh-agent in ps -ae. Only see it after starting it by hand. run: ssh-add for you various keys... and voila you are good. [EMAIL PROTECTED]:~$ ssh-add Could not open a connection to your authentication agent. [EMAIL PROTECTED]:~$ ps -ae snip 1172 ?00:00:00 ssh-agent snip And now? You still have to enter the passphrase initially for each key, but then after which you don't. I dont't get that far... :( joerg -- Gib GATES keine Chance! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: passwordless ssh-login
Am Mo, den 01.12.2003 schrieb Vineet Kumar um 19:34: * Joerg Johannes ([EMAIL PROTECTED]) [031201 09:52]: Hi everybody Is it possible to use different login names on different machines in combination with passwordless ssh logins? My situation is the following: Yes, the key setup is completely independent of the username. If it's not working on a particular server, it could be that the server is configured to disallow key-based authentication, or is just using an incompatible ssh daemon. Maybe ssh -v can help you or some other expert? Here we go: [EMAIL PROTECTED]:~$ ssh -v [EMAIL PROTECTED] OpenSSH_3.6.1p2 Debian 1:3.6.1p2-10, SSH protocols 1.5/2.0, OpenSSL 0x0090703f debug1: Reading configuration data /home/jorg/.ssh/config debug1: Applying options for opteron1 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Rhosts Authentication disabled, originating port will not be trusted. debug1: Connecting to changed.this.name [1.2.3.4] port 22. debug1: Connection established. debug1: identity file /home/jorg/.ssh/identity type -1 debug1: identity file /home/jorg/.ssh/id_rsa type 1 debug1: identity file /home/jorg/.ssh/id_dsa type -1 debug1: Remote protocol version 1.99, remote software version OpenSSH_3.7.1p2 debug1: match: OpenSSH_3.7.1p2 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_3.6.1p2 Debian 1:3.6.1p2-10 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server-client aes128-cbc hmac-md5 none debug1: kex: client-server aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug1: Host 'changed.this.name' is known and matches the RSA host key. debug1: Found key in /home/jorg/.ssh/known_hosts:1 debug1: ssh_rsa_verify: signature correct debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,keyboard-interactive debug1: Next authentication method: publickey debug1: Trying private key: /home/jorg/.ssh/identity debug1: Offering public key: /home/jorg/.ssh/id_rsa debug1: Authentications that can continue: publickey,keyboard-interactive debug1: Trying private key: /home/jorg/.ssh/id_dsa debug1: Next authentication method: keyboard-interactive Password: debug1: Authentication succeeded (keyboard-interactive). debug1: channel 0: new [client-session] debug1: Entering interactive session. debug1: channel 0: request pty-req debug1: channel 0: request shell On a sort of tangent, you can use your ~/.ssh/options to save yourself typing if you're often logging in to multiple machines with different usernames on each by using nicknames for each remote account. For example, you can set up something like this: Host chipotle HostName chipotle.longhostname.longdomainname.edu User jorg Host pimiento HostName pimiento.longhostname.longdomainname.edu User joerg and then ssh chipotle or ssh pimiento will do the obvious thing. This way, you can also specify different options such as compression or no, or even to connect on different ports, which can be very useful for saving typing when working around draconian firewalls. This is great help, thank you. I was about to define some aliases in ~/.bashrc ... good times, Vineet Good times will start once I understood how ssh works... joerg -- Gib GATES keine Chance! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: passwordless ssh-login
Vineet Kumar [EMAIL PROTECTED] writes: * Joerg Johannes ([EMAIL PROTECTED]) [031201 09:52]: Hi everybody Is it possible to use different login names on different machines in combination with passwordless ssh logins? My situation is the following: Yes, the key setup is completely independent of the username. If it's not working on a particular server, it could be that the server is configured to disallow key-based authentication, or is just using an incompatible ssh daemon. On a sort of tangent, you can use your ~/.ssh/options to save yourself typing if you're often logging in to multiple machines with different usernames on each by using nicknames for each remote account. [...] At least on my (sid) system, it's ~/.ssh/config. And thanks a lot. That was useful ^_^ -- Cristian Gutierrez http://www.dcc.uchile.cl/~crgutier [EMAIL PROTECTED]Jabber:[EMAIL PROTECTED] Programming is 10% science, 25% ingenuity and 65% getting the ingenuity to work with the science. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: passwordless ssh-login
* Bob Proulx ([EMAIL PROTECTED]) [031201 22:33]: Vineet Kumar wrote: On a sort of tangent, you can use your ~/.ssh/options to save yourself A small thing. It is ~/.ssh/config not options. Yes, that's correct; I mistyped it. good times, Vineet -- http://www.doorstop.net/ -- Great spirits have always found violent opposition from mediocre minds. The latter cannot understand it when a man does not thoughtlessly submit to hereditary prejudices but honestly and courageously uses his intelligence. -- Albert Einstein signature.asc Description: Digital signature
passwordless ssh-login
Hi everybody Is it possible to use different login names on different machines in combination with passwordless ssh logins? My situation is the following: I have my notebook, where my user account is called jorg. On the university network, I have different user names on several Unix machines. I'd like to be able to log into each of these using ssh, but not typing my password every time. I tried setting up ssh as described in this document: http://www.cs.umd.edu/~arun/misc/ssh.html but the one machine I tried so far asked me for my password even after generating keys and copying to the machine over there. Can someboy help me setting this up? Thanks, joerg -- Gib GATES keine Chance! signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: passwordless ssh-login
* Joerg Johannes ([EMAIL PROTECTED]) [031201 09:52]: Hi everybody Is it possible to use different login names on different machines in combination with passwordless ssh logins? My situation is the following: Yes, the key setup is completely independent of the username. If it's not working on a particular server, it could be that the server is configured to disallow key-based authentication, or is just using an incompatible ssh daemon. On a sort of tangent, you can use your ~/.ssh/options to save yourself typing if you're often logging in to multiple machines with different usernames on each by using nicknames for each remote account. For example, you can set up something like this: Host chipotle HostName chipotle.longhostname.longdomainname.edu User jorg Host pimiento HostName pimiento.longhostname.longdomainname.edu User joerg and then ssh chipotle or ssh pimiento will do the obvious thing. This way, you can also specify different options such as compression or no, or even to connect on different ports, which can be very useful for saving typing when working around draconian firewalls. good times, Vineet -- http://www.doorstop.net/ -- http://www.digitalconsumer.org/ Protecting fair-use rights in the digital world signature.asc Description: Digital signature
Re: passwordless ssh-login
On Mon, 2003-12-01 at 12:29, Joerg Johannes wrote: Hi everybody Is it possible to use different login names on different machines in combination with passwordless ssh logins? My situation is the following: I have my notebook, where my user account is called jorg. On the university network, I have different user names on several Unix machines. I'd like to be able to log into each of these using ssh, but not typing my password every time. I tried setting up ssh as described in this document: http://www.cs.umd.edu/~arun/misc/ssh.html but the one machine I tried so far asked me for my password even after generating keys and copying to the machine over there. Can someboy help me setting this up? Are you running Debian X environment? If you are they have already setup an ssh-agent for your login. run: ssh-add for you various keys... and voila you are good. You still have to enter the passphrase initially for each key, but then after which you don't. -- [EMAIL PROTECTED] REMEMBER ED CURRY! http://www.iwethey.org/ed_curry signature.asc Description: This is a digitally signed message part
Re: passwordless ssh-login
Greg Folkert wrote: Are you running Debian X environment? If you are they have already setup an ssh-agent for your login. run: ssh-add for you various keys... and voila you are good. You still have to enter the passphrase initially for each key, but then after which you don't. strange on my mashine (Debian/unstable) ssh-agent it isen't setup :/ ssh-add just says: Could not open a connection to your authentication agent. The ssh-agent binary exists, though... greets niko @greg folkert: sorry for directly maling you... i just hit reply out of habit -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: passwordless ssh-login
Joerg Johannes wrote: http://www.cs.umd.edu/~arun/misc/ssh.html but the one machine I tried so far asked me for my password even after generating keys and copying to the machine over there. Can someboy help me setting this up? Check the permissions of files. If they are group writable (depending upon the ssh compilation) then it will ignore the authorized_keys file. It and all directories above it must appear to be secure to sshd. chmod go-w ~ ~/.ssh ~/.ssh/authorized_keys I am guessing that one of those is writable and so sshd is ignoring it. Bob pgp0.pgp Description: PGP signature
Re: passwordless ssh-login
Vineet Kumar wrote: On a sort of tangent, you can use your ~/.ssh/options to save yourself A small thing. It is ~/.ssh/config not options. Bob P.S. I double checked unstable just to make sure I was not missing something. pgp0.pgp Description: PGP signature
Re: passwordless ssh-login
Niko Efthymiou wrote: Greg Folkert wrote: Are you running Debian X environment? If you are they have already setup an ssh-agent for your login. strange on my mashine (Debian/unstable) ssh-agent it isen't setup :/ ssh-add just says: Could not open a connection to your authentication agent. The ssh-agent binary exists, though... Check /etc/X11/Xsession.options and make sure that use-ssh-agent is present in the file. That is the default but perhaps you have a configuration file from way, way back without that and have been answering N when doing upgrades? Check /etc/X11/Xsession.d/90xfree86-common_ssh-agent and trace what it is doing. You should see that it is setting up the X startup to use ssh-agent if it can and you have not already done it. Bob pgp0.pgp Description: PGP signature
Re: passwordless ssh login not working: BUG?
It seems this thread made its way onto usenet, and I reproduce the text of an email exchange that resulted: On Wed, Mar 19, 2003 at 02:37:21PM +1100, (somebody) wrote: Hi Pigeon, I just read your usenet thread http://groups.google.com/groups?hl=enlr=ie=UTF-8oe=UTF-8threadm=20030208053009%246b20%40gated-at.bofh.itrnum=10prev=/groups%3Fq%3D%2522debug1%2522%2B%2522try%2Bpubkey:%2522%2B%2522.ssh/id_dsa%2522%26hl%3Den%26lr%3D%26ie%3DUTF-8%26oe%3DUTF-8%26selm%3D20030208053009%25246b20%2540gated-at.bofh.it%26rnum%3D10 I had the _exact_ same problem as you. After reading the thread and doing the same things I have it working as well. If you wouldn't have posted this message, I would not have it working at all. You should document it perhaps? There would be many people out there who would appreciate it. It's certainly a problem with ssh-keygen / sshd not allowing the keys to be terminated with [EMAIL PROTECTED], but allowing a non-existing file. Thanks a lot Pigeon wrote: So it got onto usenet? Wow, I had no idea. It was on the debian-user list ([EMAIL PROTECTED]) that I posed the question originally. I'm glad you found it useful! There's not much point in me documenting it as I don't have a website on which to publish the documentation. However, there are various people on debian-user who maintain FAQs and lists of helpful hints etc, so I shall pass the suggestion on. (Having removed your personal details, of course.) According to Vineet, who was my debian-user mentor on this, the termination of the key is supposed to be a comment, so it shouldn't make any difference whether it's an address or a nonexistent file. The fact that this is not the case on your system as well as mine suggests to me that I should also file a bug against sshd. I am reluctant to file bugs in case I end up wasting the developers' time over something which is actually my brain not working or a peculiarity of my setup. Since there are evidently other people having the same problem, does the list feel I should go ahead? And are any FAQ-writers interested in (somebody)'s suggestion? Pigeon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: passwordless ssh login not working
* Pigeon ([EMAIL PROTECTED]) [030215 20:05]: So, I rename 'identity' to 'id_rsa' and try again... IT WORKS!!! Huh? The authorized_keys on the host still ends in '/home/pigeon/.ssh/identity', which doesn't exist on either machine. Well, this is unsurprising. The last field of a public key line is just a comment, and can be anything (or even nothing). Mine happened to be a filename, which was misleading. Anyway, glad you got it working. good times, Vineet -- http://www.doorstop.net/ -- http://www.anti-dmca.org/ msg31357/pgp0.pgp Description: PGP signature
Re: passwordless ssh login not working
On Sat, Feb 15, 2003 at 11:28:12PM +0800, Sukanta Kumar Hazra wrote: Hi! copy th id_dsa key to .ssh/authorized_keys2 and make sure the permission mode is 600. ssh2 would work then. - Sukanta Thanks - but unfortunately, it doesn't. There was a previous thread on this, from Jan 19, containing similar recommendations; apparently they worked for that poster, but not for me. Since protocol 1 is now working, I'm not too bothered about 2 not working, but it would be nice to fix it purely on the grounds of not liking to have broken stuff around especially when it works for everyone else! Pigeon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: passwordless ssh login not working
* Pigeon ([EMAIL PROTECTED]) [030215 11:03]: On Sat, Feb 15, 2003 at 11:28:12PM +0800, Sukanta Kumar Hazra wrote: Hi! copy th id_dsa key to .ssh/authorized_keys2 and make sure the permission mode is 600. ssh2 would work then. - Sukanta Thanks - but unfortunately, it doesn't. There was a previous thread on this, from Jan 19, containing similar recommendations; apparently they worked for that poster, but not for me. Since protocol 1 is now working, I'm not too bothered about 2 not working, but it would be nice to fix it purely on the grounds of not liking to have broken stuff around especially when it works for everyone else! I agree; it's no fun to just give up! It should work. Here's what I have on my laptop (which is what I carry around everywhere and is the local side of things): doozer:~% ssh -V OpenSSH_3.4p1 Debian 1:3.4p1-4, SSH protocols 1.5/2.0, OpenSSL 0x0090607f doozer:~% ls -la .ssh total 48 drwx--2 vineet vineet 4096 2003-01-17 17:22 ./ drwxr-xr-x 80 vineet vineet 4096 2003-02-15 12:28 ../ -r1 vineet vineet963 2002-09-13 19:49 identity -rw-r--r--1 vineet vineet 29082 2003-02-14 11:30 known_hosts -rw-r--r--1 vineet vineet 15 2002-09-03 17:00 options doozer:~% head -4 .ssh/identity -BEGIN RSA PRIVATE KEY- Proc-Type: 4,ENCRYPTED DEK-Info: DES-EDE3-CBC,99FDB9028C056429 doozer:~% cat .ssh/options ForwardX11 yes doozer:~% grep -v '^#' /etc/ssh/ssh_config That is, it's empty; there are no uncommented lines there. Also, I cat-ed .ssh/options just to show there's nothing special in there. The ForwardX11 statement is unrelated. So I did no setup on the client side, save generate an rsa key and put it at ~/.ssh/identity . Here's what I have on a remote host to which I can connect using my key: Thalia:~% ls -la .ssh total 10 drwx-- 2 vineet dba 512 Dec 3 15:35 ./ drwxr-xr-x 14 vineet other 1024 Feb 7 15:33 ../ -rw--- 1 vineet dba 236 Nov 26 11:31 authorized_keys -rw-r--r-- 1 vineet dba 1725 Feb 11 14:24 known_hosts Thalia:~% cat .ssh/authorized_keys ssh-rsa B3NzaC1yc2EBJQAAAIEA3QejohPKVWiC5dgyhcX1R41j10gCDXXHKu0II3I1S54UbB3bOh1ugyyZKADFtbjWTAk2944Z/s0yfM5gIhxkr5QyDM0Lg86MijcZE76NTSa6YZ7hRDfrxGFjGh1CcUL7ZuL/82wCc+kUw1cu3EWdxoi78lxZUa62/aQRrYa4SE0= /home/vineet/.ssh/identity Thalia:~% ssh -V OpenSSH_3.5p1, SSH protocols 1.5/2.0, OpenSSL 0x0090607f Thalia:~% grep -i keyauth /usr/local/etc/sshd_config PubkeyAuthentication yes Hope that helps. I can send you the whole sshd_config (off list) if it would help. good times, Vineet -- http://www.doorstop.net/ -- Extremism in the defense of liberty is no vice. Moderation in the pursuit of justice is no virtue. -- Barry Goldwater msg30947/pgp0.pgp Description: PGP signature
Re: passwordless ssh login not working
Pigeon [EMAIL PROTECTED] writes: Since protocol 1 is now working, I'm not too bothered about 2 not working, but it would be nice to fix it purely on the grounds of not liking to have broken stuff around especially when it works for everyone else! I see in your first message you combed the debugging output from the client. In the past I have resolved some weird ssh configuration errors with the help of the servers debugging output. One the sshd host, start sshd from the command line with the debug switch and bind to an unsed port, it will dump copious info. # sshd -d -p 24 ...then hit it with the client $ ssh -p 24 HostWhatNot This has helped for me, hope it reveals something for you. -jereme -- +--+ Jereme Corrado [EMAIL PROTECTED] System Administrator Restorative Management Corp. gpg: 1024D/9C39E1F0 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: passwordless ssh login not working
On Sat, Feb 15, 2003 at 12:40:08PM -0800, Vineet Kumar wrote: * Pigeon ([EMAIL PROTECTED]) [030215 11:03]: Since protocol 1 is now working, I'm not too bothered about 2 not working, but it would be nice to fix it purely on the grounds of not liking to have broken stuff around especially when it works for everyone else! I agree; it's no fun to just give up! It should work. Here's what I have on my laptop (which is what I carry around everywhere and is the local side of things): snip Well, the clot thickens... and the wound heals! So, you had protocol 2 keys, but named 'identity' rather than 'id_rsa', and nothing else in .ssh (no protocol 1 keys, like me). Other than that, the setup was the same, permissions- and config-wise. Same version, too, as on your older end - ssh -V gives: OpenSSH_3.4p1 Debian 1:3.4p1-1, SSH protocols 1.5/2.0, OpenSSL 0x0090603f So, I cleared my protocol 1 keys out into a separate directory, generated a new protocol 2 rsa key pair and called it 'identity' instead of 'id_rsa', copied the public key across to the host. No - still didn't work. Oh, wait a minute: Here's what I have on a remote host to which I can connect using my key: snip Thalia:~% cat .ssh/authorized_keys ssh-rsa B3NzaC1y-snip-SE0= /home/vineet/.ssh/identity Mine doesn't end in the key file name, it ends in pigeon@pigeon, which is what ssh-keygen wrote there. So I change pigeon@pigeon to /home/pigeon/.ssh/identity. Result: Still doesn't work. Have a look at ssh -vvv again, and find that it is no longer barfing on the key file and pretending it doesn't know the format, but it does get confused later on because the file is named 'identity' and not 'id_rsa'. So, I rename 'identity' to 'id_rsa' and try again... IT WORKS!!! Huh? The authorized_keys on the host still ends in '/home/pigeon/.ssh/identity', which doesn't exist on either machine. ssh -vvv reveals that it is looking for 'identity', not finding it, trying 'id_rsa', and being happy. BUT... higher up the -vvv output, it is once more complaining that id_rsa isn't a proper key file, as in my original post. From this, it would appear that for some reason the problem was that ssh-keygen was terminating the keys in 'pigeon@pigeon', but ssh/sshd didn't like that and would prefer them to end in a filename, even if the file doesn't exist... WEIRDY WEIRDY Well, thanks very much for the clue that got it fixed! Nice one! Thanks, Pigeon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: passwordless ssh login not working
On Sat, Feb 15, 2003 at 08:50:29PM -0500, jereme wrote: Pigeon [EMAIL PROTECTED] writes: Since protocol 1 is now working, I'm not too bothered about 2 not working, but it would be nice to fix it purely on the grounds of not liking to have broken stuff around especially when it works for everyone else! I see in your first message you combed the debugging output from the client. In the past I have resolved some weird ssh configuration errors with the help of the servers debugging output. One the sshd host, start sshd from the command line with the debug switch and bind to an unsed port, it will dump copious info. # sshd -d -p 24 ...then hit it with the client $ ssh -p 24 HostWhatNot This has helped for me, hope it reveals something for you. Well, I just got it working (see previous post) with Vineet's help, but nevertheless tried this out, so I could add it to my list of useful tricks. For it is a very useful trick! Thanks, Pigeon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: passwordless ssh login not working
On Sat, Feb 08, 2003 at 11:31:12PM -0800, Vineet Kumar wrote: * Pigeon ([EMAIL PROTECTED]) [030208 20:16]: debug3: Not a RSA1 key file /root/.ssh/id_rsa. (and the same for id_dsa) Looking in these files, I find they don't look right compared to the id_?sa.pub files. The .pub files contain ssh-rsa fv487t509n0etcetcetc= root@pigeon all as one long line. The private key files contain -BEGIN RSA PRIVATE KEY- followed by the key as 12 separate lines and an -END.. line. So, I take my text editor to the private key files and change them to the same format as the public key files. It still doesn't work, but the error message changes: debug3: Not a RSA1 key file /root/.ssh/id_rsa. key_read: uudecode ptu5087509nrounrin975tetcetcetc= root@pigeon failed Does that mean anything to anyone? Yup. Your ssh is expecting ~/.ssh/id_rsa to contain a version 1 rsa key, as would be generated by using ssh-keygen -t rsa1. That's the kind of key ssh would use when trying to connect with protocol version 1. Well, that's odd. /etc/ssh/sshd_config is telling the host to accept Protocol 2 only, and I was using ssh-keygen -t rsa to create a version 2 key file - well, that was my intention. Does 'ssh -2 remotehost' work? If so, try setting 'Protocol 2' (or 'Protocol 2,1') in your ~/.ssh/config or /etc/ssh/ssh_config . No, the result is identical with or without the -2. So you should either generate a version 1 key (in ~/.ssh/identity, for convention's sake) or connect using protocol version 2. Interesting again. I did this, changed /etc/ssh/sshd_config to specify Protocol 1 only, and generated an rsa1 host-key pair in /etc/ssh. Now, it works! Thank you! But the protocol 2 still doesn't work. It is very strange. If I'm incorrect about why it's failing, some more of that -vvv output and/or your ssh_config would help. The whole lot of the -vvv output is in my first post. My ssh_config (local ssh client config, as opposed to sshd_config = remote host config, if I've got it right) is empty (effectively) - it's the default one that woody installs, and every line is commented out. But now the proto1 version works, I'm happy. I've got passwordless ssh login, which is what I wanted. Odd though that proto2 doesn't work. Thanks again, Pigeon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: passwordless ssh login not working
On Fri, Feb 07, 2003 at 10:38:17PM -0700, Tim Ayers wrote: When you generate your keys and it asks for a passphrase, just hit enter. Don't use a passphrase and it won't prompt you for one. No, that's how I did it. It's not asking for a passphrase, it's asking for a password, just as if I had no keys. On Sat, Feb 08, 2003 at 02:34:34AM -0500, sean finney wrote: heya, are you sure your sshd_config is configured to allow PubkeyAuthentication? Yes - here it is (below) But the main problem seems to be the bit from the ssh -vvv output, where it says debug3: Not a RSA1 key file /root/.ssh/id_rsa. (and the same for id_dsa) Looking in these files, I find they don't look right compared to the id_?sa.pub files. The .pub files contain ssh-rsa fv487t509n0etcetcetc= root@pigeon all as one long line. The private key files contain -BEGIN RSA PRIVATE KEY- followed by the key as 12 separate lines and an -END.. line. So, I take my text editor to the private key files and change them to the same format as the public key files. It still doesn't work, but the error message changes: debug3: Not a RSA1 key file /root/.ssh/id_rsa. key_read: uudecode ptu5087509nrounrin975tetcetcetc= root@pigeon failed Does that mean anything to anyone? Pigeon (/etc/ssh/sshd_config follows) # Package generated configuration file # See the sshd(8) manpage for defails # What ports, IPs and protocols we listen for Port 22 # Use these options to restrict which interfaces/protocols sshd will bind to #ListenAddress :: #ListenAddress 0.0.0.0 Protocol 2 # HostKeys for protocol version 2 HostKey /etc/ssh/ssh_host_rsa_key HostKey /etc/ssh/ssh_host_dsa_key #Privilege Separation is turned on for security UsePrivilegeSeparation yes # ...but breaks Pam auth via kbdint, so we have to turn it off # Use PAM authentication via keyboard-interactive so PAM modules can # properly interface with the user (off due to PrivSep) PAMAuthenticationViaKbdInt no # Lifetime and size of ephemeral version 1 server key KeyRegenerationInterval 3600 ServerKeyBits 768 # Logging SyslogFacility AUTH LogLevel INFO # Authentication: LoginGraceTime 600 PermitRootLogin yes StrictModes yes RSAAuthentication yes PubkeyAuthentication yes AuthorizedKeysFile %h/.ssh/authorized_keys # rhosts authentication should not be used RhostsAuthentication no # Don't read the user's ~/.rhosts and ~/.shosts files IgnoreRhosts yes # For this to work you will also need host keys in /etc/ssh_known_hosts RhostsRSAAuthentication no # similar for protocol version 2 HostbasedAuthentication no # Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication #IgnoreUserKnownHosts yes # To enable empty passwords, change to yes (NOT RECOMMENDED) PermitEmptyPasswords yes # Uncomment to disable s/key passwords #ChallengeResponseAuthentication no # To disable tunneled clear text passwords, change to no here! PasswordAuthentication yes # To change Kerberos options #KerberosAuthentication no #KerberosOrLocalPasswd yes #AFSTokenPassing no #KerberosTicketCleanup no # Kerberos TGT Passing does only work with the AFS kaserver #KerberosTgtPassing yes X11Forwarding no X11DisplayOffset 10 PrintMotd no #PrintLastLog no KeepAlive yes #UseLogin no #MaxStartups 10:30:60 #Banner /etc/issue.net #ReverseMappingCheck yes Subsystem sftp/usr/lib/sftp-server -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: passwordless ssh login not working
* Pigeon ([EMAIL PROTECTED]) [030208 20:16]: debug3: Not a RSA1 key file /root/.ssh/id_rsa. (and the same for id_dsa) Looking in these files, I find they don't look right compared to the id_?sa.pub files. The .pub files contain ssh-rsa fv487t509n0etcetcetc= root@pigeon all as one long line. The private key files contain -BEGIN RSA PRIVATE KEY- followed by the key as 12 separate lines and an -END.. line. So, I take my text editor to the private key files and change them to the same format as the public key files. It still doesn't work, but the error message changes: debug3: Not a RSA1 key file /root/.ssh/id_rsa. key_read: uudecode ptu5087509nrounrin975tetcetcetc= root@pigeon failed Does that mean anything to anyone? Yup. Your ssh is expecting ~/.ssh/id_rsa to contain a version 1 rsa key, as would be generated by using ssh-keygen -t rsa1. That's the kind of key ssh would use when trying to connect with protocol version 1. Does 'ssh -2 remotehost' work? If so, try setting 'Protocol 2' (or 'Protocol 2,1') in your ~/.ssh/config or /etc/ssh/ssh_config . So you should either generate a version 1 key (in ~/.ssh/identity, for convention's sake) or connect using protocol version 2. If I'm incorrect about why it's failing, some more of that -vvv output and/or your ssh_config would help. good times, Vineet -- http://www.doorstop.net/ -- http://www.eff.org/ msg29569/pgp0.pgp Description: PGP signature
passwordless ssh login not working
Hi, I'm trying to set up ssh to enable passwordless logins from 192.168.1.1 to 192.168.1.2. I have used ssh-keygen to generate key pairs for root on 192.168.1.1 and copied the .pub files into /root/.ssh/authorized_keys. According to man ssh, as I understand it, this should be enough to get passwordless login working. But it doesn't - I still get asked for a password. I have generated keys in all 3 formats - v1 RSA, v2 RSA and v2 DSA - as the default /root/.ssh/identity, id_rsa and id_dsa. None of them work. The 'debugging' output from ssh says nothing useful about .ssh/identity, but appears to claim that the id_rsa and id_dsa files are invalid! I don't see how they can be unless either ssh or ssh_keygen are up the spout, and I haven't heard anyone else complaining. Any ideas what's going on? Pigeon ssh is OpenSSH_3.4p1 Debian 1:3.4p1-1 ssh-keygen doesn't want to give a version number but it's the woody version, file size 84616 date Jun 28 2002. The id_rsa file it moans about looks like -BEGIN RSA PRIVATE KEY- (12 lines of random-seeming characters) -END RSA PRIVATE KEY- The 'debugging' (-vvv) output from ssh follows: OpenSSH_3.4p1 Debian 1:3.4p1-1, SSH protocols 1.5/2.0, OpenSSL 0x0090603f debug1: Reading configuration data /etc/ssh/ssh_config debug1: Rhosts Authentication disabled, originating port will not be trusted. debug1: ssh_connect: needpriv 0 debug1: Connecting to 192.168.1.2 [192.168.1.2] port 22. debug1: Connection established. debug1: identity file /root/.ssh/identity type 0 debug3: Not a RSA1 key file /root/.ssh/id_rsa. debug2: key_type_from_name: unknown key type '-BEGIN' debug3: key_read: no key found debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug2: key_type_from_name: unknown key type '-END' debug3: key_read: no key found debug1: identity file /root/.ssh/id_rsa type 1 debug3: Not a RSA1 key file /root/.ssh/id_dsa. debug2: key_type_from_name: unknown key type '-BEGIN' debug3: key_read: no key found debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug2: key_type_from_name: unknown key type '-END' debug3: key_read: no key found debug1: identity file /root/.ssh/id_dsa type 2 debug1: Remote protocol version 2.0, remote software version OpenSSH_3.4p1 Debian 1:3.4p1-1 debug1: match: OpenSSH_3.4p1 Debian 1:3.4p1-1 pat OpenSSH* Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_3.4p1 Debian 1:3.4p1-1 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,[EMAIL PROTECTED] debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,[EMAIL PROTECTED] debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,[EMAIL PROTECTED],hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,[EMAIL PROTECTED],hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none debug2: kex_parse_kexinit: none debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,[EMAIL PROTECTED] debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,[EMAIL PROTECTED] debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,[EMAIL PROTECTED],hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,[EMAIL PROTECTED],hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_init: found hmac-md5 debug1: kex: server-client aes128-cbc hmac-md5 none debug2: mac_init: found hmac-md5 debug1: kex: client-server aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug1: dh_gen_key: priv key bits set: 117/256 debug1: bits set: 1591/3191 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1:
Passwordless SSH still asks for password when remote usernamediffers
Here is what I did : # Local end : cd ~/.ssh # Enter an empty password when prompted by the following command ssh-keygen -t dsa -f id_dsa scp id_dsa.pub remote.end.net:~/.ssh # Repeat last command for all remote ends # Remote ends cd ~/.ssh touch authorized_keys2 cat id_dsa.pub authorized_keys2 chmod 640 authorized_keys2 rm -f id_dsa.pub # Local end : ssh remote.end.net # Look ma, no password ! Works great between various hosts where I have the same username. But when I want to connect to a host where my username is different (ssh -l differentusername other.remote.end.net) I am still asked for a password. I log on fine, but it is annoying to be unable to enjoy passwordless SSH, SCP and Unison just because I could not get an account with my usual username. Can anybody point me toward a solution ? signature.asc Description: This is a digitally signed message part
Re: Passwordless SSH still asks for password when remote username differs
On Sun, Jan 19, 2003 at 04:34:44PM +0100, Jean-Marc V. Liotier wrote: Here is what I did : # Local end : cd ~/.ssh # Enter an empty password when prompted by the following command ssh-keygen -t dsa -f id_dsa scp id_dsa.pub remote.end.net:~/.ssh # Repeat last command for all remote ends # Remote ends cd ~/.ssh touch authorized_keys2 cat id_dsa.pub authorized_keys2 chmod 640 authorized_keys2 rm -f id_dsa.pub Fine, although you can just use ssh-copy-id. Works great between various hosts where I have the same username. But when I want to connect to a host where my username is different (ssh -l differentusername other.remote.end.net) I am still asked for a password. Please show the output of 'ssh -vvv -l differentusername other.remote.end.net'. It works for me ... Cheers, -- Colin Watson [[EMAIL PROTECTED]] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Passwordless SSH still asks for password when remote usernamediffers
On Sun, 2003-01-19 at 16:54, Colin Watson wrote: On Sun, Jan 19, 2003 at 04:34:44PM +0100, Jean-Marc V. Liotier wrote: Please show the output of 'ssh -vvv -l differentusername other.remote.end.net'. It works for me ... Actually, only one remote host exhibits the behavior. Other hosts work fine, even across platforms (Irix and Debian). The culprit is a Debian host. And the refusal to log me on without asking for a password is independent of the username. So my initial question was completely off... Apologies for the false trail. So I am guessing this is a wrongly configured option in /etc/sshd_config on the remote host. Maybe it refuses the public key authentication, or the keys are wrong... I went through the /etc/ssh/sshd_config but I don't quite understand it enough to find what could be wrong. If anyone has a clue, it is welcome. Kisangani% ssh -vvv [EMAIL PROTECTED] OpenSSH_3.5p1 Debian 1:3.5p1-4.1, SSH protocols 1.5/2.0, OpenSSL 0x0090700f debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug1: Rhosts Authentication disabled, originating port will not be trusted. debug1: ssh_connect: needpriv 0 debug1: Connecting to tethys.jipo.org [194.206.11.154] port 22. debug1: Connection established. debug1: identity file /home/jim/.ssh/identity type -1 debug1: identity file /home/jim/.ssh/id_rsa type -1 debug3: Not a RSA1 key file /home/jim/.ssh/id_dsa. debug2: key_type_from_name: unknown key type '-BEGIN' debug3: key_read: no key found debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug2: key_type_from_name: unknown key type '-END' debug3: key_read: no key found debug1: identity file /home/jim/.ssh/id_dsa type -1 debug1: Remote protocol version 1.99, remote software version OpenSSH_3.4p1 Debian 1:3.4p1-1 debug1: match: OpenSSH_3.4p1 Debian 1:3.4p1-1 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_3.5p1 Debian 1:3.5p1-4.1 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,[EMAIL PROTECTED] debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,[EMAIL PROTECTED] debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,[EMAIL PROTECTED],hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,[EMAIL PROTECTED],hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,[EMAIL PROTECTED] debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,[EMAIL PROTECTED] debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,[EMAIL PROTECTED],hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,[EMAIL PROTECTED],hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_init: found hmac-md5 debug1: kex: server-client aes128-cbc hmac-md5 none debug2: mac_init: found hmac-md5 debug1: kex: client-server aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug1: dh_gen_key: priv key bits set: 135/256 debug1: bits set: 1608/3191 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug3: check_host_in_hostfile: filename /home/jim/.ssh/known_hosts debug2: key_type_from_name: unknown key type '1024' debug3: key_read: no key found debug3: check_host_in_hostfile: match line 3 debug3: check_host_in_hostfile: filename /home/jim/.ssh/known_hosts debug2: key_type_from_name: unknown key type '1024' debug3: key_read: no key found debug3: check_host_in_hostfile: match line 3 debug1: Host 'tethys.jipo.org' is known and matches the RSA host key. debug1: Found key in /home/jim/.ssh/known_hosts:3 debug1: bits set: 1565/3191 debug1: ssh_rsa_verify: signature correct debug1: kex_derive_keys debug1: newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: waiting for SSH2_MSG_NEWKEYS debug1: newkeys: mode 0 debug1:
Re: Passwordless SSH still asks for password when remote username differs
Make sure that the user's home dir on the remote host is not group writeable (and the .ssh subdir as well). sshd does some checks before using some files. Christian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Passwordless SSH still asks for password when remote usernamediffers
On Sun, 2003-01-19 at 18:02, Christian Jaeger wrote: Make sure that the user's home dir on the remote host is not group writeable (and the .ssh subdir as well). sshd does some checks before using some files. Yes, that was it. 'chmod 700 ~/.ssh' on the remote host solved the problem. Thanks to you and to Colin for your help ! signature.asc Description: This is a digitally signed message part
Re: Passwordless SSH still asks for password when remote usernamediffers
On Sun, 2003-01-19 at 18:04, Jean-Marc V. Liotier wrote: On Sun, 2003-01-19 at 18:02, Christian Jaeger wrote: Make sure that the user's home dir on the remote host is not group writeable (and the .ssh subdir as well). sshd does some checks before using some files. Yes, that was it. 'chmod 700 ~/.ssh' on the remote host solved the problem. Thanks to you and to Colin for your help ! While I'm at it, here is my revised recipe fort passwordless SSH. Next step : use ssh-agent... But that is going to be another story. For now : # Local end : cd ~/.ssh # Enter an empty password when prompted by the following command ssh-keygen -t dsa -f id_dsa scp id_dsa.pub [EMAIL PROTECTED]:~/.ssh # Repeat last command for all remote ends # Remote end test -d .ssh || mkdir .ssh chmod 700 ~/.ssh cd ~/.ssh touch authorized_keys2 cat id_dsa.pub authorized_keys2 chmod 640 authorized_keys2 rm -f id_dsa.pub # Local end : ssh -l user remote.end.net # Look ma, no password ! signature.asc Description: This is a digitally signed message part
Re: passwordless ssh on woody failed
In Debian A, I ssh-keygen the public key, scp and append to Debian B ~/.ssh/authorized_keys It seems that Debian now uses protocol version 2, so maybe you need to add v2 key to ~/.ssh/authorized_keys2. -- Alexey Python is executable pseudocode, Perl is executable line-noise.
Re: passwordless ssh on woody failed
In Debian A, I ssh-keygen the public key, scp and append to Debian B ~/.ssh/authorized_keys It seems that Debian now uses protocol version 2, so maybe you need to add v2 key to ~/.ssh/authorized_keys2. -- Alexey Python is executable pseudocode, Perl is executable line-noise. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] Thanks. I end up with ssh-keygen -t rsa and then appended id_rsa.pub to .ssh/authorized_keys2 on the other machine. It works! -- Patrick Hsieh [EMAIL PROTECTED] GPG public key http://pahud.net/pubkeys/pahudatpahud.gpg
Re: passwordless ssh on woody failed
On Mon, Jan 07, 2002, Patrick Hsieh wrote: In Debian A, I ssh-keygen the public key, scp and append to Debian B ~/.ssh/authorized_keys It seems that Debian now uses protocol version 2, so maybe you need to add v2 key to ~/.ssh/authorized_keys2. Thanks. I end up with ssh-keygen -t rsa and then appended id_rsa.pub to .ssh/authorized_keys2 on the other machine. It works! Hi, Not sure exactly what's going on here, maybe you just have some config option specifying this in sshd_config, but, according to the release notes on openssh.org, for version 3.0 of openssh, authorized_keys2 is now depracated in favor of authorized_keys. Supposedly, IIRC, support for it might be removed in the future. HTH, Daniel -- Patrick Hsieh [EMAIL PROTECTED] -- Daniel A. Freedman Laboratory for Atomic and Solid State Physics Department of Physics Cornell University
Re: passwordless ssh on woody failed
On Mon, 7 Jan 2002 03:06:39 -0500 Daniel Freedman [EMAIL PROTECTED] wrote: Not sure exactly what's going on here, maybe you just have some config option specifying this in sshd_config, but, according to the release notes on openssh.org, for version 3.0 of openssh, authorized_keys2 is now depracated in favor of authorized_keys. Supposedly, IIRC, support for it might be removed in the future. Interesting, the ssh(1) manpage doesn't refer to authorized_keys2 anymore, just authorized_keys(and in the SSH protocol v2 section, to boot). Thanks for letting us know :) -- .--=-=-=-=--=---=-=-=. /David Barclay HarrisAut agere, aut mori. \ \Clan Barclay Either action, or death./ `---==-=-=-=-===-=---=--=' pgpFExezltWLM.pgp Description: PGP signature
passwordless ssh on woody failed
Hello list, I have to Debian woody with ssh-3.0.1p1-1.2. In Debian A, I ssh-keygen the public key, scp and append to Debian B ~/.ssh/authorized_keys Then I try to ssh login from Debian A to Debian B again, but still got the password prompt. Is there something wrong? -- Patrick Hsieh [EMAIL PROTECTED] GPG public key http://pahud.net/pubkeys/pahudatpahud.gpg
Passwordless ssh?
Can someone tell me how to enable passwordless ssh under potato? (ssh 1.2.26) This is for the purpose of backups. I have public key of the machine which is doing the connecting in the backup user's authorized keys file, and the user that is doing the connecting is in the backup user's .shosts file. However, the machine always insists on asking for a password. There are similarly configured machines around here already, so this should work...am I missing some PAM settings or something?
Re: Passwordless ssh?
Quoth Christopher J. Morrone on 27 Oct, 1999:
This is for the purpose of backups. I have public key of the machine
which is doing the connecting in the backup user's authorized keys file,
and the user that is doing the connecting is in the backup user's .shosts
file. However, the machine always insists on asking for a password.
Is it asking for the user password (A message along the lines of 'Password for
user at host') or the password for the key ('Password for RSA key yadda
yadda')? If it's the second, you can probably solve your problem by
investigating ssh-agent and ssh-add. Generally, run ssh-agent in a parent
process, and then run ssh-add to add your key. You'll be prompted for your
password once, and all child processes will not require you to identify
yourself again. If you need further help, just say so.
If it's asking for the user's password, for some reason the server is refusing
RSA authentication. Make sure your local identity.pub is in the
authorized_keys on the server. Make sure the permissions are set properly if
the server is using Strickt Permissions. Make sure the server allows .shosts
to be taken into effect.
--
Robert C. Jones | rjones-at-devzero-dot-org | http://www.devzero.org
Linux junkie | professional sysadmin | raving lunatic
Please use PGP: http://www.devzero.org/public.asc
pgp7pjFaJUBEC.pgp
Description: PGP signature
