SSH rarigheid ?

[Verwijderd]

Hey,

Ik kan sinds een paar dagen niet meer naar buiten SSH'en vanaf mijn server. Waar ik ook heen probeer te SSH'en het resulteert allemaal in:

$ ssh some.host.tld
Permission denied, please try again.
Permission denied, please try again.
Permission denied (publickey,password,keyboard-interactive).
zsh: 12400 exit 255 ssh some.host.tld

Er word dus niet eens om een password gevraagd, maar toch krijg ik permission denied. De output van ssh -v -v -v is ook niet vreselijk verhelderend m.i.:

debug1: got SSH2_MSG_SERVICE_ACCEPT
debug1: authentications that can continue: publickey,password,keyboard-interactive
debug3: start over, passed a different list publickey,password,keyboard-interactive
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: next auth method to try is publickey
debug1: try privkey: /home/ssmeenk/.ssh/identity
debug3: no such identity: /home/ssmeenk/.ssh/identity
debug1: try privkey: /home/ssmeenk/.ssh/id_rsa
debug3: no such identity: /home/ssmeenk/.ssh/id_rsa
debug1: try privkey: /home/ssmeenk/.ssh/id_dsa
debug3: no such identity: /home/ssmeenk/.ssh/id_dsa
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 auth method to try is 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 auth method to try is password
debug3: packet_send2: adding 64 (len 52 padlen 12 extra_pad 64)
debug2: we sent a password packet, wait for reply
debug1: authentications that can continue: publickey,password,keyboard-interactive
Permission denied, please try again.
debug3: packet_send2: adding 64 (len 52 padlen 12 extra_pad 64)
debug2: we sent a password packet, wait for reply
debug1: authentications that can continue: publickey,password,keyboard-interactive
Permission denied, please try again.
debug3: packet_send2: adding 64 (len 52 padlen 12 extra_pad 64)
debug2: we sent a password packet, wait for reply
debug1: authentications that can continue: publickey,password,keyboard-interactive
debug2: we did not send a packet, disable method
debug1: no more auth methods to try
Permission denied (publickey,password,keyboard-interactive).

Wat me opvalt is dat ie wel /zegt/ een password packet te hebben verstuurd, maar ik heb er nooit een ingetikt. Mijn ~/.ssh/ bevat alleen een known_hosts file, geen andere config files. /etc/ssh/ssh_config bevat ook geen active statements, m.a.w. alles staat uitgecomment.

Heeft iemand enig idee wat dit kan zijn?

$ ssh -V
OpenSSH_3.5p1 Debian 1:3.5p1-2, SSH protocols 1.5/2.0, OpenSSL 0x0090607f

Ik weet 't iig niet meer.

[Verwijderd]

Zijn alle bestanden in ~/.ssh/ wel leesbaar en schrijfbaar voor jou, zowel op deze machine als op de machine die je met ssh probeert te bereiken?

[Verwijderd]

yep.

De computer waar ik heen SSH logt in /var/log/auth.log:

Dec 18 15:35:42 host sshd[11426]: Failed password for ssmeenk from 195.64.xx.xxx port 1105 ssh2

u tell me!

[ Voor 96% gewijzigd door Verwijderd op 18-12-2002 15:36 ]

[Arioch]

heb je 'chkrootkit' al eens laten draaien?

[active2]

onzin

[ Voor 99% gewijzigd door active2 op 18-12-2002 16:51 ]

[Verwijderd]

Het is echt *ZO* raar dat zelfs wanneer ik compleet SSH van m'n systeem verwijder, INCLUSIEF /etc/ssh, ~/.ssh/ alles wat er maar mee te maken heeft, WEGHAAL, 't daarna opnieuw installeer, en nog es probeer: Host key verification failed.

Now breaks my wooden shoe..

[XTerm]

En dit is zo naar eender welke host je probeert the SSH'en ?

[active2]

Verwijderd schreef op 18 december 2002 @ 16:56:
Het is echt *ZO* raar dat zelfs wanneer ik compleet SSH van m'n systeem verwijder, INCLUSIEF /etc/ssh, ~/.ssh/ alles wat er maar mee te maken heeft, WEGHAAL, 't daarna opnieuw installeer, en nog es probeer: Host key verification failed.

Now breaks my wooden shoe..

Probeer eens met ssh nieuwe keys aan te maken

[Verwijderd]

't zou evt veroorzaakt kunnen worden doordat op de remote "PasswordAuthentication no" in de sshd_config staat. Dit is mij iig een keer overkomen. Op de remotes werd je alleen maar toegelaten als je pubkey in de authorized_keys stond, en dat je dus ook alleen maar via pub/privkey auth binnen kon komen.
Toen je sshd opnieuw installde, heb je toen ook de deb files opnieuw geleeched (soms, heel soms heb ik het gevoel dat dat wat scheelt...)
Dit, of een proxy tussen jouw en de remote die packets mangled / dropped. (kun je op de remote inloggen (via telnet, vnc, xdmcp, whatever) om zo tcpdump te draaien? (of de admin van remote vragen te helpen natuurlijk))

edit:
tekst verduidelijkt

[ Voor 76% gewijzigd door Verwijderd op 18-12-2002 17:14 ]

[Verwijderd]

Volgens mij heeft het naar buiten ssh'en niet te maken met de instellingen van mijn sshd, right?

Anyways, het is nog gekker. Mijn user (ssmeenk) krijgt die vreemde problemen met ssh, en een test user (sm-test) kan gewoon ssh'en, alles werkt als een charm.

WaddeFUK is er aan de hand.

.zshrc van mijn shell even weggemoved en opnieuw ingelogd, resultaat blijft hetzelfde, ik kan niet ssh'en, sm-test wel.

[ Voor 20% gewijzigd door Verwijderd op 18-12-2002 17:37 . Reden: ligt dus niet aan shell ]

[Verwijderd]

met de sshd_config bedoelde ik die van de remote ssh server, dus niet die van jouw eigen systeem. Je hebt echter zelf het probleem al flink weten te reduceren. Paar vraagjes:

- die sm-test user, heeft die een andere shell?
- als jij een andere shell gebruikt, werkt het dan ook?
- als je (nadat je een backup gemaakt hebt) al je ~/.[a-z]* files weggooit, heb je dan nog hetzelfde probleem?

edit:
<ot>fsck, m'n usericon ziet er eigk niet uit, vanavond maar ff rechtzetten </ot>

[ Voor 13% gewijzigd door Verwijderd op 18-12-2002 17:45 ]

[Verwijderd]

sm-test user heeft ook zsh als shell, maar geen .zshrc, maar zoals ik net postte helpt 't dus niet als ik mijn eigen .zshrc wegmove

het maakt niet uit of ik zsh of bash gebruik, beide shells geven hetzelfde foute resultaat.

net even alle .-files uit m'n homedir weggemoved, to no avail.
*ECHT* ik heb nog nooit zoiets sufs meegemaakt.

[Verwijderd]

active2 schreef op 18 December 2002 @ 17:10:
[...]

Probeer eens met ssh nieuwe keys aan te maken

Dat gebeurt vanzelf als je SSH opnieuw installeert. iig wel met de debian packages, en zeker nadat ik 101% sure was dat er geen restje van SSH meer op mijn systeem stond nadat ik SSH had verwijderd.

HELP!

[Newjersey]

Welke kernel gebruik je?

als je 2.2.* gebruikt met een nieuwe ssh moet je dit in je sshd.conf zetten

code:

Compression no

[Verwijderd]

Ik gebruik een al wat oudere kernel: 2.4.17. Maar het heeft gewerkt, en sinds ongeveer begin deze week heb ik deze rare problem. Het werkt dus ook perfect als een andere user dan 'ssmeenk' (ikke). Alleen ben ik er nog niet achter waarom. Het ligt niet aan de shell, niet aan environment variables, niet aan zogenaamde 'dot-files' en 'dot-directories', geen idee waar het aan ligt.

[Verwijderd]

ok, mischien dat een strace meer info geeft. Doe anders eens voor beide users de .zshrc wegmoven, en dan strace ssh user@host. De outputfiles kun je evt diff-en. Als ik straks thuis ben heb ik wat hosts tot me beschikking om ook wat tests te gaan doen...

Enne Newjersey, je moet "Compression no" doen als je priviledge separation gebruikt. Niet waneer je oude kernels gebruikt (ik moet het ook uitzetten met 2.4 kernels en anders zet ssh compression uit als je beide gebruikt)

[Verwijderd]

Mja, strace had ik nog niet geprobeert. En zo blijkt maar weer dat je dat toch moet doen, want wat bleek daaruit:

15864 open("/dev/tty", O_RDWR|O_LARGEFILE) = -1 EACCES (Permission Denied)

en

[18:22] [ssmeenk@sorrow:~] % ls -lad /dev/tty
crw-r--rw- 1 root tty 5, 0 Dec 18 18:18 /dev/tty

Na dat weer op crw-rw-rw- gezet te hebben, wis en waarachtig, weer een password prompt voor mijn neus.

Geen *FLAUW* idee hoe /dev/tty ineens zo'n vreemde set rechten kan hebben gekregen.

[Verwijderd]

ssmeenk zit in groep tty, /dev/tty was niet group writable.
sm-test zit niet in groep tty, /dev/tty is wel world writable.

Beats me waarom een file die wel world writable is, maar voor een groep niet, niet geschreven kan worden door die groep. Beetje vreemde logica.