[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: i cannot understand sshd behavior
Andreas Haupt wrote:
> sorry for the delay.
> On Tue, 13 Mar 2007, Douglas E. Engert wrote:
>>> Does the reverse lookup (mapping ip to fqdn) work? Depending on
>>> /etc/nsswitch.conf something like this should give you a fqdn of the
>>> desired host name:
>> Why do you thing there is a name mapping going on? You gave
>> it an explicit IP ti try.
> because the ssh client simply does a name lookup if you specify an ip
> address. Otherwise this wouldn't work, would it?
ssh does not need the name mapping, it can use the IP number.
Note the line: "Connecting to 188.8.131.52 [184.108.40.206] port 22".
Normally it would say "Connecting to fama.ifh.de [220.127.116.11] port 22"
But the GSSAPI should need to map the ip to the name to get a principal
name of the host to get a service ticket. (Can the heimdal GSS do this?)
What does the klist show on the machine where the ssh was run?
Does it have a service ticket for host/fama.ifh.de@IFH.DE
Or did you create a host principal with the ip number,
Note the security risk here of using the ip number. You are now
trusting the DNS server to return the correct mapping. If the IP
is registered to some other site, it will be the other site's DNS
> [fuchur] ~ % ssh -v 18.104.22.168 klist
> OpenSSH_3.9p1, OpenSSL 0.9.7a Feb 19 2003
> debug1: Reading configuration data /afs/ifh.de/user/a/ahaupt/.ssh/config
> debug1: Reading configuration data /etc/ssh/ssh_config
> debug1: Connecting to 22.214.171.124 [126.96.36.199] port 22.
> debug1: Connection established.
> debug1: identity file /afs/ifh.de/user/a/ahaupt/.ssh/identity type 0
> debug1: identity file /afs/ifh.de/user/a/ahaupt/.ssh/id_rsa type -1
> debug1: identity file /afs/ifh.de/user/a/ahaupt/.ssh/id_dsa type 2
> debug1: Remote protocol version 2.0, remote software version OpenSSH_4.5
> debug1: match: OpenSSH_4.5 pat OpenSSH*
> debug1: Enabling compatibility mode for protocol 2.0
> debug1: Local version string SSH-2.0-OpenSSH_3.9p1
> debug1: SSH2_MSG_KEXINIT sent
> debug1: SSH2_MSG_KEXINIT received
> debug1: kex: server->client aes128-cbc hmac-md5 none
> debug1: kex: client->server aes128-cbc hmac-md5 none
> debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
> debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
> debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
> debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
> debug1: Host '188.8.131.52' is known and matches the RSA host key.
> debug1: Found key in /etc/ssh/ssh_known_hosts2:322
> debug1: ssh_rsa_verify: signature correct
> debug1: SSH2_MSG_NEWKEYS sent
> debug1: expecting SSH2_MSG_NEWKEYS
> debug1: SSH2_MSG_NEWKEYS received
> debug1: SSH2_MSG_SERVICE_REQUEST sent
> debug1: SSH2_MSG_SERVICE_ACCEPT received
> debug1: Authentications that can continue:
> debug1: Next authentication method: gssapi-with-mic
> debug1: Delegating credentials
> debug1: Delegating credentials
> debug1: Authentication succeeded (gssapi-with-mic).
> debug1: channel 0: new [client-session]
> debug1: Entering interactive session.
> debug1: Requesting X11 forwarding with authentication spoofing.
> debug1: Requesting authentication agent forwarding.
> debug1: Sending command: klist
> Credentials cache: FILE:/tmp/krb5cc_E11054
> Principal: ahaupt@IFH.DE
> Issued Expires Principal
> Apr 3 15:06:06 Apr 4 15:26:58 krbtgt/IFH.DE@IFH.DE
> Apr 3 15:06:06 Apr 4 15:26:58 afs@IFH.DE
> debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
> debug1: channel 0: free: client-session, nchannels 1
> debug1: Transferred: stdin 0, stdout 0, stderr 0 bytes in 0.3 seconds
> debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.0
> debug1: Exit status 0
> [fuchur] ~ %
Douglas E. Engert <DEEngert@anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439