Dotaz: Problém s ssh

[Vtipnéř]

Hezký den všem.

Nejdřív popíšu situaci. Momentálně jsem doma na home office. V kanceláři mi běží počítač s Arch Linuxem, na ten se nemůžu přihlásit přímo z domova, musím přes náš pracovní server s Ubuntu. Hlásím se tam zřídka (přes ssh pomocí klíče), jen když potřebuji pustit nějaké náročnější zpracování dat. Jiný typ připojení, např. rdesktop, nepoužívám. Domovský adresář z počítače v kanceláři mám připojený na serveru pomocí sshfs pro případ, kdybych potřeboval z kanceláře něco stáhnout nebo tam uložit.

A teď problém: Včera jsem zjistil, že přihlášení přes ssh přestalo fungovat, hlásí mi to

ssh_exchange_identification: read: Connection reset by peer

Stačil by patrně restart sshd, což nemůžu udělat na dálku, když se nemůžu přihlásit. Ale domovský adresář z kanceláře zůstal připojen na serveru. Takže můj dotaz zní: je možné nějak na dálku zprovoznit přihlášení přes ssh, například zásahem do lokální konfigurace v adresáři .ssh?

Předem díky za odpovědi.

Jirka

---

---

Odpovědi

[Вherzet]

Prihlas sa pri ssh s parametrom -v tam kde ti to blbne a citaj alebo hod sem text.

[Vtipnéř]

Díky, dole je výstup. Tipnul bych to na problém s klíčem, ale když jsem se zkusil přihlásit bez klíče (ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no), tak to dopadlo taky neuspěšně.

Jirka

OpenSSH_7.2p2 Ubuntu-4ubuntu2.8, OpenSSL 1.0.2g  1 Mar 2016
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to jirka [147.251.xxx.xxx] port 22.
debug1: Connection established.
debug1: identity file /home/employees/jirka/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /home/employees/jirka/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/employees/jirka/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/employees/jirka/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/employees/jirka/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/employees/jirka/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/employees/jirka/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/employees/jirka/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.8
ssh_exchange_identification: Connection closed by remote host

[X]

Dost mozna to ani prihlaseni heslem nepovoluje. Zadej cestu ke klici rucne:

ssh -vv -i /cesta/tvuj_klic server

[Vtipnéř]

Přihlášení heslem mám skoro určitě povoleno, na klíč jsem přešel poměrně nedávno. Ledaže by se něco samo změnilo po nějakém updatu.

Tip jsem zkusil, ve výpisu přibyly dva řádky s debug2 (kvůli orientaci uvádím i předchozí řádek):

debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: resolving "147.251.xxx.xxx" port 22
debug2: ssh_connect_direct: needpriv 0

Ještě napíšu sysmanovi, jestli neměnil něco v konfiguraci ssh.

Jirka

[X]

Ok pridej tam jeste jedno -v a posli to cele:

ssh -vvv -i tvuj_klic server

a pro jistotu se jeste koukni do /var/log/auth.log.

[Vtipnéř]

Posílám, ale nic nového tam není. Do toho souboru se nedostanu, na serveru nemám přístup a na mém počítači je mimo připojenou část.

Jirka

OpenSSH_7.2p2 Ubuntu-4ubuntu2.8, OpenSSL 1.0.2g  1 Mar 2016
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: resolving "jirka" port 22
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to jirka [147.251.xxx.xxx] port 22.
debug1: Connection established.
debug1: identity file .ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file .ssh/id_rsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.8
ssh_exchange_identification: read: Connection reset by peer

[X]

Protistrana to proste bezduvodne zarizne a nepokracuje ani v procesu autentizace. Muzes byt na nejakem blacklistu nebo tak neco.. Uz jsem se setkal se situaci, kdy se firewall snazi delat proxy. Ma to byt:

debug1: key_load_public: No such file or directory
debug1: identity file /xxx/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /xxx/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.2
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.7p1 Debian-5+deb8u4
debug1: match: OpenSSH_6.7p1 Debian-5+deb8u4 pat OpenSSH* compat 0x04000000
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to xxx.cz:56185 as 'xxx'
debug3: put_host_port: [xxx.cz]:56185
debug3: hostkeys_foreach: reading file "/root/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /xxx/.ssh/known_hosts:2
debug3: load_hostkeys: loaded 1 keys from [xxx.cz]:56185
...

[j]

Podle toho vypisu tam bud nemas klic, kterej se snazis pouzit, nebo doslo k nejaky aktualizaci a ty se snazis pouzit klic generovanej nepodporovanym/nepovolenym algoritmem.

Predpokladam, ze prihlasovani bez klice je zakazany.

At tak nebo tak bez toho aby ses k tomu prihlasil s tim nic neudelas. Takze si budes muse udelat vylet na misto, protoze opet predpokladam, ze neco jako drac/ilo/... to nema.

---

Dete s tim guuglem dopice!

[Vtipnéř]

Myslím si, že se to stalo po poslední aktualizaci, asi jsem něco zapomněl udělat, pravděpodobně restart sshd. V blízké době stejně budu muset zajít pro stravenky, tak to pořeším na místě.

Jirka

[Jendа]

Zkusil bych se tam přihlásit lokálním SSH klientem pro případ, že je problém na tom Ubuntu serveru. Udělej si tunel (ssh server -L 2222:desktop:22) a pak ssh -p 2222 localhost. (existuje parametr -J, kterým se tohle stane automaticky, ale pro debugování mi nepřijde vhodný, protože ve -vvv pak uvidíš obě spojení a nevyznáš se v tom)

Když se na ten SSH server telnetneš (telnet desktop 22), hodí to identifikační string?

To, že stávající spojení (sshfs) zůstalo viset, bohužel neznamená, že SSH server funguje. To stávající spojení běží v dětském procesu a když server havaruje/restartuje se, tak obvykle dál funguje. Ale napadlo mě, že by přes něj šlo spouštět příkazy a opravit to -- nejlepší by bylo, pokud máš zapisovací právo do něčeho, co se spouští (třeba z cronu). Jestli jde běžící sshfs ladit a otevřít si přímo shell nevím, ale teoreticky by mělo.

[Jendа]

ale teoreticky by mělo

A nebo ne, moje sshfs spustí ssh -s sftp, a z toho nevím jestli půjde vylézt.

[Vtipnéř]

To, že stávající spojení (sshfs) zůstalo viset, bohužel neznamená, že SSH server funguje. To stávající spojení běží v dětském procesu a když server havaruje/restartuje se, tak obvykle dál funguje.

Tohle mi připadá jako velmi pravděpodobné vysvětlení. Zkoušel jsem další návrhy uvedené i v ostatních příspěvcích, ale nic nezabralo. Takže někdy příští týden tam zajdu a provedu ruční zásah.

Možná přidám nějaký záložní způsob připojení. Zatím všem díky.

Jirka

[ZAH]

Napadají mne práva k ke složce (a souborům rekurzivním) /home/tvoje/.ssh/

použij chmod go-rwx /home/tvoje/.ssh/

[Peter Golis]

Tým ale sprístupní pre všetkých lokálnych užívateľov svoj osobný kľúč.

Ako phishing dobré.

Keby mal problém právami toho adresára, tak mu stačí aby bola vo vlastníctve jeho UID, GID a aby bola preňho čitateľná.

[ZAH]

Přečti si dobře příkaz. Soubor nesmí být přístupný pro nikoho kromě vlastníka. Příkaz odebírá práva. Nesmí být přístupný pro skupinu.

[Peter Golis]

Jaj, pardon. Tam je mínus, hanbím sa.

[Petr Fiedler]

Zpráva o výsledku: počítač byl v podstatě tuhý, nereagoval na klávesnici, na monitoru bylo nějaké hlášení (detaily už nevím). Takže jsem použil základní řešení - vypnout a zapnout.

Jirka