SSH ja SFTP-palvelin [wiki]

[Nahjus]

Ja kyllä nuo muut tunnukset toimii jotka on lisätty ennen tuota uutta.

[Tonde]

onko salasanassa skandeja? sillon vois joku merkistösekaannus? Ei ole varmasti iso vika, jos yhteys toimii kaikilla, paitsi yhdellä tunnuksella...

[Nahjus]

ei ole salasanassa skandeja

[Squirrel]

Kokeile toisella tunnuksella kirjautumista ja kirjoita:

Koodia: [Valitse]

su - (uusi_kayttajatunnus_jota_asken_kokielit)

Ja sitten sen salasana (ei omaa vaan sen uuden), jos se hyväksyy, niin vika on SSH:ssa. Onko sshd_configissa allow ja deny määritteitä? Jos on, niin minkälaiset ne on?

[JJK]

Edgy ei anna luoda 2048 bittistä avain. Dapperilla kyllä onnistuu.

Koodia: [Valitse]

xx@PC:~$ ssh-keygen -b 2048 -t dsa
DSA keys must be 1024 bits

[f0nzarelli]

mitä avaimet "/etc/ssh"-hakemistossa ovat. Pitääkö niiden pääle kirjoittaa uudet public ja private-avaimet?

"~/ssh."-hakemistoon "authorized_keys"-tiedotoon liitetään loppuun public-key.. laitetaanko samaan hakemistoon private-key, jos laitetaan niin minkä nimisenä..

miten yhteyden saa toimimaan windowsin "ssh secure shell client"-terminaalilla...?

Mulla on ubuntu edgy eft (6.10) versio ja siinä mukana tullut openSSH..

Mä oon kokeillu kaikke mahdollista.. ohjeiden mukaan ja puttyllä (puttygenillä tein vielä privaattiavaimen ym...) 

Nämä ohjeet on myös kokeiltu huolellisesti....... silti ei vaa skulaa.... 
http://www.andremolnar.com/how_to_set_up_ssh_keys_with_putty_and_not_get_server_refused_our_key


Virheilmotuksia:

SSH Secure Shell client:
Server responded "No further authentication methods available..."

Putty:
Server refused our key
No supported authentication methods left to try!

Tos on mun sshd_config:

Koodia: [Valitse]

# Package generated configuration file
# See the sshd(8) manpage for details

# What ports, IPs and protocols we listen for
Port 2222
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2
# HostKeys for protocol version 2
 HostKey /etc/ssh/ssh_host_rsa_key
 HostKey /etc/ssh/ssh_host_dsa_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes

# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 768

# Logging
SyslogFacility AUTH
LogLevel INFO

# Authentication:
LoginGraceTime 120
PermitRootLogin yes
StrictModes yes

RSAAuthentication no
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

# Kerberos options
#KerberosAuthentication no
#KerberosGetAFSToken no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
#UseLogin no

#MaxStartups 10:30:60
Banner /etc/issue.net

# Allow client to pass locale environment variables
AcceptEnv LANG LC_*

Subsystem sftp /usr/lib/openssh/sftp-server

UsePAM no

Jos joku jaksais / osais auttaa, niin olisin (melkein) ikuisesti kiitollinen ... 

[f0nzarelli]

Autan sitten itseäni .... 

Näiden rivien kommentointi sshd_config-tiedostota

Koodia: [Valitse]

HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
ratkaisi onkkelman...

Nyt toimii puttyllä ja ssh secure shell clientillä..

EDIT: tämä on potaskaa, lue alaspäin!!

[janne]

mitä avaimet "/etc/ssh"-hakemistossa ovat. Pitääkö niiden pääle kirjoittaa uudet public ja private-avaimet?

palvelimen avaimet. palvelin tarvitsee omat avaimet, jotta man-in-the middle tyyppisen hyökkäyksen tunnistaminen olisi mahdollista.

"~/ssh."-hakemistoon "authorized_keys"-tiedotoon liitetään loppuun public-key.. laitetaanko samaan hakemistoon private-key, jos laitetaan niin minkä nimisenä..

private key on ainoastaan sillä koneella josta logataan, eikä sitä tarvitse siirtää mihinkään. se määritellään sisään loggaavan sovelluksen käytettäväksi. linuxissa tuo tapahtuu oletusnimillä automaattisesti.

[debuntu]

Nyt taisi onkelma selvitä mutta ei tullut vielä ratkaistuksi. Onkelma on, että palvelin eli minun koneeni hylkää avaimen, koska PuTTy sanoo näin:

login as: samuli
Server refused our key
No supported authentication methods left to try!

Mitä pitäisi tehdä?

Hei

Mikä ratkasu tähän. Heittää koko ajan saman, vaikka mitä muuttaisi!

[f0nzarelli]

Nyt taisi onkelma selvitä mutta ei tullut vielä ratkaistuksi. Onkelma on, että palvelin eli minun koneeni hylkää avaimen, koska PuTTy sanoo näin:

login as: samuli
Server refused our key
No supported authentication methods left to try!

Mitä pitäisi tehdä?

Hei

Mikä ratkasu tähän. Heittää koko ajan saman, vaikka mitä muuttaisi!

EDIT: ### Poistettu puoli-virheellistä tietoa tästä ###

tee palvelimelle ~/.ssh - hakemisto ja sille oikeudet 700

Koodia: [Valitse]

mkdir ~/.ssh
chmod 700 ~/.ssh

tee avaimet palvelimellasi sillä käyttäjällä mille haluat avaimet tehdä:
hyväksy avaimille ehdotetut oletussijainnit.
Kannattaa kirjoittaa joku salasana passphreseen. Jos avain joutuu vääriin käsiin, sitä ei voi käyttää ilman passphreseä.

Koodia: [Valitse]

ssh-keygen -t dsa
seuraavaksi kopioi julkinen avain authorized_keys nimiseksi tiedostoksi:

Koodia: [Valitse]

cp ~/.ssh/id_dsa.pub ~/.ssh/authorized_keys
tarkista että authorized_keys-tiedostossa on vain yksi rivi (yksi avain per rivi)

voit tuhota id_dsa.pub-tiedoston

kopioi id_dsa-tiedosto koneelle missä käytät puttyä.

lataa itsellesi ohjelma "puttygen.exe" (googlesta löytyy)

käynnistä puttygen.exe

paina LOAD nappia ja valitse id_dsa tiedosto. (jos laitoit passphresen avainten luonnin yhteydessä, puttgen kysyy sen)

paina save private key nappia ja anna avaimelle joku nimi (esim. avain.ppk)

mene puttyn asetuksiin: connection -> ssh -> auth ja private key file for authencation kohtaan laitat tiedoston, minkä teit äsken (avain.ppk)

sitten kirjaudut palvelimelle..... (ja eiku koodia vääntämää) 

[debuntu]

Kiitos avusta!

En kuitenkaan tuota risuaitaa(kommenttia) tonne eteen (jotain rsa_host_key jne.) laittanut, koska jannen mukaan serveri tarvitsee sitä.

Keskityin kuitenkin siihen, että miksi avaimet ei täsmää.
Tosi vähän olen ollut noitten avainten kanssa tekemisissä.
Siksi en ymmärtänyt mitä avaimessa piti oikein olla.

siis

commentin (joka oli kopioidussa tiedostossa) korvasin ssh-dss :llä tämän jälkeen avain yhdellä rivillä ja sen jälkeen laitoin loppuun vielä dsa-key- "numerosarja".

ja wot lähdöi peljittää   

tietenkin helppoiten avaimen kopiointi onnistuu puttyn keygenin avulla.
siellä jopa taitaa englanniksi lukea jos nyt oikein muistan, että kopioi tämä openssh:n avaimen tiedostoon.

olin kuitenkin alussa avaimen ensin tallentanut public-avaimeksi ja sitten sieltä kopioinut avaimen.
silloin avain muistaakseni sisälsi tuon comment: kohdan. ja lopusta puuttu tuo numerosarja.


Kiitos kuitenkin neuvosta!
Joskus se on pienestä kiinni!

 

[f0nzarelli]

Näiden rivien kommentointi sshd_config-tiedostota

Koodia: [Valitse]

HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
ratkaisi onkkelman...

toi onkin täyttä potaskaa...
ei niitä tarvitse kommentoida. otin juuri #-merkit pois, ja homma pelittää vieläkin..

vika johtui siitä että avaimet eivät olleet samaa formaattia..
DSA-avaimia on (ainakin) ssh.com- , openSSH-formaattia...
sain muutettua ne samaan formaattiin puttygenillä conversions-valikosta...

ssh-keygen -t dsa-käsky teki minulla puttygenin ssh.com-formaattia vastaavan avaimen.
tein avaimet serverillä ja muutin privaattiavaimen asiakaskoneella puttygenillä ssh.com-muotoon ja painoin save private key-nappia..

en ole varma onko formaatti oikea sana kuvaaaan dsa-avainten eroja. mutta niitä on vähän erinäkösiä muunnoksia. en oo perehtynyt aiheeseen paremmin..

P.S. authorized_keys-tiedostoon ei tarvi lisätä niitä kommenttirivejä.... kannattaa varmistaa että tekstieditori ei lisää sinne automaattisesti rivinvaihtoa....

[snowone]

Asennus ei pääty niin kuin pitäisi:

Unpacking openssh-server (from .../openssh-server_1%3a4.3p2-5ubuntu1_i386.deb) ...
Säädän asetukset: openssh-server (4.3p2-5ubuntu1) ...
Creating SSH2 RSA key; this may take some time ...
 * Restarting OpenBSD Secure Shell server...                                   
Could not load host key: /etc/ssh/ssh_host_dsa_key
Could not load host key: /etc/ssh/ssh_host_dsa_key


Avaimethan meillä kyllä on:

jyrki@Iglu-server:/etc/ssh$ ls -l
yhteensä 164
-rw-r--rw- 1 root root 132839 2006-10-05 12:43 moduli
-rw-r--rw- 1 root root   1423 2006-10-05 12:43 ssh_config
-rw-r--rw- 1 root root   1870 2007-02-16 12:58 sshd_config
-rw-r--rw- 1 root root   1870 2007-02-16 01:33 sshd_config~
-rw------- 1 root root    744 2007-02-16 13:29 ssh_host_dsa_key
-rw-r--r-- 1 root root    606 2007-02-16 13:29 ssh_host_dsa_key.pub
-rw------- 1 root root   1679 2007-02-16 13:35 ssh_host_rsa_key
-rw-r--r-- 1 root root    398 2007-02-16 13:35 ssh_host_rsa_key.pub


Palvelin toimii, mutta avaimia ei saa käyttöön.

Joltakin kysyttiin että onko ssh-kansion oikeudet oikein, mitkähän ne pitäisi olla? En ole kyllä koskenut.

EDIT: Pari uudelleen asennusta ja kansioiden poisto ja uudelleen luonti niin homma lähti toimimaan. Ratkaisu: tuntematon.

[jnr21]

vähän asiasta poiketen.
Eli toimii muuten hyvin mutta ku loin uuden userin, niin en voi kuitenkaan sillä enää kopioida enkä tallentaa tiedostoja servulle nautiluksella.

Koodia: [Valitse]

Tiedoston "ssh://käyttäjä@ip/opt/lampp/htdocs/filu.php" tallentaminen epäonnistui.
Oikeutesi eivät riitä tiedoston kirjoittamiseen. Tarkista että annoit sijainnin oikein ja yritä uudelleen.
Ennenhän tää onnistu ju käytin roottia.

[Vapaan koodin kananmuna]

vähän asiasta poiketen.
Eli toimii muuten hyvin mutta ku loin uuden userin, niin en voi kuitenkaan sillä enää kopioida enkä tallentaa tiedostoja servulle nautiluksella.

Koodia: [Valitse]

Tiedoston "ssh://käyttäjä@ip/opt/lampp/htdocs/filu.php" tallentaminen epäonnistui.
Oikeutesi eivät riitä tiedoston kirjoittamiseen. Tarkista että annoit sijainnin oikein ja yritä uudelleen.
Ennenhän tää onnistu ju käytin roottia.

Tavallisen juuserin ei kuulukaan saada tallentaa /opt hakemistoon. Kopioi ne tiedostot vaikka juuserin kotihakemistoon ja siirrä päätteellä sudon avulla sinne mihin haluat.

[miitsu]

Minulla on ongelmia tuon X11 Forwardingin kanssa.

Eli, olen siis asentanut ssh -palvelimen tässä threadissä olleen ohjeen mukaan ja olen onnistuneesti ottanut käyttöön avaimilla tunnistautumisen. Pohjalla on 6.10 serveri asennus (LAMP). Koneessa, jolla otan ssh -yhteyden, on WinXP, Putty ja Reflection. Puttyssa olen ruksannut enable X11 forwarding -kohtan ja kokeillut X display locationia osoittella 127.0.0.1 ja ilman (tällä ei kyllä käsittääkseni ole merkitystä, sillä Puttyn pitäisi käyttää oletuksena 127.0.0.1).

X-ikkunoiden avaus muista koneista ssh -yhteyden yli pelaa kyllä kyseisellä kokoonpanolla. Mutta kun otan yhteyden tähän kotipalvelimeeni ja yritän avata nedit -editoria, niin saan herjan "Can't open display". Tämänkin nyt on kyllä aika luonnollista, sillä DISPLAY -ympäristömuuttujaa ei ole asetettuna automaattisesti (muihin koneisiin yhteyden ottaessani DISPLAY -muuttuja on asetettuna automaattisesti, missä ero?). Mutta asiaan ei auta, vaikka käsin ajaisin komennon "export DISPLAY=localhost:0.0". Niin käsittääkseni se X11 forwarding pitäisi toimia juuri näin ja saan kyllä kotona x-ikkunat aukeamaan, mikäli määrittelen DISPLAY -muuttujaan "pääkoneeni" IP-osoitteen, mutta tällöinhän ikkuna ei tule ssh -tunnellia pitkin(?), eikä toimi esim. kun olen toimistolla palomuurin (itseasiassa useammankin) takana.

Olen myös epäillyt, että mahdollisesti iptables -asetukseni estävät x-ikkunoiden avautumisen, mutta en ole onnistunut vikaa sieltä löytämään. Olen sallinut kaiken sisään ja ulos menevän liikenteen loopback -interfacelle (127.0.0.1).

Alkaa pikkuhiljaa tuskastuttamaan, sillä olen lukenut foorumeita ja websivuja jo useamman tunnin ajan, eikä hieman linuxin kanssa kokeneempi työkaverinikaan osannut auttaa... Toivottavasti täältä löytyy apu.

Tässä vielä muutamia tähän asiaan liittyviä konfiguraatioita.

Koodia: [Valitse]

/etc/ssh/sshd_config
# Package generated configuration file
# See the sshd(8) manpage for details

# What ports, IPs and protocols we listen for
Port 22
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes

# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 768

# Logging
SyslogFacility AUTH
LogLevel INFO

# Authentication:
LoginGraceTime 120
#PermitRootLogin yes
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

# Kerberos options
#KerberosAuthentication no
#KerberosGetAFSToken no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
#UseLogin no

#MaxStartups 10:30:60
#Banner /etc/issue.net

# Allow client to pass locale environment variables
AcceptEnv LANG LC_*

Subsystem sftp /usr/lib/openssh/sftp-server

UsePAM yes

AllowUsers tunnukseni


Koodia: [Valitse]

sudo iptables --list
Chain INPUT (policy DROP)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere            state RELATED,ESTABLISHED
REJECT     tcp  --  anywhere             anywhere            tcp option=!2 reject-with tcp-reset
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:ssh
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:www

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere
DROP       icmp --  anywhere             anywhere

Huomaa, että iptables tulosteessa INPUT:n "ACCEPT     all  --  anywhere             anywhere" ja OUTPUT:n "ACCEPT     all  --  anywhere             anywhere" tulevat loopback -interfacesta, eli komennoista:
/sbin/iptables -A INPUT -i lo -p all -j ACCEPT
/sbin/iptables -A OUTPUT -o lo -p all -j ACCEPT

[miitsu]

Itse itselleni vastaten xauth -paketti oli asentamati ja nyt pelaa...

[Marbo]

Elikkäs tässä just asentelin tämän ssh-palvelimen, ja sain toimimaan muuten. Yhdisti kaikkialta myös kaverin windowsista putylla. Mutta ongelma on se, että miks ihmeessä se menee servun työpöydälle kun käynnistää putyllä ssh yhteyden ja kattoo "dir" komennolla mitä se sanoo. Tarvisin pikaista apua tässä asiassa.

Joo elikkäs nyt sain toimimaan

[carpenter]

Väsäilin sftp palvelimen pystyyn ja jätän kumminkin nuo vaativammat
salaushässäkät tekemättä, ja varmistan turvallisuuttta sillä että luon
palomuuriin reitin vain yhdestä ipstä käyttää palvelinta.

Onko mitenkään mahdollista että kun tietyllä tunnuksella loggaa sisään
ni näkee vain oman kotihakemiston ja sen alapuolella olevat systeemit,
muttei kumminkaan pysty edes brousaamaan hakemistorakennetta ylöspäin??

Nythän tilanne ilmeisesti oletuksena on se että ylöspäin pystyy selaileen, vaikkei
mitään oikeuksia ole kumminkaa touhuta ylhäälläpäin.

[T.M]

Käyttäjän voi lukita kotihakemistoon ainakin seuraavalla tavalla
http://forum.ubuntu-fi.org/index.php?topic=484.0