search for: ssh_known_hosts2

...9;. This means that users can circumvent the system policy and login from disallowed source IP addresses. Important Changes: ================== OpenSSH 2.9.9 might have upgrade issues introduced by the long time between releases, which may affect people in unforseen ways: 1) The files /etc/ssh_known_hosts2 ~/.ssh/known_hosts2 ~/.ssh/authorized_keys2 are now obsolete, you can use /etc/ssh_known_hosts ~/.ssh/known_hosts ~/.ssh/authorized_keys For backward compatibility ~/.ssh/authorized_keys2 is still used for authentication and hostkeys are still read from the known_hosts2. However, o...

I am seeing the same issues as another recent post, hostbased authentication in 3.4p1 not seeming to work. I tried the ssh-keysign.c patch posted, didn't seem to fix the problem. Details: Solaris 7, OpenSSH 3.4p1, OpenSSL 0.9.6d Key from client ssh_host_rsa_key.pub copied to server /etc/ssh/ssh_known_hosts2 with comma-separated client hostnames added to front and a blank space before rest of key entry. debug3: check_host_in_hostfile: filename /etc/ssh/ssh_known_hosts2 debug3: check_host_in_hostfile: match line 1 debug2: check_key_in_hostfiles: key ok for bester.cad.gatech.edu debug3: mm_answer_keyall...

...e been snipping too much (I hope it doesn't get stripped off by the mailing list software). Some basic configuration info: ssh_config (stripped): Host hostname.domainname.tld PreferredAuthentications hostbased,publickey,password HostbasedAuthentication yes GlobalKnownHostsFile /etc/ssh/ssh_known_hosts2 CheckHostIP yes StrictHostKeyChecking ask Protocol 2 sshd_config (stripped): Protocol 2 HostbasedAuthentication yes IgnoreRhosts no shosts.equiv (stripped): 192.168.1.5 hostname.domainname.tld + + (Last line just for testing, obviously.) ls /etc/ssh/: ssh_host_dsa_key...

...KEX_DH_GEX_GROUP debug1: dh_gen_key: priv key bits set: 124/256 debug1: bits set: 1581/3191 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug3: check_host_in_hostfile: filename /home/enfm/mikep/.ssh/known_hosts2 debug3: check_host_in_hostfile: filename /etc/ssh/ssh_known_hosts2 debug2: key_type_from_name: unknown key type '1024' debug3: key_read: no key found debug3: key_read: type mismatch debug3: check_host_in_hostfile: match line 34 debug3: check_host_in_hostfile: filename /home/enfm/mikep/.ssh/known_hosts2 debug3: check_host_in_hostfile: filename /etc/ssh/ssh_...

...hentication yes HostbasedUsesNameFromPacketOnly yes PasswordAuthentication yes # if you don't want users to add clients, you either need to stop parsing .[rs]hosts IgnoreRhosts yes # or control which hosts have trusted keys with IgnoreUserKnownHosts yes # or both AuthOrder2 hostbased:password ssh_known_hosts2: charles.dom.ain.,charles.dom.ain ssh-dss [charles_dsa_public_key] shosts.equiv: charles.dom.ain charles.dom.ain. NOTE: trailing dot form included in ssh_known_hosts2 and shosts.equiv to work around a bug in the current codebase. On charles: ssh must have access to ssh_host_dsa_key. For now...

...passwords or per-user keys. My /etc/ssh/sshd_config contains: [...] IgnoreRhosts no HostbasedAuthentication yes [...] My /etc/ssh/ssh_config contains: [...] HostbasedAuthentication yes [...] I created the known hosts file like so: box1# cd /etc/ssh box1# cp ssh_host_dsa_key.pub ssh_known_hosts2 I replicated the config directory: box2# rm -rf /etc/ssh box2# mkdir /etc/ssh box2# chown 0755 /etc/ssh box2# rcp box1:/etc/ssh/* /etc/ssh I restarted the daemons: box1# /sbin/service sshd restart box2# /sbin/service sshd restart Here's the client debugging output: [...] debug...

...Fl v46 +.Op Fl T Ar timeout +.Op Fl t Ar type +.Op Fl - +.Op Ar host | addrlist namelist +.Op Fl f Ar files +.Op Ar ... .Sh DESCRIPTION .Nm is a utility for gathering the public ssh host keys of a number of hosts. It was designed to aid in building and verifying .Pa ssh_known_hosts +and +.Pa ssh_known_hosts2 files. .Nm provides a minimal interface suitable for use by shell and perl @@ -46,14 +52,43 @@ have begun after you created your ssh_known_hosts file. .Sh OPTIONS .Bl -tag -width Ds -.It Fl t +.It Fl v +Verbose mode. +Causes +.Nm +to print debugging messages about its progress. +.It Fl 4 +For...

...erac/etc/sshd_config (comments removed): --------------------------------------------- Protocol 2 PermitRootLogin yes StrictModes yes HostBasedAuthentication yes HostbasedUsesNameFromPacketOnly yes X11Forwarding yesq X11DisplayOffset 400 Subsystem sftp /opt/erac//libexec/sftp-server /opt/erac/etc/ssh_known_hosts2: ------------------------------- evereska,evereska.wan.erac.com,10.49.191.9,evereska. ssh-dss ... evereska,evereska.wan.erac.com,10.49.191.9,evereska. ssh-rsa ... /etc/shosts.equiv (chmod 444) ----------------------------: evereska evereska. 10.49.191.9 evereska.wan.erac.com CLIENT: /opt/erac/e...

..._config tyr fd1026 65 cd /usr/local/etc/ssh tyr ssh 66 grep ssh_host *config sshd_config:HostKey /etc/ssh/ssh_host_key sshd_config:HostKey /etc/ssh/ssh_host_rsa_key sshd_config:HostKey /etc/ssh/ssh_host_dsa_key tyr ssh 67 grep ssh_known *config ssh_config:GlobalKnownHostsFile2 /usr/local/etc/ssh/ssh_known_hosts2 sshd_config:# /usr/local/etc/ssh/ssh_known_hosts Now we created ~/.shosts and tried a connection. Unfortunately we always had to present a password. Debugging ssh and sshd didn't solve the problem. At least we tried to insert some links into /usr/local/etc/ssh ssh_host_dsa_key -> /etc/s...

...SG_KEX_DH_GEX_GROUP debug1: dh_gen_key: priv key bits set: 130/256 debug1: bits set: 1600/3191 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug3: check_host_in_hostfile: filename /home/mattbee/.ssh/known_hosts2 debug3: check_host_in_hostfile: filename /etc/ssh/ssh_known_hosts2 debug3: check_host_in_hostfile: filename /home/mattbee/.ssh/known_hosts2 debug3: check_host_in_hostfile: filename /etc/ssh/ssh_known_hosts2 debug3: check_host_in_hostfile: filename /home/mattbee/.ssh/known_hosts debug3: check_host_in_hostfile: match line 250 debug3: check_host_in_hostfile: filename...

...ile: filename /opt/erac/etc/ssh_known_hosts debug1: temporarily_use_uid: 503/5005 (e=0) debug3: check_host_in_hostfile: filename /export/home/rjl01/.ssh/known_hosts debug1: restore_uid debug2: check_key_in_hostfiles: key not found for evereska. debug3: check_host_in_hostfile: filename /opt/erac/etc/ssh_known_hosts2 debug3: key_read: type mismatch debug1: temporarily_use_uid: 503/5005 (e=0) debug3: check_host_in_hostfile: filename /export/home/rjl01/.ssh/known_hosts2 debug1: restore_uid debug2: check_key_in_hostfiles: key not found for evereska. debug3: mm_answer_keyallowed: key 1245e0 is disallowed debug3: mm...

...ns the problem! ;-) So, I guess we can force all our clients or servers to be version 1 for now, but does anyone have any idea when hostbased authentication will be implemented in the version 2 support? Also, the openssh documentation implies that this SHOULD work (talks about ssh_known_hosts and ssh_known_hosts2 quite interchangeably). Any chance that the documentation can be ammended until version 2 support for trusted-host authentication is actually added? It might save some frustration... Many thanks, Brent Nelson Sys. Manager Dept. of Physics University of Florida

When using "HostbasedUsesNameFromPacketOnly yes", the ssh client sends the hostname with a trailing dot, but the server does not strip off the trailing dot when matching against .shosts et. al., or when looking up keys in ssh_known_hosts2. This causes the host to not be found. Adding the hostname with trailing dot to the config files "fixes" this, but I think sshd should do this itself. If you like, I can try to gen a patch. I thought I'd ask first, in case major restructuring was going to occur in this code. --...

I am trying to generate a ssh_known_hosts2 file, 2.9.9p2, using: ssh-keyscan -f list_of_hosts -t rsa > ssh_known_hosts.rsa and ssh-keyscan -f list_of_hosts -t dsa > ssh_known_hosts.dsa but both commands fail almost immidiately with: Couldn't obtain random bytes (error 604389476) What could that mean? Servers that I am aware of...

...nn That is followed by the usual Accepted hostbased for xxx from nnn.nnn.nnn.nnn and the host based authentication continues to work correctly despite the new "Failed hostbased..." message. Running sshd in debug shows that 4.4p1 tries a DSA host key ahead of the RSA host key. /etc/ssh/ssh_known_hosts2 only contains RSA keys, and 4.3p1 (and previous) OpenSSH versions did not produce any errors. Is checking DSA keys ahead of RSA keys new in 4.4p1, or is this just a logging change of a previously unreported error? Thanks Ric Anderson (ric at ms.telcom.arizona.edu)

...: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug1: dh_gen_key: priv key bits set: 128/256 debug1: bits set: 1016/2049 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug1: Host 'foobar' is known and matches the DSA host key. debug1: Found key in /etc/ssh/ssh_known_hosts2:201 debug1: bits set: 995/2049 debug1: len 55 datafellows 0 debug1: ssh_dss_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: SSH2_MSG_NEWKEYS received debug1: done:...

...ebug2: fd 4 setting O_NONBLOCK debug1: Authenticating to localhost:22 as 'bsradmin' debug1: load_hostkeys: fopen /home/bsradmin/.ssh/known_hosts2: No such file or directory debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or directory debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or directory debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: local client KEXINIT proposal debug2: KEX algorithms: sntrup761x25519-sha512 at openssh.com,curve25519-sha256,curve25519-sha256 at libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,d...

...). We would like to thank the OpenSSH community for their continued support and encouragement. Important Changes: ================== 1) SSH protocol v2 is now the default protocol version use the 'Protocol' option from ssh(1) and sshd(8) if you need to change this. 2) The files /etc/ssh_known_hosts2 ~/.ssh/known_hosts2 ~/.ssh/authorized_keys2 are now obsolete, you can use /etc/ssh_known_hosts ~/.ssh/known_hosts ~/.ssh/authorized_keys For backward compatibility ~/.ssh/authorized_keys2 will still used for authentication and hostkeys are still read from the known_hosts2. However,...

...g3: check_host_in_hostfile: filename /gosbee/.ssh/known_hosts debug3: check_host_in_hostfile: filename /usr/local/etc/ssh_known_hosts debug2: no key of type 0 for host 10.4.0.8 debug3: check_host_in_hostfile: filename /gosbee/.ssh/known_hosts2 debug3: check_host_in_hostfile: filename /usr/local/etc/ssh_known_hosts2 debug3: check_host_in_hostfile: filename /gosbee/.ssh/known_hosts debug3: check_host_in_hostfile: filename /usr/local/etc/ssh_known_hosts debug2: no key of type 2 for host 10.4.0.8 debug1: read_passphrase: can't open /dev/tty: No such device or address Host key verification failed.

is anyone using rhost-rsa + hosts.equiv? is it broken? -------------- next part -------------- An embedded message was scrubbed... From: Francesc Guasch <frankie at etsetb.upc.es> Subject: hosts.equiv Date: Thu, 22 Mar 2001 12:56:22 +0100 Size: 2614 Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20010322/ced5a345/attachment.mht