• Tjenester
  • PC
  • Server
  • Nettverk
  • Programmering
• Kontakt
• Om
  • Om psdigital
  • Referanser
  • Priser
• Annet
  • Datatips
  • Blog
  • bits & bytes
  • Artikler >
    • Telnet
    • Dualboot
    • Remote Desktop

Du er her: Hjem --> Annet --> Blog --> SSH til Mac avansert

SSH til Mac for avanserte

SSH er en fin måte å administrere en remote maskin. Ved hjelp av brukernavn og passord, eller en asynkron krypteringsnøkkel, kan man logge seg inn på en remote maskin til et tekstbasert grensesnitt. I denne posten vil jeg se på noen tildels avanserte detaljer rundt SSH til en Mac. Innholdet i denne blogposten er testet fra en Windows 10-maskin til en Macmini med OS-X El Capitan. På Windows har jeg brukt Cygwin OpenSSH klient, og putty.

SSH til Mac med OpenSSH på Cygwin

Anta Mac'en har IP 10.10.10.10

ssh brukernavn@10.10.10.10

Konfigurere SSH server gjøres i filen /etc/sshd_config

Lage nøkkelpar: ssh-keygen -t rsa. Nøklene lagres i /Users/brukernavn/.ssh/ katalogen.

keepalive

Default vil en SSH forbindelse avbrytes etter et bestemt antall minutters inaktivitet. Dette er av sikkerhets- og ressursårsaker. Man kan omgå dette ved f.eks. å kjøre top over SSH (på remote maskin) - da vil det ikke være inaktivitet.

Putty

Eller man kan gå Category-Connection og legge inn et antall sekunder i Seconds to keepalives. For eksempel 90. Da vil det hvert 90. sekund sendes informasjon fra klient til server, slik at det ikke er lang inaktivitet. Dette er keepalive på TCP nivå, ikke på session-layer nivå. Det har fungert fint for meg. Det kan også brukes til å kjøre script remote, se nedenfor.

SSH shell

Når du logger inn på en remote maskin over SSH, logger du inn i et bestemt shell.

Et shell er et program som kaller programmer. Shellet har også mange andre innebygde funsjoner - wildcard substitusjon, og et script-språk. Installerte shell er under /bin/. For å være tilgjengelige må de også være listet i filen /etc/shells

/bin/bash
/bin/csh
/bin/ksh
/bin/sh
/bin/tcsh
/bin/zsh

Sjekk hvilket shell du er logget inn med

Default shell?

echo ${SHELL}

Name of running process - current shell?

echo $0

Sjekk BASH_VERSION, ZSH_VERSION, og andre shell-spesifikk miljøvariable.

Beste måten?

ps -p$$ -ocommand=

$$ er shell prosess id

ps -p $$

Bytt shell

Skriv navnet på shellet du vil til

bash sh zsh

Bytt shell permanent

chsh -s /bin/bash. Logg ut og deretter logg inn igjen.

eller

sudo chsh admin -s /bin/bash

chsh -s /bin/bash admin

eller sh, ksh ...

Angi default shell

På Mac lokalt i GUI, åpne Terminal og gå i menyen til Terminal-Options.

Start script over SSH og log ut mens det fortsetter å kjøre

Har hatt problemer med å få til dette på Mac. Når jeg logger ut fra SSH så pauser scriptet, og begynner å kjøre igjen når jeg logger inn igjen (!). En måte å gjøre det på er å sette keepalive i putty, logge inn på Mac over SSH med putty, og starte scriptet. Da ungår man SSH logut pga inaktivitet. Men man må ha klientmaskinen (sin egen maskin..) gående helt til scriptet er ferdig. Så ikke optimal løsning.

nohup ./myscript.sh parameter1 parameter2 >out.txt 2>err.txt &

nohup sudo -b ./myscript.sh parameter1 parameter2 >out.txt 2>err.txt &

screen?

tmux?

disown?

SSH fra Synology til Mac med public-key autentisering

Vi ønkser å kjøre et backupscript på en Synology. Scriptet bruker rsync over SSH til å kopiere filer fra Synologyen til en remote Macmini. Kopieringen går over internett. Synologyen må dermed kunne logge inn på målmaskinen. Scriptet skal kjøre automatisk en gang per natt, med crontab. Da er det ikke praktisk å autentisere med brukernavn og passord. En annen måte å autentisere på er med en public nøkkel. Et private/public nøkkelpar fungerer på den måten at en melding kan krypteres med en public nøkkel, mens det er kun den private nøkkelen som kan dekryptere meldingen. Man bruker altså forskjellige nøkler for kryptering og dekryptering. Mellom de to nøklene er det en matematisk sammenheng. Hvis målmaskinen sender en kryptert melding til kildemaskinen, og kildemaskinen klarer å lese denne, vet målmaskinen at kildemaskinen er innehaver av den private nøkkelen. Dette kan brukes til å autentisere.

Det finnes private/public nøkkelpar for brukere - som benyttes for å autentisere en bruker på en målmaskin. Det finnes også et tilsvarende nøkkelpar for målmaskinen (hostkey) som brukes for å autentisere målmaskinen for brukeren - slik at en som logger inn kan være sikker på at han logger inn på riktig system.

Hvordan sette opp public nøkkel autentisering fra en Synology (kildesystem) til en Mac (målsystem):

1. Avgjøre hvilke brukerkontoer som skal benyttes - på kildemaskinen og på målmaskinen. Ofte vil man av sikkerhetshensyn unngå å bruke root. Årsaken til dette er at root har uinnskrenkede rettigheter. Hvis man bruker root og gjør noe feil kan det få store kosekvenser. Og - bruk av root øker sjansen for at kontoen kompromitteres - det vil si at en uvedkommende klarer å få tilgang til systemet med root brukeren - konsekvensen av dette kan være store. Å skulle omgå denne problematikken er ofte mulig, men resulterer gjerne i egne sikkerhetsmessige utfordringer, se referanse (2).
   • Kildemaskinen - endel omstendigheter tilsier at det er greit å kjøre et backupscript under root på Synology. Hvis en uvedkommende person endrer et script som kjører som root på crontab, kan dette få konsekvenser. Kun root skal ha tilgang til script-filene og katalogen disse ligger i. Det har tidligere vært problemer med å kjøre script som noe annet enn root på Synology, blant annet har crontab innslagene blitt slettet når DSM oppdateres. Vi behøver ikke aktivere root brukeren for å kunne kjøre crontab jobber under root. root-brukeren har default egen brukerkatalog på Synology - en katalog vi behøver når vi skal sette opp public key autentisering. Dersom vi vil kjøre scriptet med en annen bruker må vi aktivere brukerkatalog for alle brukerne på Synology - og det er ikke alltid dette passer med måten man vil at brukerne skal bruke Synologyen.
   • Målmaskinen - vi behøver ikke bruke root på Macminien. Kontoen vi logger inn på målmaskinen med må ha tilstrekkelige rettigheter. For et backupscript vil dette bety rettigheter til å kopiere filene ned på intern eller ekstern harddisk. Aller helst vil vi beholde bruker-id på filene som skal kopieres over, slik at de får riktig eier og gruppe ved en restore tilbake til Synology. Hvis ingen filer eies av root på kildesystemet bør det være enkelt å sette opp backupmaskinen slik at vi ikke behøver bruke root her.
     Detaljene rundt hvordan rettigheterne blir for filer som kopieres fra en Synology til en Macmini er kompliserte - fordi de to maskinene har forskjellige brukersystemer. Dersom man kopler en ekstern harddisk til Synologyen, kopierer over filene, og så frakter den eksterne harddisken til Macminien, blir det lett komplisert hvordan rettighetene på filene blir. Dersom jeg logger inn på Macminien over ssh viser det seg at rettighetene på filene på den eksterne harddisken varierer med hvilken bruker jeg logger inn med:

     Fig. 1 Rettigheter på filer på ekstern harddisk. Harddisken var først koplet til en Synology, filene ble kopiert over, deretter ble harddisken koplet til en Macmini. Vi er logget inn over SSH med ladmin bruker.

     

     Fig. 2 Rettigheter på filer på ekstern harddisk. Harddisken var først koplet til en Synology, filene ble kopiert over, deretter ble harddisken koplet til en Macmini. Vi er logget inn over SSH med root.

2. På kildemaskinen Synology: lage private/public nøkkelpar for en bruker:
   ssh-keygen -t rsa -b 2048
   Vi endre opp med filene id_rsa og id_rsa.pub. Begge filene kopieres ned til katalogen /root/.ssh/.
   Den private nøkkelen id_rsa skal ha rettigheter 600.
   Den offentlige nøkkelen id_rsa.pub skal ha rettigheter 644.
   Katalogen /root skal ha rettigheter 700.
   Katalogen /.ssh skal også være 700.
   Katalogene skal eies av root, og ha gruppe root.
   Nøkkelfilene behøver ikke ha eier-gruppe root-root, kan ha eksempevis admin-users, autentiseringen fungerer allikevel.
   I filen id_rsa.pub står det gjerne angitt noe om bruker og maskin nøkkelen ble laget på. Denne teksten kan editeres - påvirker ikke om autentiseringen fungerer.
   Når man lager nøklene får man spørsmål om hvor de skal lagres og hva filnavnene skal være. Default er .ssh katalogen til brukeren man er logget inn med, og navnene id_rsa og id_rsa.pub. Filene kan lagres hvor som helst når de lages, bare de kopieres ned til riktig .ssh katalog etterpå. Filnavnene må være id_rsa og id_rsa.pub - ellers vil ikke public nøkkel autentiseringen fungere. Man behøver altså ikke være logget inn med den brukeren som skal benytte nøklene når de lages, bare nøklene etterpå plasseres i riktig katalog.
3. Kopier rsa host public-nøkkel filen på målmaskinen Macmini til Synology known_hosts, for autentisering av målmaskinen. Filen /etc/ssh_host_rsa_key.pub på Macmini legges til innholdet i filen /root/.ssh/known_hosts på Synology. Denne filen autentiserer målmaskinen for kildemaskinen.
   known_hosts skal være 644.
   Vi begynte med å oppdatere known_hosts filen for hånd. Men det fungerte ikke, autentisering av målserver skjedde ikke automatisk. Først da vi lot programmet oppdatere known_hosts (ved å logge inn med ssh og svare yes til å oppdatere) fungerte det. Vet ikke hvorfor det ikke fungerte å oppdatere for hånd. Eneste forskjell i innslaget i filen er at når oppdateringen var automatisk kom også IP-adressen til målserveren med - men skulle ikke tro det var nødvendig for at autentiseringen skulle fungere.
   

   Fig. 3 Dersom ikke offentlig nøkkel fra målserver ligger i known_hosts filen på kildeserveren får man advarsel om at man ikke er garantert identiteten til maskinen man forsøker å logge seg på. Man får her muligheten til å automatisk oppdatere known_hosts filen.

   Dersom vi manuelt legger innholdet i ssh_host_rsa_key.pub til known_hosts ser filen slik ut:
   ssh-rsa AABBCCDDEEFFaabb...xxyyzz
   Det står altså først ssh-rsa, deretter public key. Dersom dette gjøres automatisk av ssh-programmet ved at vi svarer "yes" på spørsmålet om vi vil kople til serveren, ser known_hosts slik ut:
   123.456.789.123 ssh-rsa AABBCCDDEEFFaabb...xxyyzz
   Filen har altså et litt annet format - nå legges også ip-adressen til målmaskinen inn. Uklart hvorfor dette er nødvendig. Men uten riktig ip-adresse her fungerer ikke autentiseringen.
4. Kopiere id_rsa.pub på kildemaskinen til målmaskinen, for brukerautentisering. På kildemaskinen Synology kopierer vi innholdet i /root/.ssh/id_rsa.pub, og legger det til i Macmini-filen /Users/<brukernavn>/.ssh/authorized_keys (eventuelt til /var/root/.ssh/authorized_keys, hvis vi logger inn som root).
   authorized_keys skal være 644. Owner og group?
   katalogen .ssh?
   katalogen <brukernavn>?
   
5. Test at det fungerer. Fra Synology:
   sudo ssh adminuser@ip-til-macmini
   Husk at ssh må kjøre under root-brukeren på Synology, så vi må bruke sudo.
6. Rydd opp eventuelle nøkkelfiler som ikke ligger i riktige kataloger. Vær spesielt nøye med å ikke la id_rsa (private key filen) komme på avveie. Denne filen skal aldri distribueres.
   

We want to run a script on a Synology. The script uses rsync to copy files from the Synology to a remote machine. So the script needs to be able to log into the remote machine. logs into a, where the Synology . The script backs up much of the files on the Synology to a Macmini external USB harddrive. The Synology is in the office, the Macmini is at the home of one of the employees From a Synology we want to log into a Mac without password. So we will set upp public key authentication. Synology -------> Mac. We want the Synology root user to be able to log into the Mac root user account. One reason we use the Synology root user is because only this user has a user folder by default, /root. So then we do not need to activate user folder for all the other users. Another reason is that we will use the connection in a crontab script, and cron scripts on Synology are most reliably run as root.


1) On Synolgy, create private and public key pair. We do not need to be logged into the machine as the root user account (the root accoutn is not even activated). Actually, we are logged in as admin, and are in a test-directory we have created ourselves. ssh-keygen -t rsa -b 2048. We did save the keys as id-rsa and id-rsa.pub in the test directory. Later we found out that id-rsa need to be called id_rsa (the default name).

2) We move the private key to /root/.ssh/ directory. We copy the public key to /root/.ssh/ directory. The private key should be 600. The public key should be 644. In the public key the line ends with admin@pssyno01. This is ok, does not need to be changed to root@pssyno01. The two key files have owner admin and group users. So this also did not need to be changed to root root. The .ssh directory is 700. The \root directory is also 700.

3) We copy the host public key from the Mac into a file /root/.ssh/known_hosts. This file should be 644. On the Mac, the file is /etc/ssh_host_rsa_key. This file makes us certain that we connect to the correct server. We still do not authenticate the server. We learn: we let the machine update the known_hosts file - by running: sudo ssh@targetserver. Now the system will ask if we would like to update known_hosts file. Say yes. And for the future the serve authentication is going automatic. Do now know why this file could not be updated by hand. when I update the file: ssh-rsa 3434343publickey... when the system did: server-ip ssh-rsa 3434343publckey... So maybe the ip needs to be in there? -->so now server authentication is automatic. Now we need automatic user authentication as well.

4) On the Mac we make (or update) the file authorized_keys with the public key of the Synology. This file is /var/root/.ssh/authorized_keys. It should be 644. At the end of the public key, there was admin@pssyno01. We do not need to change this to root@pssyno01. The file has owner root and group wheel.

5)Clean up key files that are in wrong places on both machines. Should definitely not be lying around.

6) id-rsa need to be called id_rsa (the default name). but do not need to edit admin@pssyno01 in the file to root@pssyno01.

7)We learn: you do not need to activate the Synology root user in order to run scripts under root. And public-key authentication can be set up without activating the account.

SSH fra PC til Synology med public-key autentisering

Her er altså autentiseringen i motsatt regning - SSH serveren og ikke klienten kjører nå på Synology. På en Windows maskin bruker vi Putty SSH-klient og ønsker å logge inn på Synology over SSH med public-key autentisering.

1) På PC, lag Putty private-key, public-key nøkkelpar. Med programmet puttygen.exe. Jeg brukte RSA 2048 bits. Lagre i to filer. Private key filen har etternavn .pkk. Public key filen har etternavn .txt. Lagre også public key ved å markere all teksten i vinduet i puttygen, copy, paste inn i notepad - nå kommer alt på en linje - lagre dette og bruk denne filen videre som public key.
2) Public key filen må altså være på et en-linjers format:
ssh-rsa AAASDFDS....SDFSFDF rsa-key-20181101
NB: det fungerte ikke dersom filen ikke var i en linje.
3) Vi ønsker å logge inn på Synology med root-brukeren fordi denne har default en brukerkatalog /root, slik at vi slipper å aktivere brukerkatalog for de andre brukeren. Vi lager katalogen /root/.ssh/ /root er root:root og 700. /root/.ssh er også root:root og 700. I /root/.ssh/ katalogen kopierer vi inn public-key filen fra PC'en. Vi gir filen nytt navn, authorized_keys. Den er root:root og 644 (det fungerte ikke dersom den var admin:users).
4) Det er ikke nødvendig å editere /etc/ssh/sshd_config filen på Synology. Behøver ikke kommentere ut #PermitRootLogin.
5) På PC må filen known_hosts inneholde keyprint fra Synology. Enkleste måten å gjøre dette på er å kople til Synology med SSH i Putty og svare Yes når man får spørsmål om man vil lagre keyprint i known_hosts filen. Med putty på en PC eksisterer egentlig ikke known_hosts filen (ikke noe poeng i å lete etter den), men er implementert som innslag i registry, under HKEY_CURRENT_USER - Software - SimonTatham - PuTTY - SshHostKeys.
6) NB: måtte restarte Synology. For å bruke Synology som root logger vi inn med admin-brukeren og gjør sudo -i. Restart Synology med reboot.
7) Kople til Synology fra Putty commandline på PC: putty -i private-key-file.pkk root@synoip.
Eller: pscp -i private-key-file.pkk testfil.txt root@synoip:/root/
Eller: pscp -i private-key-file.pkk testfil1.txt testfil2.txt root@synoip:/volume1/minefiler/
Eller: pscp -i private-key-file.pkk -r /path/to/testdirectory root@synoip:/volume1/minefiler/

SSH fra PC til Mac med public-key autentisering

Vi bruker putty på en PC og skal SSH til en Mac som kjører en SSH server. Dette er veldig likt som å SSH til en Synology, se ovenfor.

Referanser

1. How to test what shell I am using in a terminal
   https://unix.stackexchange.com/questions/9501/how-to-test-what-shell-i-am-using-in-a-terminal
2. rsync all files of remote machine over SSH without root user?
   https://unix.stackexchange.com/questions/92123/rsync-all-files-of-remote-machine-over-ssh-without-root-user
3. Putty manual, Chapter 8: Using public keys for SSH authentication
   https://the.earth.li/~sgtatham/putty/0.63/htmldoc/Chapter8.html#pubkey
4. Putty manual, Chapter 3: Command line usage
   https://the.earth.li/~sgtatham/putty/0.63/htmldoc/Chapter3.html#using-cmdline-identity
5. Where does Putty store known_hosts information on Windows?
   https://superuser.com/questions/197489/where-does-putty-store-known-hosts-information-on-windows