PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : authorized keys, Permission denied



littleangel
14.12.09, 13:54
ich bin gerade am verzweifeln ... folgendes problem: (mein erster tag auf Aix, ansich linux admin)

AIX Server 5.3 (ich hoffe ihr könnt mir trotzdem helfen)
ich möchte unter anderem via ssh über authorized keys verbinden.
zusätzlich zu norm. user + pw login.

config anpassungen:

variante 1:

sshd_config:
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
PasswordAuthentication no

Fehler:
ssh -i .ssh/keyfile serverip
Permission denied (publickey,keyboard-interactive).


variante 2:

sshd_config:
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
#PasswordAuthentication no

Fehler:
ssh -i .ssh/keyfile serverip
user@serverip's password:
(die passwortabfrage kommt dennoch)


Zusatzinfo:
die key files sind jedoch ursprünglich auf einem linux system generiert worden, funktioniert auch so. habe den server key den ich immer auf den server kopiere und das funktioniert bisher bei allen linux systemen.
dies ist mein erstes AIX system und ich weiß nicht ob das mit ein problem ist.

Logfiles:
ich finde keine am aix. ... kein messages, syslog, security log oder sonst irgendwelche logs.

pls help. ohne logs bin ich echt hilflos ...

link zu den anderen foren mit dem selben beiträgen:
http://www.rootforum.org/forum/viewtopic.php?f=75&t=50956
http://www.administrator.de/index.php?content=131633

oziris
14.12.09, 23:17
Auf die .ssh/authorized_keys müssen ganz bestimmte Rechte gesetzt sein. (Siehe "man sshd" Abschnitt FILES Absatz "~/.ssh/authorized_keys" oder "man ssh-copy-id")

littleangel
15.12.09, 08:03
hi,
danke für die antwort.
leider hab ich das auch :(

.ssh/ -> 700
keyfile -> 600

ich hab das gefühl es muss an der config liegen. jedoch ist diese ident mit den andern config files. lediglich das betriebsystem ist ein anderes.
und wie gesagt ich finde keine logfiles. vielleicht kann mir jemand sagen wo ich die unter aix finden kann. ein find bringt garnix leider.

marce
15.12.09, 08:06
ich fürchte, ohne Logeinträge des Servers wird's schwer - versuch doch erst mal herauszufinden, wo die denn sein könnten...

Evtl. - wenn Du den Client auf "gib mir jeden Sch* aus"-Debug-Modus stellst - kommt da auch was zurück...

kreol
15.12.09, 09:51
Hier mal ein Auszug aus meiner sshd_config (Debian):
...
# Logging
SyslogFacility AUTH
LogLevel INFO

# Authentication:
LoginGraceTime 120
PermitRootLogin no
StrictModes yes

RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile %h/.ssh/authorized_keys

# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
#IgnoreUserKnownHosts yes

# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no

# Change to no to disable tunnelled clear text passwords
PasswordAuthentication no
...Ob aix da etwas anders handhabt kann ich nicht sagen, das ist aber eher unwahrscheinlich. Welche ssh-Version ist denn am Start?

Den logging-Teil habe wg. des Beitrags von marce mal mitkopiert, da kannst Du das Loglevel am Server hochdrehen.

Und logischerweise musst Du den sshd nach einer Änderung neu starten.


Kreol

littleangel
15.12.09, 10:23
thx.
ja login hab ich aufgedreht.
auch neu gestartet hab ichs (kann kein restart oder reload, explizites stop/starten ...)

aber nirgenst ist ein file aufgetaucht trotz login meinerseits wo er was protokollieren müßte. ....

am liebsten würde ich ja ssh deinstalliern und neu installieren. hab irgendwo nen beitrag gefunden wo das half.
leider fehlen 1. meine kenntnisse wie das geht. 2. ist das ein kundensystem welches in betrieb ist .... da geht das leider nicht so einfach :(

config ist identisch wie im linux.
nur reagiert sie anders?!? scheinbar.


hab ich irgendwas vergessen.
welche einstellungen muss ich machen wenn ich user auth + key auth haben will? vielelicht hab ich was übersehen?!

Roger Wilco
15.12.09, 11:23
Multiposting - Was ist das und warum mag die keiner? (http://www.linux-club.de/viewtopic.php?f=38&t=76935)

http://www.rootforum.org/forum/viewtopic.php?f=75&t=50956
http://www.administrator.de/AIX,_authorized_keys,_Permission_denied.html

kreol
15.12.09, 11:51
Multiposting - Was ist das und warum mag die keiner? (http://www.linux-club.de/viewtopic.php?f=38&t=76935)Es dürfte sich gemäss dem von Dir selbst geposteten Link eher um crossposting als um multiposting handeln... :rolleyes:


Kreol

Roger Wilco
15.12.09, 11:54
Beim Multiposting posted man einfach in mehreren Foren dieselbe Frage. Der Grund kann vielfältig sein. Dann fängt in jedem Forum eine Diskussion an - und kein Forumsposter weiß von den anderen Foren wo ebenso andere Forenbesucher versuchen zu helfen. Würden die voneinander wissen und die Postings in den jeweils anderen Foren kennen wird Doppelarbeit vermieden.
Das ist hier der Fall. Oder meintest du etwas anderes?

Ich finde es nicht schlimm, dass in verschiedenen Foren gleichzeitig gefragt wird, allerdings erwarte ich dann einen Link auf die parallel laufenden Diskussionen.

littleangel
15.12.09, 11:56
jop lt. link bin ich ein crossposter :)

marce
15.12.09, 11:58
Im Gegensatz dazu übernimmt der Poster bei einem Crossposting bewußt die Aufgabe in den jeweiligen Postings mit Links auf die anderen Postings zu verweisen und außerdem bei erfolgreicher Beendigung der Diskussion in einem Forum das Kopieren der Antwort/Lösung in die anderen Foren zwecks Referenz für diejenigen,
den Beweis dafür bist Du uns aber noch schuldig.

littleangel
15.12.09, 12:10
links sind nun in allen 3 ursprungsposts enthalten so das man sie schnell findet.
auch werde ich in allen 3en vermerken wie es funktioniert hat sollte ich es je zum laufen bekommen .....

syslog.conf is leer ... logfiles gibts überhaupt keine auf der maschine. und die verbindung dorthin ist leider so langsam das das arbeiten enorm schwer ist.

key habe ich generiert auf der aix maschine damit kein versionsproblem besteht.
das in der config was falsch ist glaub ich schon nicht mehr.

irgendwo fand ich einen beitrag wo einer schrieb bei der neuinstallation gings dann ... das kann ich leider nicht testen :(

ich lies mal weiter was logfiles betrifft ...

MiGo
15.12.09, 15:43
Du kannst auch mal versuchen dich mit "ssh -vvv user@host" zu verbinden, dann wird schon der Client deutlich gesprächiger, was er exakt versucht zu tun.

littleangel
16.12.09, 08:55
@migo. danke das hat echt viel geholfen.
aber problem is leider noch nicht gelöst.

ich habe nun einen neuen key generiert am aix server direkt. mit rsa1 weil bei dem output zuerst stand kein rsa1 key.

auch bekam ich dazwischen den fehler:
Authentication refused: bad ownership or modes for directory /home/nagios
habe die rechte des ordners auf 701, .ssh auf 700 und das key file auf 600 nochmals angepaßt (bis auf das home dir waren schon alle so)

am server liegt im ordner /home/nagios/.ssh/ 2x das selbe file mit unterschiedlichem namen.
einmal identity.pub und einmal authorized_keys ... weil ich gelsen hab manche systeme wollen ein identity.pub file. was aber absolut schwachsinn is wiel in meiner ssh config steht drin:


RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys

jetzt bekomme ich keinen fehler mehr ... nur ->


debug1: Next authentication method: publickey
debug2: we did not send a packet, disable method
debug3: authmethod_lookup keyboard-interactive
debug3: remaining preferred: password

gesammt sieht das so aus:


[nagios@nagios .ssh]$ ssh -vvv -i identity serverip
OpenSSH_4.3p2, OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to serverip [serverip] port 22.
debug1: Connection established.
debug1: identity file identity type 0
debug1: loaded 1 keys
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_4.3
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_init: found hmac-md5
debug1: kex: server->client aes128-cbc hmac-md5 none
debug2: mac_init: found hmac-md5
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
debug2: dh_gen_key: priv key bits set: 126/256
debug2: bits set: 501/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug3: check_host_in_hostfile: filename /home/nagios/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 5
debug1: Host '172.26.34.120' is known and matches the RSA host key.
debug1: Found key in /home/nagios/.ssh/known_hosts:5
debug2: bits set: 541/1024
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug3: start over, passed a different list publickey,password,keyboard-interactive
debug3: preferred gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug2: we did not send a packet, disable method
debug3: authmethod_lookup keyboard-interactive
debug3: remaining preferred: password
debug3: authmethod_is_enabled keyboard-interactive
debug1: Next authentication method: keyboard-interactive
debug2: userauth_kbdint
debug2: we sent a keyboard-interactive packet, wait for reply
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug3: userauth_kbdint: disable: no info_req_seen
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred:
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
nagios@serverip's password:


am server selbst, der auf debug lauft, steht nun nichts mehr im logfile.
außer Failed password for nagios was klar is.

bin zwar schon fleissig am suchen, aber bislang noch nicht fündig geworden wie ich das beheben kann das er doch ein packet sendet ....

danke für die hilfe. ich denk wir habens bald, hoff ich.

littleangel
17.12.09, 09:57
habe grad die anforderung gestellt das der ssh server neu installiert wird. ich hoffe das geschiet noch diese woche.
danke euch für die hilfe, damit "schließe" ich vorerst den beitrag weil ich hoffe das es damit behoben ist. fals nicht melde ich mich im jänner wieder. ;)

pibi
17.12.09, 14:31
habe grad die anforderung gestellt das der ssh server neu installiert wird.Nanana, wir sind doch hier nicht bei Windows :-)

Nur ein Schuss ins Blaue: Du weisst, wie genau die Authentification mittels keys funktioniert und welcher Key wo generiert und abgelegt werden muss? Du weisst, dass ein Key erst auf der Maschine, die sich verbinden will, "geladen" werden muss (zB. mit KeyChain in Linux oder pageant in Windows)? Was passiert, wenn Du Deinen public key auf eine Linux-Maschine kopierst? Klappt dann ein Connect via Key?

Ansonsten kann ich dir versichern, dass das Format der Keys etc. zwischen Linux und AIX absolut identisch ist. Ich connecte hier @WORK absolut problemlos zu einer AIX, sowohl von Windows als auch von Linux aus.

Gruss Pit.

littleangel
17.12.09, 14:57
hi,
danke für die antwort.
also wie gesagt unter linux hab ichs hinbekommen.
config is identisch von sshd.

(bez. neu installieren. ich hab einen älteren beitrag gefunden irgendwo wo stand neu installation half. vielleicht wegen ner neuen version. auch sagten die kollegen das dort garkein ssh drauf sein sollte standartmäßig auf der maschine und trotzdem drauf is ... viellicht das was vergessen wurde an notwendigen packeten?! ... deswegen möcht ich das die das nochmal kontrollieren bzw. neu installieren und am besten glei configurieren :D - und mit windows hab i net viel am hut. aber mit aix leider auch no nix. - das system hatte anfangs nicht mal logfiles, also irgendwie total komische installation was die da betrieben haben ... also wer weiß.)

ich habs probiert mit den keys die unter linux - linux funktionieren. mit denen gings auch net. weil so hab ich nur ein key file das ich nutzen muss was für die scripte natürlich gut ist wenns immer das selbe ist.

das mit dem "geladen" verstehe ich allerdings nicht.
ich verbinde mich mich ssh -i .ssh/keyfile serverip das klappt unter linux super.

ich habe nur 1 maschine die sich auf alle anderen verbindet. also nur einseitige key authentifzierung sozusagen, retour brauch ich nicht.

deswegen auch meine ursprungsfrage, was genau muss ich in da sshd_config aktivieren das geht. .. diese ist aber auf aix (bis auf das logfile einträge dings) gleich wie auf linux wo es geht.

danke dir.

lg