glebspy
asked on
ssh not permitting login without password despite key generation
I have two computers A and B on a home LAN, I need to be able to ssh between them without a password prompt appearing.
They are both Mandrake 9.0 laptops, OS virtually identical although one was upgraded from Mandrake 8.1 and is about three years older.
Both are running the same version of ssh:
OpenSSH_3.4p1, SSH protocols 1.5/2.0, OpenSSL 0x0090607f
I used ssh-keygen -t dsa on each machine to create private and public keys. I then appended A's public key to B's .ssh/authorized_hosts file, and vice versa. That permitted passwordless A->B access, but going in the other direction B->A it still asked for a password.
I cleared everything out and tried it again using -t rsa. The exact same situation occured.
Any ideas?
They are both Mandrake 9.0 laptops, OS virtually identical although one was upgraded from Mandrake 8.1 and is about three years older.
Both are running the same version of ssh:
OpenSSH_3.4p1, SSH protocols 1.5/2.0, OpenSSL 0x0090607f
I used ssh-keygen -t dsa on each machine to create private and public keys. I then appended A's public key to B's .ssh/authorized_hosts file, and vice versa. That permitted passwordless A->B access, but going in the other direction B->A it still asked for a password.
I cleared everything out and tried it again using -t rsa. The exact same situation occured.
Any ideas?
ASKER
Thanks for your comment MrAhmad and good luck in answering questions in the future.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
jlevie
Thanks, but.. I followed your suggestion and, after generating rsa keys, copied them to authorized_keys2 as well as authorized_keys, it was the same behaviour (different between the two machines). Any other suggestions?
Thanks, but.. I followed your suggestion and, after generating rsa keys, copied them to authorized_keys2 as well as authorized_keys, it was the same behaviour (different between the two machines). Any other suggestions?
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
get rid of $HOME/.ssh (so we can have a clean start), then try the followings:
on machineA for userA do the following
1. Login as userA on machineA and run the following commands
$ssh-keygen -N '' -t dsa
$ssh-keygen -N '' -t rsa
Note : Accept the default
The above would generate 4 files under $HOME/.ssh
id_dsa
id_dsa.pub
id_rsa
id_rsa.pub
cd $HOME/.ssh
cat id_dsa.pub > authorized_keys
cat id_rsa.pub >> authorized_keys
rm id_dsa.pub id_rsa.pub
chmod 700 authorized_keys
2. Copy this authorized_keys (which u created as above) to the home dir of the destination machine.
3. You should be able to execute the commands on dest host without asking for password.
on machineA for userA do the following
1. Login as userA on machineA and run the following commands
$ssh-keygen -N '' -t dsa
$ssh-keygen -N '' -t rsa
Note : Accept the default
The above would generate 4 files under $HOME/.ssh
id_dsa
id_dsa.pub
id_rsa
id_rsa.pub
cd $HOME/.ssh
cat id_dsa.pub > authorized_keys
cat id_rsa.pub >> authorized_keys
rm id_dsa.pub id_rsa.pub
chmod 700 authorized_keys
2. Copy this authorized_keys (which u created as above) to the home dir of the destination machine.
3. You should be able to execute the commands on dest host without asking for password.
If you still have problem, check your sshd_config in both boxes, and make sure you have:
RSAAuthentication yes
PubkeyAuthentication yes
RSAAuthentication yes
PubkeyAuthentication yes
why do you need to eliminate the passwords?
assuming that eliminating the passwords is a solution to a different problem, maybe there's an alternative solution to the "real" problem.
assuming that eliminating the passwords is a solution to a different problem, maybe there's an alternative solution to the "real" problem.
ASKER
I did exactly what you said yuzh, and it still doesnt work. I made sure the sshd options were right, and I even diffed the /etc/ssh/ssh_config and /etc/ssh/sshd_config files between the two machines. They were identical.
Philjones85 thank you very much for your contribution and good luck with answering other questions.
Philjones85 thank you very much for your contribution and good luck with answering other questions.
If you modified any of /etc/ssh/ssh_config file, you need to restart sshd.
BTY, which version of secure shell are you using? (Are the two boxes running the same version of ssh?)
BTY, which version of secure shell are you using? (Are the two boxes running the same version of ssh?)
ASKER
I didn't modify it, just looked!
The boxes are both running the same version of ssh. The version is:
OpenSSH_3.4p1, SSH protocols 1.5/2.0, OpenSSL 0x0090607f
The boxes are both running the same version of ssh. The version is:
OpenSSH_3.4p1, SSH protocols 1.5/2.0, OpenSSL 0x0090607f
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Sorry the step 2 in my previous comment might case a confusion:
2. Copy this authorized_keys (which u created as above) to the home dir of the destination machine
It should be:
2. Copy this authorized_keys (which u created as above) to $HOME/.ssh dir of the destination machine
2. Copy this authorized_keys (which u created as above) to the home dir of the destination machine
It should be:
2. Copy this authorized_keys (which u created as above) to $HOME/.ssh dir of the destination machine
If you still have problem.
try to use the filename authorized_keys2 instead of authorized_keys (in case you are runing ssh2)
try to use the filename authorized_keys2 instead of authorized_keys (in case you are runing ssh2)
ASKER
I know authorized_keys should be in the ssh2 directory.
I have tried both authorized_keys and authorized_keys2, it still doesn't work.
There are some differences between PabloUraguay's sshd_config and mine. But my sshd_config file is *the same on both of my machines* and it works in one direction but not the other, so I don't think this could be the problem.
Differences between my sshd_config and PabloUraguay's sshd_config:
SyslogFacility Me:AUTH PabloUraguay:SyslogFacilit
PermitRootLogin Me: yes PabloUraguay:PermitRootLog
RSAAuthentication Me: yes PabloUraguay:RSAAuthentica
AuthorizedKeysFile Me:.ssh/authorized_keys PabloUraguay: .ssh/authorized_keys2
IgnoreUserKnownHosts Me:no Pablo:yes
PasswordAuthentication Me:yes Pablo:no
ChallengeResponseAuthentic
KerberosOrLocalPassword Me:yes Pablo:no
KerberosTicketCleanup Me:yes Pablo:no
I repeat that my options work on one of my computers but not on the other.
I have tried both authorized_keys and authorized_keys2, it still doesn't work.
There are some differences between PabloUraguay's sshd_config and mine. But my sshd_config file is *the same on both of my machines* and it works in one direction but not the other, so I don't think this could be the problem.
Differences between my sshd_config and PabloUraguay's sshd_config:
SyslogFacility Me:AUTH PabloUraguay:SyslogFacilit
PermitRootLogin Me: yes PabloUraguay:PermitRootLog
RSAAuthentication Me: yes PabloUraguay:RSAAuthentica
AuthorizedKeysFile Me:.ssh/authorized_keys PabloUraguay: .ssh/authorized_keys2
IgnoreUserKnownHosts Me:no Pablo:yes
PasswordAuthentication Me:yes Pablo:no
ChallengeResponseAuthentic
KerberosOrLocalPassword Me:yes Pablo:no
KerberosTicketCleanup Me:yes Pablo:no
I repeat that my options work on one of my computers but not on the other.
ok this diferences are because my server is absolute restricted to DSA keys, no root login no passwords no anything, only DSA keys, only for security. if you have password yes the machine ask the password if you select NO the server ask for DSA or RSA keys, and is the rigth solution, also check the authorized_keys or authorized_keys2 perm, you need yo have this perms in this file
-rw-r--r-- 1 pablo pablo 1817 Jun 19 13:59 authorized_keys2
the diferenece between authorized_key* is only for the ssh version, you can change this in the config, the names are trivial if you call from sshd_config
If you need to keep the password entrance you need to move the passwordAuth to the bottom of the line. but i dont know is this function, i recommend for max. security only manage your box with KEYS no with passwd, and the Peritrootlogin put in NO please., is high unsecure option, after you stay inside the system change with su
-rw-r--r-- 1 pablo pablo 1817 Jun 19 13:59 authorized_keys2
the diferenece between authorized_key* is only for the ssh version, you can change this in the config, the names are trivial if you call from sshd_config
If you need to keep the password entrance you need to move the passwordAuth to the bottom of the line. but i dont know is this function, i recommend for max. security only manage your box with KEYS no with passwd, and the Peritrootlogin put in NO please., is high unsecure option, after you stay inside the system change with su
ASKER
Thanks for the advice. Does anyone have any more ideas about why it isn't working?
ASKER
Ok I have had an which might give some clues. I ran ssh in both the working direction and the not-working direction, with the -v option (verbose). I recorded the output. Here is is.
WORKING VERSION (ssh to machine kairakuen from machine pajama)
OpenSSH_3.4p1, SSH protocols 1.5/2.0, OpenSSL 0x0090607f
debug1: Reading configuration data /etc/ssh/ssh_config^M
debug1: Applying options for *^M
debug1: Rhosts Authentication disabled, originating port will not be trusted.^M
debug1: ssh_connect: needpriv 0^M
debug1: Connecting to kairakuen [192.168.1.12] port 22.^M
debug1: Connection established.^M
debug1: identity file /home/vil/.ssh/identity type -1^M
debug1: identity file /home/vil/.ssh/id_rsa type -1^M
debug1: identity file /home/vil/.ssh/id_dsa type -1^M
debug1: Remote protocol version 1.99, remote software version OpenSSH_3.4p1^M
debug1: match: OpenSSH_3.4p1 pat OpenSSH*^M
Enabling compatibility mode for protocol 2.0^M
debug1: Local version string SSH-2.0-OpenSSH_3.4p1^M
debug1: SSH2_MSG_KEXINIT sent^M
debug1: SSH2_MSG_KEXINIT received^M
debug1: kex: server->client aes128-cbc hmac-md5 none^M
debug1: kex: client->server aes128-cbc hmac-md5 none^M
debug1: SSH2_MSG_KEX_DH_GEX_REQUES
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP^
debug1: dh_gen_key: priv key bits set: 125/256^M
debug1: bits set: 1587/3191^M
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent^M
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY^
debug1: Host 'kairakuen' is known and matches the RSA host key.^M
debug1: Found key in /home/vil/.ssh/known_hosts
debug1: bits set: 1612/3191^M
debug1: ssh_rsa_verify: signature correct^M
debug1: kex_derive_keys^M
debug1: newkeys: mode 1^M
debug1: SSH2_MSG_NEWKEYS sent^M
debug1: waiting for SSH2_MSG_NEWKEYS^M
debug1: newkeys: mode 0^M
debug1: SSH2_MSG_NEWKEYS received^M
debug1: done: ssh_kex2.^M
debug1: send SSH2_MSG_SERVICE_REQUEST^M
debug1: service_accept: ssh-userauth^M
debug1: got SSH2_MSG_SERVICE_ACCEPT^M
debug1: authentications that can continue: publickey,password,keyboar
debug1: next auth method to try is publickey^M
ebug1: try privkey: /home/vil/.ssh/identity^M
debug1: try privkey: /home/vil/.ssh/id_rsa^M
debug1: read PEM private key done: type RSA^M
debug1: ssh-userauth2 successful: method publickey^M
debug1: fd 5 setting O_NONBLOCK^M
debug1: channel 0: new [client-session]^M
debug1: send channel open 0^M
debug1: Entering interactive session.^M
debug1: ssh_session2_setup: id 0^M
debug1: channel request 0: pty-req^M
debug1: Requesting X11 forwarding with authentication spoofing.^M
debug1: channel request 0: x11-req^M
debug1: channel request 0: shell^M
debug1: fd 3 setting TCP_NODELAY^M
debug1: channel 0: open confirm rwindow 0 rmax 32768^M
^[[36l^[>Warning - PVM_ROOT not defined^M
To use PVM, define PVM_ROOT and rerun your .bashrc^M
-bash: /lib/pvmgetarch: No such file or directory^M
^[]0;vil@kairakuen: /home/vil^G[vil@kairakuen vil]$ ^M
(success)
NOT WORKING VERSION (ssh to machine pajama from machine kairakuen)
OpenSSH_3.4p1, SSH protocols 1.5/2.0, OpenSSL 0x0090607f
debug1: Reading configuration data /etc/ssh/ssh_config^M
debug1: Applying options for *^M
debug1: Rhosts Authentication disabled, originating port will not be trusted.^M
debug1: ssh_connect: needpriv 0^M
debug1: Connecting to pajama [192.168.1.13] port 22.^M
debug1: Connection established.^M
debug1: identity file /home/vil/.ssh/identity type -1^M
debug1: identity file /home/vil/.ssh/id_rsa type -1^M
debug1: identity file /home/vil/.ssh/id_dsa type -1^M
debug1: Remote protocol version 1.99, remote software version OpenSSH_3.4p1^M
debug1: match: OpenSSH_3.4p1 pat OpenSSH*^M
Enabling compatibility mode for protocol 2.0^M
debug1: Local version string SSH-2.0-OpenSSH_3.4p1^M
debug1: SSH2_MSG_KEXINIT sent^M
debug1: SSH2_MSG_KEXINIT received^M
debug1: kex: server->client aes128-cbc hmac-md5 none^M
debug1: kex: client->server aes128-cbc hmac-md5 none^M
debug1: SSH2_MSG_KEX_DH_GEX_REQUES
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP^
debug1: dh_gen_key: priv key bits set: 136/256^M
debug1: bits set: 1552/3191^M
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent^M
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY^
debug1: Host 'pajama' is known and matches the RSA host key.^M
debug1: Found key in /home/vil/.ssh/known_hosts
debug1: bits set: 1540/3191^M
debug1: ssh_rsa_verify: signature correct^M
debug1: kex_derive_keys^M
debug1: newkeys: mode 1^M
debug1: SSH2_MSG_NEWKEYS sent^M
debug1: waiting for SSH2_MSG_NEWKEYS^M
debug1: newkeys: mode 0^M
debug1: SSH2_MSG_NEWKEYS received^M
debug1: done: ssh_kex2.^M
debug1: send SSH2_MSG_SERVICE_REQUEST^M
debug1: service_accept: ssh-userauth^M
debug1: got SSH2_MSG_SERVICE_ACCEPT^M
debug1: authentications that can continue: publickey,password,keyboar
debug1: next auth method to try is publickey^M
debug1: try privkey: /home/vil/.ssh/identity^M
debug1: try privkey: /home/vil/.ssh/id_rsa^M
debug1: read PEM private key done: type RSA^M
debug1: authentications that can continue: publickey,password,keyboar
debug1: try privkey: /home/vil/.ssh/id_dsa^M
debug1: read PEM private key done: type DSA^M
debug1: authentications that can continue: publickey,password,keyboar
debug1: next auth method to try is keyboard-interactive^M
debug1: authentications that can continue: publickey,password,keyboar
debug1: next auth method to try is password^M
(failure:it asks for password authentication here)
Most of the output is the same in both cases, but they diverge at a certain point. Can you figure out what is going on?
WORKING VERSION (ssh to machine kairakuen from machine pajama)
OpenSSH_3.4p1, SSH protocols 1.5/2.0, OpenSSL 0x0090607f
debug1: Reading configuration data /etc/ssh/ssh_config^M
debug1: Applying options for *^M
debug1: Rhosts Authentication disabled, originating port will not be trusted.^M
debug1: ssh_connect: needpriv 0^M
debug1: Connecting to kairakuen [192.168.1.12] port 22.^M
debug1: Connection established.^M
debug1: identity file /home/vil/.ssh/identity type -1^M
debug1: identity file /home/vil/.ssh/id_rsa type -1^M
debug1: identity file /home/vil/.ssh/id_dsa type -1^M
debug1: Remote protocol version 1.99, remote software version OpenSSH_3.4p1^M
debug1: match: OpenSSH_3.4p1 pat OpenSSH*^M
Enabling compatibility mode for protocol 2.0^M
debug1: Local version string SSH-2.0-OpenSSH_3.4p1^M
debug1: SSH2_MSG_KEXINIT sent^M
debug1: SSH2_MSG_KEXINIT received^M
debug1: kex: server->client aes128-cbc hmac-md5 none^M
debug1: kex: client->server aes128-cbc hmac-md5 none^M
debug1: SSH2_MSG_KEX_DH_GEX_REQUES
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP^
debug1: dh_gen_key: priv key bits set: 125/256^M
debug1: bits set: 1587/3191^M
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent^M
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY^
debug1: Host 'kairakuen' is known and matches the RSA host key.^M
debug1: Found key in /home/vil/.ssh/known_hosts
debug1: bits set: 1612/3191^M
debug1: ssh_rsa_verify: signature correct^M
debug1: kex_derive_keys^M
debug1: newkeys: mode 1^M
debug1: SSH2_MSG_NEWKEYS sent^M
debug1: waiting for SSH2_MSG_NEWKEYS^M
debug1: newkeys: mode 0^M
debug1: SSH2_MSG_NEWKEYS received^M
debug1: done: ssh_kex2.^M
debug1: send SSH2_MSG_SERVICE_REQUEST^M
debug1: service_accept: ssh-userauth^M
debug1: got SSH2_MSG_SERVICE_ACCEPT^M
debug1: authentications that can continue: publickey,password,keyboar
debug1: next auth method to try is publickey^M
ebug1: try privkey: /home/vil/.ssh/identity^M
debug1: try privkey: /home/vil/.ssh/id_rsa^M
debug1: read PEM private key done: type RSA^M
debug1: ssh-userauth2 successful: method publickey^M
debug1: fd 5 setting O_NONBLOCK^M
debug1: channel 0: new [client-session]^M
debug1: send channel open 0^M
debug1: Entering interactive session.^M
debug1: ssh_session2_setup: id 0^M
debug1: channel request 0: pty-req^M
debug1: Requesting X11 forwarding with authentication spoofing.^M
debug1: channel request 0: x11-req^M
debug1: channel request 0: shell^M
debug1: fd 3 setting TCP_NODELAY^M
debug1: channel 0: open confirm rwindow 0 rmax 32768^M
^[[36l^[>Warning - PVM_ROOT not defined^M
To use PVM, define PVM_ROOT and rerun your .bashrc^M
-bash: /lib/pvmgetarch: No such file or directory^M
^[]0;vil@kairakuen: /home/vil^G[vil@kairakuen vil]$ ^M
(success)
NOT WORKING VERSION (ssh to machine pajama from machine kairakuen)
OpenSSH_3.4p1, SSH protocols 1.5/2.0, OpenSSL 0x0090607f
debug1: Reading configuration data /etc/ssh/ssh_config^M
debug1: Applying options for *^M
debug1: Rhosts Authentication disabled, originating port will not be trusted.^M
debug1: ssh_connect: needpriv 0^M
debug1: Connecting to pajama [192.168.1.13] port 22.^M
debug1: Connection established.^M
debug1: identity file /home/vil/.ssh/identity type -1^M
debug1: identity file /home/vil/.ssh/id_rsa type -1^M
debug1: identity file /home/vil/.ssh/id_dsa type -1^M
debug1: Remote protocol version 1.99, remote software version OpenSSH_3.4p1^M
debug1: match: OpenSSH_3.4p1 pat OpenSSH*^M
Enabling compatibility mode for protocol 2.0^M
debug1: Local version string SSH-2.0-OpenSSH_3.4p1^M
debug1: SSH2_MSG_KEXINIT sent^M
debug1: SSH2_MSG_KEXINIT received^M
debug1: kex: server->client aes128-cbc hmac-md5 none^M
debug1: kex: client->server aes128-cbc hmac-md5 none^M
debug1: SSH2_MSG_KEX_DH_GEX_REQUES
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP^
debug1: dh_gen_key: priv key bits set: 136/256^M
debug1: bits set: 1552/3191^M
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent^M
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY^
debug1: Host 'pajama' is known and matches the RSA host key.^M
debug1: Found key in /home/vil/.ssh/known_hosts
debug1: bits set: 1540/3191^M
debug1: ssh_rsa_verify: signature correct^M
debug1: kex_derive_keys^M
debug1: newkeys: mode 1^M
debug1: SSH2_MSG_NEWKEYS sent^M
debug1: waiting for SSH2_MSG_NEWKEYS^M
debug1: newkeys: mode 0^M
debug1: SSH2_MSG_NEWKEYS received^M
debug1: done: ssh_kex2.^M
debug1: send SSH2_MSG_SERVICE_REQUEST^M
debug1: service_accept: ssh-userauth^M
debug1: got SSH2_MSG_SERVICE_ACCEPT^M
debug1: authentications that can continue: publickey,password,keyboar
debug1: next auth method to try is publickey^M
debug1: try privkey: /home/vil/.ssh/identity^M
debug1: try privkey: /home/vil/.ssh/id_rsa^M
debug1: read PEM private key done: type RSA^M
debug1: authentications that can continue: publickey,password,keyboar
debug1: try privkey: /home/vil/.ssh/id_dsa^M
debug1: read PEM private key done: type DSA^M
debug1: authentications that can continue: publickey,password,keyboar
debug1: next auth method to try is keyboard-interactive^M
debug1: authentications that can continue: publickey,password,keyboar
debug1: next auth method to try is password^M
(failure:it asks for password authentication here)
Most of the output is the same in both cases, but they diverge at a certain point. Can you figure out what is going on?
you have a problem, the ssh not found or not the rigth perms. the best way to test this is, set to NO the password auth. and try to modified the keys perms and location.....
ASKER
I already did that, but it didnt help. Thanks. Any other ideas?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
sorry, that didn't help. Anything else?
ASKER
ok it *did* help. I understand now that I must have been overwriting something during the scp.
Thanks for all your help - it was really important to me that I got this working.
Thanks for all your help - it was really important to me that I got this working.
its very bad to make no password (even in home LAN)