Paul E Condon wrote: > I go into this seeming unnecessary detail because the behavior ot ssh > in this environment is very strange: I think it makes sense and can be explained. > Sitting at Big, logged in as user pec, I can: > > connect to pec@gq without giving any password > connect to root@gq also without a password > connect to pec@dl2 also without a password Good. > But I CANNOT connect to root@dl2. When I try I'm asked to type in password > and when I type it in I get a response "denied, please try again" > I know the root password to Dl2 and the password for the ssh key that > I generated for /root/.ssh/id-rsa , and I carefully contrived to make it > the same as system password to that of system user 'root'. I think the ssh rsa keys on the server for dl2 are broken in some way. This is preventing you from logging in using ssh rsa keys. Jessie 8 and includes a new default configuration: PermitRootLogin without-password That prevents logging in with a password. Only ssh rsa keys are allowed. But if the ssh rsa key login is broken then it exactly matches your description. The usual problem is permissions. Double check all of the file permissions on the server side of things. It is the server that is the problem. This entire path cannot be writable by group or other. # ls -ld / /root /root/.ssh /root/.ssh/authorized_keys drwxr-xr-x 26 root root 4096 Feb 17 13:10 / drwxr-xr-x 27 root root 4096 May 10 15:17 /root drwx------ 2 root root 4096 Dec 18 2013 /root/.ssh -rw-r--r-- 1 root root 1440 Oct 29 2011 /root/.ssh/authorized_keys Check the /var/log/auth.log file for errors from the sshd daemon. # less /var/log/auth.log If all of the checking fails then log in on the console and start up a debugging sshd session manually. root@dl2:~# /usr/sbin/sshd -d -p 2222 debug1: sshd version OpenSSH_6.7, OpenSSL 1.0.2a 19 Mar 2015 debug1: private host key: #0 type 1 RSA debug1: private host key: #1 type 2 DSA debug1: rexec_argv[0]='/usr/sbin/sshd' debug1: rexec_argv[1]='-d' debug1: rexec_argv[2]='-p' debug1: rexec_argv[3]='2222' Set /proc/self/oom_score_adj from 0 to -1000 debug1: Bind to port 2222 on 0.0.0.0. Server listening on 0.0.0.0 port 2222. debug1: Bind to port 2222 on ::. Server listening on :: port 2222. Then try to log in using port 2222. $ ssh -p 2222 dl2 That will cause the debugging sshd to print out more information. Hopefully the clues as to the problem will be there. You can increase the debug level from one -d to two -dd to three -ddd if needed for more debug verbosity. > lsh-client > lsh-server > lsh-utils As far as I know those were created at a time when there was more friction between the OpenSSL license and the GNU GPL license. It is a political philosohpical difference. While they are both free(dom) licenses they are not directly compatible. Currently GPL software that links with OpenSSL contains an exception to allow it. As far as I know the lsh project was an attempt to produce a fully GPL licensed ssh stack from top to bottom using the GnuTLS library. That would create a fully consistent license for all parts of it without any exceptions needed. But the project has floundered and OpenSSH has prospered. I stick with OpenSSH. Bob
Attachment:
signature.asc
Description: Digital signature