|
Prev: rsync prob on solaris 5.8
Next: netboot fun with a U10
From: ns on 19 Apr 2005 10:27 Hi all, I installed OpenSSH (openssh-4.0p1-sol8-sparc-local.gz) on Solaris 8. All work fine (ssh, sftp, scp...etc) In the same server, i used rsh to execute remote command by using .rhosts. I will delete rsh and use ssh. By using SSH, i juste need to execute remote command by using .rhosts or ..shosts. It's work fine, but the system ask me password. The system seem ignore ..rhosts and .shosts files. I confirm that rsh no ask me the user password, so the configuration of ..rhosts is good ! and .shosts is "cp -p" of .rhosts. I tried to modify options on ssh_config (HostbasedAuthentication yes, IgnoreRhosts no) but it's not work. I olso tried with options RhostsRSAAuthentification and RhostsAuthentification but the system always ask me password. So, i juste need to use ssh to execute command command on remote host without ask me password. I known, it's not secure but, i need to know how can i do it. Any idea ? Thank You very much for your help Best Regards NS
From: Robert Lawhead on 19 Apr 2005 11:08 For HistbasedAuthentication to work, you'll need an shost.equiv file, do you have one configured? Here is a snippet from the sshd man page: /etc/ssh/shosts.equiv This is processed exactly as /etc/hosts.equiv. However, this file may be useful in environments that want to run both rsh/rlogin and ssh. - Bob ns wrote: > Hi all, > > I installed OpenSSH (openssh-4.0p1-sol8-sparc-local.gz) on Solaris 8. > All work fine (ssh, sftp, scp...etc) > > In the same server, i used rsh to execute remote command by using .rhosts. I > will delete rsh and use ssh. > > By using SSH, i juste need to execute remote command by using .rhosts or > .shosts. > It's work fine, but the system ask me password. The system seem ignore > .rhosts and .shosts files. > > I confirm that rsh no ask me the user password, so the configuration of > .rhosts is good ! and .shosts is "cp -p" of .rhosts. > > I tried to modify options on ssh_config (HostbasedAuthentication yes, > IgnoreRhosts no) but it's not work. I olso tried with options > RhostsRSAAuthentification and RhostsAuthentification but the system always > ask me password. > > So, i juste need to use ssh to execute command command on remote host > without ask me password. I known, it's not secure but, i need to know how > can i do it. > > Any idea ? > > Thank You very much for your help > > Best Regards > NS > >
From: Dave Uhring on 19 Apr 2005 14:03 On Tue, 19 Apr 2005 16:19:00 +0100, Richard Skelton wrote: > # cat id_rsa.pub > $HOME/.ssh/authorized_keys Ummmm, I think you mean $ scp id_rsa.pub server:$HOME/.ssh/authorized_keys
From: Robert Lawhead on 19 Apr 2005 14:42 Dave Uhring wrote: > On Tue, 19 Apr 2005 16:19:00 +0100, Richard Skelton wrote: > > >># cat id_rsa.pub > $HOME/.ssh/authorized_keys > > > Ummmm, I think you mean > > $ scp id_rsa.pub server:$HOME/.ssh/authorized_keys > Interesting... I've always used .ssh/authorized_keys2 for ssh2 keys like rsa and dsa, and thought that .ssh/authorized_keys was only for rsa1 keys. However the ssh man page references ..ssh/authorized_keys for rsa and dsa keys; YET trussing sshd for an ssh2 connection I see indeed that it is .ssh/authorized_keys2 that is checked. Moreover, if sshd is only serving protocol 2 and .ssh/authorized_keys2 is absent and .ssh/authorized_keys includes the ssh2 keys, public key authentication fails. This leads me to believe that the man page is confusing at best. I'd suggest using only ssh2 & putting your keys in ssh/authorized_keys2. None of this matters though for HostBasedAuthentication. What matters there is that the respective hosts' (not users) public keys are known to the respective hosts (usually in /etc/ssh/ssh_known_hosts(2)). - Bob
From: Robert Lawhead on 19 Apr 2005 16:30
In my previous post, I indended to append my .ssh/authorized_keys2 to my .ssh/authorized_keys file and delete .ssh/authorized_keys2. Unfortunately, I mispelled "authorized_keys" so my observation led me to the wrong conclusion. Sorry for the noise. Starting sshd in debug mode shows that both files are consulted, and finding an appropriate key in either is adequate. debug1: temporarily_use_uid: 500/1 (e=0/0) debug1: trying public key file /u/foo/.ssh/authorized_keys debug1: restore_uid: 0/0 debug1: temporarily_use_uid: 500/1 (e=0/0) debug1: trying public key file /u/foo/.ssh/authorized_keys2 debug1: restore_uid: 0/0 Failed publickey for foo from 192.168.1.61 port 2819 ssh2 debug1: userauth-request for user foo service ssh-connection method publickey debug1: attempt 2 initial attempt 0 failures 2 initial failures 0 debug1: test whether pkalg/pkblob are acceptable debug1: temporarily_use_uid: 500/1 (e=0/0) debug1: trying public key file /u/foo/.ssh/authorized_keys debug1: matching key found: file /u/foo/.ssh/authorized_keys, line 6 Found matching DSA key: 96:5a:df:ce:c7:d7:57:7b:7b:d7:3a:b7:b2:f8:ba:22 debug1: restore_uid: 0/0 debug1: userauth-request for user foo service ssh-connection method publickey debug1: attempt 3 initial attempt 0 failures 2 initial failures 0 debug1: temporarily_use_uid: 500/1 (e=0/0) debug1: trying public key file /u/foo/.ssh/authorized_keys debug1: matching key found: file /u/foo/.ssh/authorized_keys, line 6 Found matching DSA key: 96:5a:df:ce:c7:d7:57:7b:7b:d7:3a:b7:b2:f8:ba:22 debug1: restore_uid: 0/0 debug1: ssh_dss_verify: signature correct Accepted publickey for foo from 192.168.1.61 port 2819 ssh2 debug1: temporarily_use_uid: 500/1 (e=0/0) debug1: trying public key file /u/foo/.ssh/authorized_keys debug1: restore_uid: 0/0 debug1: temporarily_use_uid: 500/1 (e=0/0) debug1: trying public key file /u/foo/.ssh/authorized_keys2 debug1: restore_uid: 0/0 Failed publickey for foo from 192.168.1.61 port 2819 ssh2 debug1: userauth-request for user foo service ssh-connection method publickey debug1: attempt 2 initial attempt 0 failures 2 initial failures 0 debug1: test whether pkalg/pkblob are acceptable debug1: temporarily_use_uid: 500/1 (e=0/0) debug1: trying public key file /u/foo/.ssh/authorized_keys debug1: matching key found: file /u/foo/.ssh/authorized_keys, line 6 Found matching DSA key: 96:5a:df:ce:c7:d7:57:7b:7b:d7:3a:b7:b2:f8:ba:22 debug1: restore_uid: 0/0 debug1: userauth-request for user foo service ssh-connection method publickey debug1: attempt 3 initial attempt 0 failures 2 initial failures 0 debug1: temporarily_use_uid: 500/1 (e=0/0) debug1: trying public key file /u/foo/.ssh/authorized_keys debug1: matching key found: file /u/foo/.ssh/authorized_keys, line 6 Found matching DSA key: 96:5a:df:ce:c7:d7:57:7b:7b:d7:3a:b7:b2:f8:ba:22 debug1: restore_uid: 0/0 debug1: ssh_dss_verify: signature correct Accepted publickey for foo from 192.168.1.61 port 2819 ssh2 Both Openssh and Sun's ssh permit the authorized_keys(2) file to be specified in sshd_config, albiet with slightly differing strings. So the surprise to me was even with both specified, that authorized_keys would be searched for ssh2 keys. OpenSSH_4.0p1, OpenSSL 0.9.7e 25 Oct 2004 % strings /usr/local/sbin/sshd | grep -i Authorized | sort -u .ssh/authorized_keys .ssh/authorized_keys2 authorized_keys_file authorized_keys_file2 authorizedkeysfile authorizedkeysfile2 sshd version Sun_SSH_1.1 % strings /usr/lib/ssh/sshd | grep -i Authorized | sort -u .ssh/authorized_keys .ssh/authorized_keys2 authorizedkeysfile authorizedkeysfile2 Dave Uhring wrote: > > The original version of OpenSSH from which Sun's version is derived has > this default in /etc/ssh/sshd_config: > > #AuthorizedKeysFile .ssh/authorized_keys > > Solaris 10 does not specify that file in its config. Yet from a Linux box > to Solaris: .. .. |