Problem med ssh

Labbtus · 20. mars 2013

Har tidligere satt opp en hjemmeserver; etter mye hjelp fra dere på forumet er - link

Etter en krasj på en av serverne er den nå formatert og satt opp på nytt med Ubuntu og Amahi. Problemet nå er at jeg får bare ssh til å fungere en vei, ikke opp til den nye serveren. (Har fått koblingen opp mot den gamle Fedora 12 og Amahiserveren til å fungere igjen).

- Har satt opp med id_rsa.pub som er kopiert inn i authorized_keys på motsatt server

- kjørt ssh-add

- endret i /etc/ssh/sshd_config: (rootlogin, passwrd auth og RSA identification)

- kjørt sudo /etc/init.d/ssh reload (på fedora måtte jeg endre til sshd)

Begge serverne finner jeg via canyouseeme.org, på porten jeg forsøker å kontakte. Og jeg mener begge routerne er satt opp riktig ift å forwarde porter.

Kjører følgende kommando:

$ cat /home/labbtus/cron/passwka | sshfs -p xxx -o idmap=user -o password_stdin nabo.yourhda.com:backup /backup
read: Connection reset by peer

$ ping nabo.yourhda.com
PING nabo.yourhda.com (xxx.yyy.zzz.zzz) 56(84) bytes of data.
^C
--- nabo.yourhda.com ping statistics ---
16 packets transmitted, 0 received, 100% packet loss, time 15000ms

$ ssh -p xxx  [email protected]
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@	   WARNING: POSSIBLE DNS SPOOFING DETECTED!		  @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
The RSA host key for [nabo.yourhda.com]:xxx has changed,
and the key for the corresponding IP address [xxx.yyy.zzz.zzz]:xxx
is unknown. This could either mean that
DNS SPOOFING is happening or the IP address for the host
and its host key have changed at the same time.
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@	WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!	 @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
key:key:key:key.
Please contact your system administrator.
Add correct host key in /home/labbtus/.ssh/known_hosts to get rid of this message.
Offending key in /home/labbtus/.ssh/known_hosts:3
RSA host key for [nabo.yourhda.com]:xxx has changed and you have requested strict checking.
Host key verification failed.

Noen gode forslag til videre debugging?

Del · 20. mars 2013

Ah, du har endret nøkkelen. Ssh nekter å logge på før du har fjernet den gamle nøkkelen. Bare kjør kommandoen som blir foreslått.

Oops så nettopp at du ikke får kommando forslag, så dette er vel en fedoraboks. Bare åpne known hosts filen og slett linje nummer tre.

Labbtus · 20. mars 2013

$ ssh -p xxx [email protected]
Permission denied (publickey).

Ett steg videre :-)

Del · 20. mars 2013

Nøkkelen er antagelig ikke kopiert over riktig. Prøv å kopiere den over igjen.

Oops kom til å tenke på. Har du slettet den gamle nøkkelen?

Labbtus · 20. mars 2013

Prøvde å kopiere en gang til, samme resultat.

Slettet alle filene i .ssh-katalogen; opprettet ny nøkkel og kopierte fra id_rsa.pub til authorized_keys; igjen med samme resultat.

$ ssh -p xxx [email protected]
The authenticity of host '[nabo.yourhda.com]:xxx ([xxx.yyy.zzz.zzz]:xxx)' can't be established.
RSA key fingerprint is key:key:key.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '[nabo.yourhda.com]:xxx,[xxx.yyy.zzz.zzz]:xxx' (RSA) to the list of known hosts.
Permission denied (publickey).

Kan problemet ligge i /etc/ssh/ssh_config eller i /etc/ssh/sshd_config?

Fant noen forskjeller i ssh_config som jeg har rettet opp i, men får samme resultat.

Kjørte service ssh reload etter endringene...

Endret 20. mars 2013 av Labbtus

Del · 21. mars 2013

Bare en kryssjekk. Genererte du nøkkelen på maskinen du kobler deg opp fra? Kopierte du innholdet av id_rsa.pub til filen authorized_keys på serveren du forsøker å koble deg til?

Hvis du likevel får feilmeldingen over, forsøk å tillate passord login i /etc/ssh/sshd_config (ja, det er denne som skal redigeres). Dvs. sett

PasswordAuthentication yes

så kan du prøve å logge på igjen etter å ha tatt en

ssh service ssh reload

Til slutt, få se på rettighetene som er satt på filene (gjerne på begge maskinene):

ls -l .ssh

Endret 21. mars 2013 av Del

Crowly · 21. mars 2013

Sjekk rettighetene/eierskapet på mappene og filene, hele pathen fra / til ~/.ssh/

/var/log/auth.log vil vise om du har feil rettigheter eller eierskap ett sted.

mapper t.o.m. /home/<brukernavn/ skal ha 755. Ingen grunn til at det skal være endret, men skader ikke å sjekke

.ssh/ => 700

id_rsa => 600

id_rsa.pub => 644

authorized_keys => 644

Endret 21. mars 2013 av Crowly

Labbtus · 21. mars 2013

Gått over tilgangene og de ser ut til å stemme (ift oppsettet til Crowly).

Har generert id_rsa på maskinen jeg forsøker å koble opp fra, og lagt innholdet i id_rsa.pub inn i authorized_keys under "min" mappe på naboens server (/home/labbtus/.ssh/authorized_keys).

Endret til PasswordAuthentication yes; og fikk da logget på naboens server:

$ ssh -p xxx [email protected]
Welcome to Ubuntu 12.04.1 LTS (GNU/Linux 3.2.0-35-generic x86_64)
* Documentation:  https://help.ubuntu.com/
272 packages can be updated.
112 updates are security updates.
Last login: Thu Mar 21 17:34:34 2013 from xxx.yyy.zzz.zzz
labbtus@naboserver:~$ logg ut
Connection to nabo.yourhda.com closed.

Endret tilbake til PasswordAuthentication no; restartet ssh service; og fikk fremdeles logget på.

Forsøkte så denne:

$ cat /home/labbtus/cron/passwka | sshfs -p xxx -o idmap=user -o password_stdin nabo.yourhda.com:backup /backup
read: Connection reset by peer

Men her ble det stopp igjen...

Siden jeg er usikker på noen av disse tingene midt i her forsøkte jeg denne:

$ cat /home/labbtus/cron/passwka | sshfs -p xxx -o nabo.yourhda.com:backup /backup

Som fungerte...

Fikk koblet opp og vist innholdet på /backup.

Vil dette da fungere fremover dersom jeg endrer kommandoen til dette i "kommandofilen" jeg kjører via cron?

Dersom dette vil fungere kan jeg kanskje lukke denne tråden og lage en ny for neste? :-)

Neste problem er montering av disk på naboens server. En disk hos han har krypterte data, som jeg vil montere inn under /home/labbtus/backup.

Endret i /etc/fstab:

/dev/sde1	   /home/labbtus/backup	 ext4	defaults		1 2

Og forsøker å montere:

# mount -a
mount: wrong fs type, bad option, bad superblock on /dev/sde1,
   missing codepage or helper program, or other error
   In some cases useful info is found in syslog - try
   dmesg | tail  or so

Hvordan kan jeg debugge dette?

Finner dette i syslog:

Mar 22 20:15:00 vt72 kernel: [858736.749400] EXT4-fs (sde1): VFS: Can't find ext4 filesystem

$fdisk -l
Disk /dev/sde: 2000.4 GB, 2000398934016 bytes
81 heads, 63 sectors/track, 765633 cylinders, total 3907029168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x0003b5d7

  Device Boot	  Start		 End	  Blocks   Id  System
/dev/sde1		    2048  3907029167  1953513560   83  Linux

Endret 22. mars 2013 av Labbtus

Del · 25. mars 2013

Endret tilbake til PasswordAuthentication no; restartet ssh service; og fikk fremdeles logget på.

Da er sshfs i boks såvidt jeg kan skjønne.

Siden jeg er usikker på noen av disse tingene midt i her forsøkte jeg denne:
$ cat /home/labbtus/cron/passwka | sshfs -p xxx -o nabo.yourhda.com:backup /backup
Som fungerte...

Fikk koblet opp og vist innholdet på /backup.

Vil dette da fungere fremover dersom jeg endrer kommandoen til dette i "kommandofilen" jeg kjører via cron?

Ja, generelt vil jeg anbefale å unngå for komplekse kommandoer. Det blir fort uoversiktlig. Velkjent prinsipp innen programmering:

http://en.wikipedia.org/wiki/KISS_principle

Neste problem er montering av disk på naboens server. En disk hos han har krypterte data, som jeg vil montere inn under /home/labbtus/backup.

Hvordan er den kryptert?

Labbtus · 25. mars 2013

Da er sshfs i boks såvidt jeg kan skjønne.

Ja, generelt vil jeg anbefale å unngå for komplekse kommandoer. Det blir fort uoversiktlig. Velkjent prinsipp innen programmering:

http://en.wikipedia..../KISS_principle

Hvordan er den kryptert?

Hei,

den er kryptert med encfs.

Sync kjøres etter dette prinsippet:

sshfs user@nabo:/mount/nabo /mount/encbackup

encfs /mount/encbackup /mount/backup

rsync /mount/raid/backup /mount/backup

Trenger nå å montere opp backupen hos naboen mot folderen backup på min brukermappe hos han.

Er helt blank ift hva som kan være feil her, men har det noe å si hvilken kryptering som er på disken?

Del · 25. mars 2013

Er helt blank ift hva som kan være feil her, men har det noe å si hvilken kryptering som er på disken?

Ja, noen løsninger krypterer hele disken, og da må man ta det med når man monterer. Encfs er ikke slik, så du gjør det riktig. Kunne tenkt meg å se partisjonene på den disken, kan du kjøre fdisk med sudo?

sudo fdisk -l

Labbtus · 25. mars 2013

Skal få testet det mot slutten av uka. Ikke tilgang på serverne nå i påska :-)

Takk for hjelpen så langt; og riktig god påske!

Labbtus · 31. mars 2013

Ja, noen løsninger krypterer hele disken, og da må man ta det med når man monterer. Encfs er ikke slik, så du gjør det riktig. Kunne tenkt meg å se partisjonene på den disken, kan du kjøre fdisk med sudo?
sudo fdisk -l

Hei igjen,

Se utklipp fra fdisk -l under.

sudo fdisk -l
Disk /dev/sde: 2000.4 GB, 2000398934016 bytes
81 heads, 63 sectors/track, 765633 cylinders, total 3907029168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x0003b5d7

Device Boot	  Start		 End	  Blocks   Id  System
/dev/sde1			2048  3907029167  1953513560   83  Linux

Trodde 83 Linux skulle være riktig ift ext4?

Del · 31. mars 2013

Hm, ser ut som det er riktig partisjon. Sjekk at monteringsmappen finnes,

ls /home/labbtus/

så prøv å montere manuelt

sudo mount -t ext4 /dev/sde1 /home/labbtus/backup

hvis den fortsatt klager på filsystem, kanskje du brukte ext3 da du formaterte?

Labbtus · 31. mars 2013

Hm, ser ut som det er riktig partisjon. Sjekk at monteringsmappen finnes,
ls /home/labbtus/
så prøv å montere manuelt
sudo mount -t ext4 /dev/sde1 /home/labbtus/backup
hvis den fortsatt klager på filsystem, kanskje du brukte ext3 da du formaterte?

Mappen er der, og er tom.

# sudo mount -t ext4 /dev/sde1 /home/labbtus/backup
mount: wrong fs type, bad option, bad superblock on /dev/sde1,
   missing codepage or helper program, or other error
   In some cases useful info is found in syslog - try
   dmesg | tail  or so

Disken er tidligere formatert til ext4.

Del · 31. mars 2013

Hm, høres ut som filsystemet er skadet, forsøk å fikse det med;

fsck.ext4 -fyv /dev/sde1

Labbtus · 31. mars 2013

# fsck.ext4 -fyv /dev/sde1
e2fsck 1.42 (29-Nov-2011)
fsck.ext4: Superblock invalid, trying backup blocks...
fsck.ext4: Bad magic number in super-block while trying to open /dev/sde1
The superblock could not be read or does not describe a correct ext2
filesystem.  If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
   e2fsck -b 8193 <device>

Og denne:

# e2fsck -b 8193 /dev/sde1
e2fsck 1.42 (29-Nov-2011)
e2fsck: Bad magic number in super-block while trying to open /dev/sde1
The superblock could not be read or does not describe a correct ext2
filesystem.  If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
   e2fsck -b 8193 <device>

Del · 31. mars 2013

Har du en kopi av dataene som ligger på denne partisjonen? Isåfall er kanskje det greieste å lage ny partisjon og legge over dataene på nytt. Hvis ikke må vi prøve forskjellige databergingsteknikker.

Labbtus · 2. april 2013

Har kopi på den andre serveren, men hadde håpet å spare syncing av 500Gig over internettlinjen.

Men, ser ut til at det blir løsningen; får ta det i små porsjoner.

Men, takk for hjelpen, var verdt et forsøk.

Del · 2. april 2013

Ta med disken hjem, så overfører du 500GB på noen timer. Ikke vent med å få back-up på plass

Forresten, sørg for å sjekke diskene mens du er i gang!

Bruk smartctl:

http://www.howtoforge.com/checking-hard-disk-sanity-with-smartmontools-debian-ubuntu

Problem med ssh

Anbefalte innlegg

Lenke til kommentar

Videoannonse

Lenke til kommentar

Lenke til kommentar

Lenke til kommentar

Lenke til kommentar

Lenke til kommentar

Lenke til kommentar

Lenke til kommentar

Lenke til kommentar

Lenke til kommentar

Lenke til kommentar

Lenke til kommentar

Lenke til kommentar

Lenke til kommentar

Lenke til kommentar

Lenke til kommentar

Lenke til kommentar

Lenke til kommentar

Lenke til kommentar

Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Opprett konto

Logg inn

Hvem er aktive 0 medlemmer