Keskustelu: Yleinen keskustelu: SCP ja SSH ongelma

Viime viikkoina minun on ollut vähän pakko opetella käyttämään VPS:ää ja komentorivia. Tähän asti olen koettanut välttää komentoriviä kuin ruttoa ja nyt se kostautuu. En ole ihan varma, että osaan kunnolla selittää ongelmaani saati käyttää oikeaa terminologiaa, mutta koetetaan.

Minulla on kaksi VPS serveriä ja lopullinen tavoitteeni olisi siirtää iso läjä dataa yhdeltä serveriltä toiselle käyttäen SCP:tä. Kun asensin Linuxit (16.04) noille servereille niin tein molemmille toisen käyttäjän root käyttäjän rinnalle. Sitten koetin lisätä kaikille neljälle käyttäjälle SSH salauksen ja poistaa salasanan kysymisen käytöstä. Tämä onnistui yhdelle ongelmitta, mutta kun piti saada SSH toimimaan kahdelle käyttäjälle, niin kone ei osannut arvata kumpaa avainta tulisi käyttää. En voinut tallentaa kaikkia avaimia samaan id_rsa tiedostoon, joten tallensin ne kaikki omiin tiedostoihinsa (id_rsa_root1, id_rsa_user1, id_rsa_root2, id_rsa_user2). Kun sitten koetin mennä sisään mille tahansa käyttäjälle, niin eihän se mennyt sisään. Pääsin sisään ainoastaan käyttäjälle, jonka avaimen tiedostonimi oli id_rsa. Google löysi minulle avun, kun loin config nimisen tiedoston, jonne laitoin seuraavan tekstin

Host login_root1
    HostName [IP1]
    IdentityFile ~/.ssh/id_rsa_root1
    User root1

Host login_user1
    HostName [IP1]
    IdentityFile ~/.ssh/id_rsa_user1
    User user1

Host login_root2
    HostName [IP2]
    IdentityFile ~/.ssh/id_rsa_root2
    User root2

Host login_user2
    HostName [IP2]
    IdentityFile ~/.ssh/id_rsa_user2
    User user2

Tällä pääsin kirjautumaan ongelmitta kaikilla neljällä tunnuksella ja opettelemaan ja tekemään kaikenlaista kivaa servereillä. Sitten yritin poistaa tästä config tiedostosta kokonaan "Host" rivit, jottei minun tarvitsisi käyttää sisäänkirjautumiseen näitä login_root1, login_root2 tekstejä, vaan voisin kirjautua root1@[IP1] ja root2@[IP2]. Noh, kävi niin, että komentorivi kirjautui aina sisään root1 ja user1 käyttäjillä vaikka olisin yrittänyt ssh root2@[IP2] ja ssh user2@[IP2]. Eli minun piti laittaa nuo "Host"it takaisin. Kirjaudun siis koko ajan sisään komennoilla ssh login_user2, ssh login_root1 ...

Nyt eteen tuli tilanne, että minun pitäisi siirtää dataa ensimmäiseltä serveriltä toiselle, mutta vaikka olen kuinka kysynyt apua googlelta ja koettanut kaikkia kikkoja, niin en silti tunnu onnistuvan. Onnistun kyllä datan siirtämisessä tietokoneeltani serverille ja serveriltä tietokoneelle, mutta SSH antaa jotain ongelmia niin ettei datan siirto serveriltä toiselle onnistu. Tajusinkin juuri tätä kirjoittaessa, että datan siirto onnistui koneelta serverille ja serveriltä koneelle silloin kun olin poistanut nuo "Host"it config tiedostosta. Siirto onnistui siis ensimmäisen serverin välillä, mutta veikkaan, että olisi epäonnistunut toisen serverin välillä. Ja nyt kun on "Host"it takaisin, niin siirto ei onnistu edes koneelta serverille ja takaisin.

Seuraavassa kaksi ensimmäistä koodia toimivat (silloin kun Host rivit oli pois config tiedostosta)

scp -v root1@[IP1]:/[OSOITE]/[SERVERILLÄ] /[OSOITE]/[KONEELLANI]

scp -v /[OSOITE]/[KONEELLANI] root1@[IP1]:/[OSOITE]/[SERVERILLÄ]

scp -v root1@[IP1]:/[OSOITE]/[SERVERILLÄ] root2@[IP2]:/[TOINEN]/[OSOITE]/[SERVERILLÄ]

Mutta kolmas koodi antaa seuraavan virhe-ilmoituksen

.
.
.
debug1: Host [IP1] is known and matches the ECDSA host key.
debug1: Found key in /Users/[KAYTTAJA]/.ssh/known_hosts:1
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 134217728 blocks
debug1: Will attempt key: /Users/[KAYTTAJA]/.ssh/id_rsa
debug1: Will attempt key: /Users/[KAYTTAJA]/.ssh/id_dsa
debug1: Will attempt key: /Users/[KAYTTAJA]/.ssh/id_ecdsa
debug1: Will attempt key: /Users/[KAYTTAJA]/.ssh/id_ed25519
debug1: Will attempt key: /Users/[KAYTTAJA]/.ssh/id_xmss
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<rsa-sha2-256,rsa-sha2-512>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /Users/[KAYTTAJA]/.ssh/id_rsa
debug1: Trying private key: /Users/[KAYTTAJA]/.ssh/id_dsa
debug1: Trying private key: /Users/[KAYTTAJA]/.ssh/id_ecdsa
debug1: Trying private key: /Users/[KAYTTAJA]/.ssh/id_ed25519
debug1: Trying private key: /Users/[KAYTTAJA]/.ssh/id_xmss
debug1: No more authentication methods to try.
root1@[IP1]: Permission denied (publickey).

Minulta alkaa olla nyt keinot lopussa. Huomaan, että selvästikään tämä ei löydä oikeita public key:tä, mutta en yhtään tiedä miten voisin korjata tämän.

Yleensä ei ole mitään syytä tehdä joka palvelimelle omaa avainta, vaan avain on käyttäjäkohtainen (eli sinun henkilökohtainen avaimesi), ja palvelimelle vain asetetaan, että kyseisellä avaimella on oikeus kirjautua palvelimelle. Se on juuri tämän epäsymmetrisen kryptografian idea: julkista avainta voi huoletta jakaa vaikka julkisesti, kunhan oma yksityinen avain pysyy tallessa.

Käytännössä siis vain ajat komennon ssh-copy-id jokaiselle kirjautumiskohteelle, minkä jälkeen oma avaimesi toimii näihin suoraan. Tällä tavalla vältät kaikki useaan avaimeen liittyvät ongelmat. Mitään säätöjä asetustiedostoihin ei tarvita.

Jos jostain syystä joudut käyttämään useaa eri avainta, voit valita avaimen ssh-komennossa parametrilla -i.

En tiedä, miten olet yrittänyt ”poistaa salasanan kysymisen käytöstä”, mutta toivottavasti et ole ainakaan huonontanut palvelimen tietoturvaa vahingossa. Yleensä oletusasetukset sallivat avaimella kirjautumisen, eli ei tarvitse tehdä asetuksiin muutoksia, kunhan kopioi avaimet ssh-copy-id-komennolla (tai tietysti myös käsin voi säätää tiedostoa .ssh/authorized_keys).

Kopioinnissa parempi työkalu on rsync, joka siis myös käyttää SSH-yhteyttä mutta käsittelee tiedostoja paljon sujuvammin kuin scp.

Tuota en tiennytkään. Hienoa! Kiitos! Eli voin käyttää samaa public-private key paria kaikilla kahden serverin neljällä käyttäjällä?

Kun sanoin poistanut salasanan käytöstä, tarkoitin, että olen molemmilla servereillä sekä /etc/ssh/ssh_config että /etc/ssh/sshd_config tiedostoissa asettanut PasswordAuthentication no. Onko tämä väärä tapa toimia, pitäisikö minun kommentoida nämä pois niin kuin ne alunperin oli?

Muutenkin riittää että on yksi käyttäjä jolla sudo oikeus. Tämän avulla voi tarvittaessa siirtyä toiseksi käyttäjäksi.

AkeMake kirjoitti:

Eli voin käyttää samaa public-private key paria kaikilla kahden serverin neljällä käyttäjällä?

Ehdottomasti. Jos joskus vaikka palvelimen omistusoikeus siirtyisi toiselle henkilölle, poistettaisiin vain avain palvelimen listasta. Tai jos kaverin pitäisi auttaa säädössä, laitettaisiin väliaikaisesti myös kaverin avain listalle.

AkeMake kirjoitti:

sekä /etc/ssh/ssh_config että /etc/ssh/sshd_config tiedostoissa asettanut PasswordAuthentication no.

Ainakin ssh_config on syytä jättää ennalleen, jos ei ole tarkoitus estää salasanan käyttöä myös palvelimelta muihin kohteisiin yhdistäessä.

Sinänsä sshd_config voi olla noin, jos olet varma, että avain on aina saatavilla. Toisaalta usein asetetaan salasanan esto vain root-käyttäjälle, hieman hassun kuuloisesti PermitRootLogin without-password. Oma salasana on syytä valita hyvin (https://xkcd.com/936/). Hyökkäyksiä (ja turhaa kuormitusta) voi estää jollain ohjelmalla, joka seuraa lokia ja estää virheitä tekevät IP-osoitteet.

Kävin kommentoimassa "PasswordAuthentication no" kohdat pois ja poistin public-private avaimet koneeltani (en lopullisesti). Nyt en kuitenkaan pääse kirjautumaan sisään salasanan kanssa niin kuin luulin, että kävisi. Sen sijaan saan ilmoituksen "Permission denied (publickey)".
Mitä minun täytyy vielä tehdä, että pääsen takaisin alkuun eli poistan SSH:n ja voin kirjautua sisään salasanan kanssa?

Nyt taisin sotkea homman pahasti. Jostain netin syövereistä koetin lukea ohjeita mitä tehdä, joten päädyin siirtämään kaikki serverilläni /etc/ssh kansiossa olevat tiedostot /etc/ssh/backup kansioon. Siis ihan kaikki tiedostot... Nyt en pääse kirjautumaan kyseiselle serverille ollenkaan. Antaa ilmoituksen ssh: connect to host [IP1] port 22: Connection refused. Näin jälkiviisaana veikkaan, että ssh_config ja sshd_config tiedostot olisi pitänyt jättää paikalleen.

Voikohan tätä korjata ollenkaan, kun en pääse kirjautumaan serverille alkuunkaan.. Voisikohan palveluntarjoajani tehdä tälle asialle mitään? :-/

EDIT:
Otin yhteyttä palveluntarjoajaani ja he onnistuivat korjaamaan tämän tilanteen. Eli olen takaisin alkuperäisessä ongelmassa. Kuinka tyhjennän SSH:n serveriltäni niin, että voisin asettaa uudet avaimet. :)

Sain nyt kaikki SSH avaimet servereillä nollattua palveluntarjoajan avustuksella ja asetettua ne kaikki yhden ja saman avaimen taakse. Siinä oli kyllä sen verran sähläystä mukana, etten ole ihan varma mitä kaikkea tuo SSH avainten nollaaminen lopulta vaati. Jospa tämä SCP ongelma olisi nyt tällä ratkaistu. :D

Eikö sinulla ole pääsyä palvelimelle esimerkiksi palveluntarjoajan hallintapaneelin kautta? Usein sieltä pääsee käyttämään virtuaalipalvelinta ikään kuin olisi koneen ääressä.

Joka tapauksessa palvelimen etäyhteyttä säätäessä ei ole varaa virheisiin. Tähän sisältyvät palvelimen verkkoasetukset ja SSH. Palvelimen säätämistä kannattaa harjoitella kotikoneella, ja /etc:stä kannattaa säilyttää toimiva varmuuskopio.

Muutenkin ennen säätämistä kannattaa hieman perehtyä siihen, miten ne käytettävät ohjelmat toimivat. OpenSSH-palvelimen asetustiedostot ja palvelimen avaimet (joilla siis käyttäjä tunnistaa palvelimen) ovat sijainnissa /etc/ssh, ja nämä sinä käytännössä poistit ja vieläpä aivan turhaan, koska näillä ei ollut mitään tekemistä kirjautumiseen käytettävien avainten kanssa (paitsi siltä osin, mitä itse asetustiedostoon muutit). Käyttäjän kirjautumiseen sallitut julkiset avaimet ovat (asetuksen AuthorizedKeysFile mukaan) oletuksena kunkin käyttäjän omassa kotihakemistossa tiedostossa ~/.ssh/authorized_keys, josta niitä voi muokata tekstieditorilla. Vanhoja avaimia ei kannata poistaa, ennen kuin uudet ovat varmasti paikallaan tai kirjautuminen salasanalla on sallittu.

Onko jokin syy käyttää 4 vuotta vanhaa Linux-jakelua? Lisäksi kysymyksissä on yleensä tärkeää kertoa, mikä jakelu on kyseessä, koska eri jakeluissa ohjelmia asennetaan ja asetuksia säädetään eri tavalla. (Ei ole olemassa sellaista kuin Linux 16.04.) Onneksi nyt SSH:n kohdalla ei ole suurta eroa.

Käytössäni on Ubuntu 16.04 64bit. Tämä sen vuoksi, että serverillä pyörii BigBlueButton, joka vaatii sitä. He eivät ole vielä julkaisseet uutta BigBlueButton versiota Ubuntu 18.04:lle. Valitettavasti sain juuri tietää, että meidän tarve BigBlueButtonille on sen verran suuri, ettei tämä serveri, jota tällä hetkellä käytämme ole riittävän tehokas sille. Minun on pitänyt opetella näitä monia asioita ihan nollasta todella lyhyellä varoitusajalla, joten on tullut sitten tehtyä monia virheitä.

Ihan sellainen vinkki, että on paljon helpompaa opetella asioita omalta koneelta käsin asentamalla Linux virtuaalikoneeseen. Toki noissa VPS-palveluissakin on webbikonsoli, jonka kautta pääset kirjautumaan sisään, jos sekoilet ja tuhoat oikean etäyhteyden. Asiakaspalvelun kiusaaminen näissä asioissa on turhaa.

Josset ymmärrä, mitä olet tekemässä, niin kaikista tyhmin asia on tuhota järjestelmäasetusten tiedostoja. Ota sen sijaan backupit, jotka palautat sitten, kun toteat että on tarpeen tehdä reset.