hp ProCurve und ssh public key

Marc Haber

unread,

Jul 22, 2008, 12:04:59 PM7/22/08

to

Hallo,

ich möchte gerne einen hp ProCurve Switch per ssh ansprechen:

# show ip ssh

SSH Enabled : Yes
SSH Version : 2
TCP Port Number : 22
Timeout (sec) : 120
Server Key Size (bits) : 1024
Secure Copy Enabled : No

# show authentication

Status and Counters - Authentication Information

Login Attempts : 3
Respect Privilege : Disabled

# show crypto client-public-key

Operator keys:

0,mh@my-notebook 2005-01-09 ssh-rsa AAAA<snip>bqDQ==

$ ssh -v operator@<switch>
OpenSSH_4.7p1 Debian-12, OpenSSL 0.9.8g 19 Oct 2007
debug1: Reading configuration data /home/mh/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to <switch> [10.2.100.77] port 22.
debug1: Connection established.
debug1: identity file /home/mh/.ssh/mh-priv-my-notebook type 1
debug1: identity file /home/mh/.ssh/mh-dsa-my-notebook type 2
debug1: identity file /home/mh/.ssh/mh-my-notebook type 1
debug1: Remote protocol version 2.0, remote software version
OpenSSH_3.7.1p2
debug1: match: OpenSSH_3.7.1p2 pat OpenSSH_3.*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.7p1 Debian-12
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client 3des-cbc hmac-md5 none
debug1: kex: client->server 3des-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<2048<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 '<switch>' is known and matches the RSA host key.
debug1: Found key in /home/mh/.ssh/known_hosts:324
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
We'd like to keep you up to date about:
* Software feature updates
* New product announcements
* Special events

Please register your products now at: www.ProCurve.com

debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering public key: /home/mh/.ssh/mh-my-notebook
debug1: Authentications that can continue: publickey
debug1: Offering public key: /home/mh/.ssh/mh-priv-my-notebook
debug1: Authentications that can continue: publickey
debug1: Offering public key: /home/mh/.ssh/mh-dsa-my-noteb ook
Received disconnect from 10.2.100.77: 2: Too many authentication
failures for operator
$

show logging zeigt nix, was auf den Loginversuch schiließen liesse.
Was kann ich da noch falsch gemacht haben?

Grüße
Marc

Marc Haber

unread,

Jul 27, 2008, 4:05:18 PM7/27/08

to

Marc Haber <mh+usene...@zugschl.us> wrote:
>Operator keys:
>
>0,mh@my-notebook 2005-01-09 ssh-rsa AAAA<snip>bqDQ==

Das Problem war das Leerzeichen im Kommentar für den Public-Key. Ich
weiß zwar nicht, wie hp das OpenSSH, das sie auf den Switches
einsetzen, _so_ kaputt machen konnte, dass es dann so subtil versagt,
aber ein Entfernen des Zeichens aus dem public key hat das Problem
gelöst.

Leider muss ich mir trotzdem was mit expect abbrechen, denn der Switch
führt das Kommando, das ich ihm auf der Kommandozeile mitgebe ("ssh
manager@switch show running") nicht aus.

Jens Link

unread,

Jul 28, 2008, 1:21:07 PM7/28/08

to

Marc Haber <mh+usene...@zugschl.us> writes:

> Leider muss ich mir trotzdem was mit expect abbrechen, denn der Switch
> führt das Kommando, das ich ihm auf der Kommandozeile mitgebe ("ssh
> manager@switch show running") nicht aus.

clogin aus dem RANCID-Paket sollte da helfen. Ueberhaupt ist der Einsatz
von RANCID sinnvoll wenn man mehr als ein oder zwei Netzwerkkomponenten
hat.

http://www.shrubbery.net/rancid/

Jens
--
sage@guug Berlin: http://www.guug.de/lokal/berlin/index.html

Christian Dürrhauer

unread,

Aug 1, 2008, 10:42:34 AM8/1/08

to

Marc Haber wrote:
> Marc Haber <mh+usene...@zugschl.us> wrote:
>> Operator keys:
>>
>> 0,mh@my-notebook 2005-01-09 ssh-rsa AAAA<snip>bqDQ==
>
> Das Problem war das Leerzeichen im Kommentar für den Public-Key. Ich
> weiß zwar nicht, wie hp das OpenSSH, das sie auf den Switches
> einsetzen, _so_ kaputt machen konnte, dass es dann so subtil versagt,
> aber ein Entfernen des Zeichens aus dem public key hat das Problem
> gelöst.
>
> Leider muss ich mir trotzdem was mit expect abbrechen, denn der Switch
> führt das Kommando, das ich ihm auf der Kommandozeile mitgebe ("ssh
> manager@switch show running") nicht aus.

Du hast auch immer brav "write mem" ausgeführt? Tut man das nicht,
verwirft das Gerät glatt die letzten Config-Aufrufe. Insgesamt haben die
HP-Geräte zwar ein gutes Preis-/Leistungsverhältnis, insgesamt aber auch
für mich Kanten, weshalb ich sie durchweg schlechter als vergleichbare
Cisco finde.

Christian

Message has been deleted

Sven Hartge

unread,

Aug 2, 2008, 1:56:50 PM8/2/08

to

Daniel Krebs <spam.a...@t-online.de> wrote:
> Christian Dürrhauer <cdu...@duerrhauer.de> wrote:

>> Insgesamt haben die HP-Geräte zwar ein gutes
>> Preis-/Leistungsverhältnis, insgesamt aber auch für mich Kanten,
>> weshalb ich sie durchweg schlechter als vergleichbare Cisco finde.

> Hängt davon ab, was man damit machen will. Das CLI von HP fand ich
> sehr abschreckend.

> Für Grundeinstellungen reicht aber die Web- Oberfläche. Was ich da
> früher bei 3Com erleiden musste, war grauenhaft. Die von Cisco habe
> ich jedoch noch nie gesehen.

Das CLI der aktuellen 42xx und 45xx von 3Com ist sehr Cisco-ähnlich und
ein Meilenstein gegenüber der alten CLI. Man sagt ja, das 3Com/Huawei
hier den Code von Cisco reverse engineered haben sollen.

Auch das Webinterface ist halbwegs brauchbar, im Gegensatz zur früheren
Variante.

Leider ist das Backup der Config-Dateien immer noch sehr frickelig
(expect anyone?), bei Cisco kann ich dies ja via SNMP anstoßen.

S°

--
Sven Hartge -- professioneller Unix-Geek
Meine Gedanken im Netz: http://www.svenhartge.de/