Advanced
Mailing List Archive

Mailing List Archive

  1. Home >
  2. OpenSSH>
  3. Bugs
[Bug 1213] ssh-keyscan exits in mid-way
bugzilla-daemon at mindrot
Oct 1, 2006, 1:39 PM
Post #1 of 2 (448 views)
Permalink
http://bugzilla.mindrot.org/show_bug.cgi?id=1213


paul@cypherpunks.ca changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |paul@cypherpunks.ca




------- Comment #1 from paul@cypherpunks.ca 2006-10-02 06:39 -------
I was going to open a new bug report, but I think I am reporting the
same bug as this one.

ssh-keyscan aborts when it encounters glue without the proper
authoritative data. eg:

hostname.domain.com IN NS hostname.domain.com
hostname.domain.com IN A 1.2.3.4

Where hostname.domain.com is itself not running a namserver.
It is correct in not processing this entry, as the glue is
non-authoritative data, and cannot be confirmed by the nameserver ot
the child zone.
However, ssh-keyscan should just skip this entry, not abort.

I noticed this when writing ftp://ftp.xelerance.com/sshfp/ which is a
python script that can use ssh-keyscan (or known_hosts files) to
generate SSHFP records.




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
_______________________________________________
openssh-bugs mailing list
openssh-bugs@mindrot.org
http://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 1213] ssh-keyscan exits in mid-way [ In reply to ]
bugzilla-daemon
Jul 25, 2006, 9:18 PM
Post #2 of 2 (388 views)
Permalink
http://bugzilla.mindrot.org/show_bug.cgi?id=1213

Summary: ssh-keyscan exits in mid-way
Product: Portable OpenSSH
Version: 4.3p2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: Miscellaneous
AssignedTo: bitbucket@mindrot.org
ReportedBy: tryponraj@gmail.com


Hello All,

Im using OpenSSH 4.3p2 and tyring to scan a list of 40 machines in my
network with ssh-keyscan utility. I used the following command,

ssh-keyscan -t rsa -f hosts.txt

The man page says that this utility displays the host keys rrespective
of ssh or host is up/down and its working great. But in case if the
scan stops at 30th host due to some protocol problems, the utility
exits and don't display the host keys for remaining machines. I think
this is an expected behaviour, but it would be better to ignore that
host continue till the end or atleast this can be documented
specifically in the man page.

I digged up this problem further and find my results below.

ssh-keyscan ignores the hosts if they are not up or sshd is not running
when used with -f <file> option. But when it encounters any error while
retrieving the host key from the machine which is up and have sshd
running,it simply exits. This may happen due to transport layer
implementation in packet.c at packet_read_poll_seqnr() which results in
exiting.

My guess is that as packet.c is utilised by all OpenSSH utilities
including ssh-keyscan, we can't make ssh-keyscan to continue with
remaining hosts as specified in -f <files> in case of an error. But I
also vote for atleast documenting this one.

Detailed debug traces are given below:
--------------------------------------
# ssh-keyscan -vvv -t rsa host.server.com
debug2: fd 3 setting O_NONBLOCK
debug1: no match: mpSSH_0.1.0
# host.server.com SSH-2.0-mpSSH_0.1.0
debug1: Enabling compatibility mode for protocol 2.0
debug3: RNG is ready, skipping seeding
debug1: SSH2_MSG_KEXINIT sent
Received disconnect from 16.245.97.226: 11: SSH Disabled


# ssh -vvv host.server.com
OpenSSH_4.3p2-hpn, OpenSSL 0.9.7i 14 Oct 2005
HP-UX Secure Shell-A.04.30.005, HP-UX Secure Shell version
debug1: Reading configuration data /opt/ssh/etc/ssh_config
debug3: RNG is ready, skipping seeding
debug2: ssh_connect: needpriv 0
debug1: Connecting to host.server.com [16.245.97.226] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/3
debug1: identity file /.ssh/identity type 0
debug3: Not a RSA1 key file /.ssh/id_rsa.
debug2: key_type_from_name: unknown key type '-----BEGIN'
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
debug2: key_type_from_name: unknown key type '-----END'
debug3: key_read: missing keytype
debug1: identity file /.ssh/id_rsa type 1
debug3: Not a RSA1 key file /.ssh/id_dsa.
debug2: key_type_from_name: unknown key type '-----BEGIN'
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
debug2: key_type_from_name: unknown key type '-----END'
debug3: key_read: missing keytype
debug1: identity file /.ssh/id_dsa type 2
debug1: Remote protocol version 2.0, remote software version
mpSSH_0.1.0
debug1: no match: mpSSH_0.1.0
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.3p2-hpn
debug2: fd 4 setting O_NONBLOCK
debug3: RNG is ready, skipping seeding
debug1: SSH2_MSG_KEXINIT sent
Received disconnect from 16.245.97.226: 11: SSH Disabled




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
_______________________________________________
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

©2024 GT.net. A Gossamer Threads company.
5th Floor, 455 Granville St., Vancouver, BC V6C 1T1, Canada | Legal