SSH-Tutorial für Anfänger

moonlook

moonlook

Meteorist
Also, hier mal ein Versuch eines kleinen Tut's zu SSH für Anfänger.
Ich denke, dass es keinen Anspruch auf Vollständigkeit haben wird,
dazu ist die Anwendungsvielfalt einfach zu gross
und mein Wissen sicherlich auch noch nicht ausreichend
(ich hoffe, hier nicht nur Halbwissen anzubieten).
Ich bin jedem dankbar für Kritik, weiterführende und ergänzende Beiträge.

Ich gehe hier auf OpenSSH ein, da es sich auf BSD-Systemen durchgesetzt hat.
Derzeit bei mir in der Version OpenSSH_3.5p1 installiert (ssh -V), ist es durchaus
abwärtskompatibel.

Grundsätzlich braucht man den SSH-Daemon sshd, sowie
ssh als Ersatz für frühere rlogin und telnet,
scp als Ersatz für ftp und rcp.
Diese Sachen werden beim Installieren des Paketes schon automatisch mit
installiert, genauso wie ssh-add, ssh-agent, und ssh-keygen
Bei der FreeBSD 5 schon bei ner Minimalbasisinstallation, was durchaus
Sinn macht, da sich alles weitere nach Einrichtung der
Netzanbindung damit installieren und konfigurieren lässt.

Sachen wie Root-Login lässt man erstmal genauso sein wie bei ftp o.ä.;), also erstma los in die
Konfigurationsdatei des Daemons auf MaschineA, bei der auf MaschineB sollte es ähnlich aussehen.
Zu finden unter /etc/ssh/sshd_config. Zur Erläuterung der einzelnen Optionen sei auf man 'sshd_config' verwiesen.

---------------------------------------------------------

#der standardport für ssh
Port 22
#beide Protokollversionen werden unterstützt, der eingetragenen Reihenfolge nach wird probiert
Protocol 2,1
#bei verschiedenen NIC`s oder IP's werden diese hier zugewiesen
#ListenAddress 0.0.0.0
#ListenAddress ::

HostKey /etc/ssh/ssh_host_key
HostKey /etc/ssh/ssh_host_dsa_key

#nur für Protokoll1
KeyRegenerationInterval 3600
#nur für Protokoll1
ServerKeyBits 768

SyslogFacility AUTH
LogLevel INFO

#wenn während der ang. Zeit keine erfolgreichen Login's stattfinden, diskonnektet der Server
LoginGraceTime 20
#is ja klar;)
PermitRootLogin no
#lässt ein paar weniger dau's zu
StrictModes yes

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys

RhostsAuthentication no
IgnoreRhosts yes
HostbasedAuthentication no

PasswordAuthentication yes
PermitEmptyPasswords no
#vorerst mal ohne
X11Forwarding no
MaxStartups 1
VerifyReverseMapping no

Subsystem sftp /usr/libexec/sftp-server
---------------------------------------------------------


Nachdem dies konfiguriert ist (sshd_config(5) hilft ein wenig), muss der sshd gestartet werden.
Es gibt zwei Möglichkeiten dafür:
a) Ein Eintrag in der /etc/rc.conf in der Art: sshd_enable="YES" und reboot.
b) Den sshd, wenn er schon läuft, killen und wieder starten
(wenn man die Konfiguration in o.b. Pfad schreibt, sucht er sich diese automatisch):
killall -9 sshd && sshd

Jetzt ein kleiner Test:
$ ps aux | grep sshd
root 685 0,0 0,3 2632 1628 ?? Is 7:54pm 0:00,07 sshd

Der Server steht, beide Maschinen sind übers Netz erreichbar, ein erster Verbindungs-
versuch kann losgehen, elegantere Methoden später:


$ssh user@MaschineB
The authenticity of host 'MaschineB' can't be established.
DSA key fingerprint is d6:eb:b5:10:21:9e:72:45:64:ac:0b:11:15:e4:bb:fe.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'MaschineB' (DSA) to the list of known hosts.
Password:*******

Man sollte jetzt die Ausgabe von /etc/motd der MaschineB auf MaschineA sehen und kann anfangen zu arbeiten;)
Aber das nicht alles ist, scheint klar zu sein.
Wie bekomme ich jetzt schnell eine Datei auf MaschineB?

scp /Pfad/zur/Datei User@MaschineB:/dortiger/Pfad/
Passwort des Users auf MaschineB:*******
Datei 100% |*******************************************|
Umgekehrt, Datei von MaschineB auf MaschineA holen:

scp User@MaschineB:/Pfad/zur/Datei/dort /Pfad/zur/Datei/hier
Passwort des Users auf MaschineB:*******
Datei 100% |*******************************************|
---------------------------------------------------------


Jetzt werden einige sagen: Das geht auch anders. Schon beschrieben hier:
http://www.bsdforen.de/forums/showthread.php?s=&threadid=268
Und zwar mit einigen anderen mitgelieferten Tools(o.g.)
Man generiert mit 'ssh-keygen -t rsa' als der User eigene Schlüssel für SSH, die
die dann unter ~/.ssh/id_rsa bzw. ~/ssh/id_rsa.pub zu finden sind:

$ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/User/.ssh/id_rsa): hier kein Passwort!
Enter passphrase (empty for no passphrase): eindeutige Passphrase
Enter same passphrase again: nochmal
Your identification has been saved in /home/User/.ssh/id_rsa.
Your public key has been saved in /home/User/.ssh/id_rsa.pub.
The key fingerprint is:
13:82:79:24:77:12:ff:21:67:f6:5b:46:84:73:34:c2 User@MaschineA

Dasselbe gilt für MaschineB.
Wichtig noch: Rechte 600 vergeben für diese Dateien.
Wer beim scp o.ä. gar kein Passwort eingeben will, lässt die
Passphrase leer und damit seine Maschine
unsicherer. Es werden noch Möglichkeiten genannt. Diese
Passphraseabfragen zu unterbinden.
Dann den Schlüssel von MaschineA nach MaschineB kopieren und dort in die
~/.ssh/authorized_keys bzw. anhängen.

ssh User@MaschineB 'cat >>.ssh/authorized_keys' <~/.ssh/id_rsa.pub
Natürlich auf beiden Maschinen.

---------------------------------------------------------
Ab diesem Zeitpunkt ist ssh eingerichtet, man gibt des öfteren eine Passphrase ein. Der ssh-agent dient dazu, die Schlüssel und Passphrases eleganter zu verwalten.
Allerdings er kann bei Verwendung durch User mit Superuser-Rechten missbraucht werden, um RSA auszutricksen. also bei unsicheren Umgebungen auf den ssh-agent lieber verzichten und bei jedem Verbindungsaufbau die Passphrase eingeben.
Der ssh-agent wird in der Art benutzt, das er anderen Anwendungen vorangestellt wird, also erst der agent und dann eine Konsole oder X gestartet wird, was in 2 verschiedenen Arten realisiert werden kann:
A) Der ssh-agent erhält als Parameter ein Kommando übergeben.
Kindprozesse dieses Kommandos erben eine Verbindung zum ssh-agent.
'ssh-agent $SHELL' öffnet eine Shell, die dann zum Aufbauen verschiedener
Verbindungen zu anderen Maschinen genutzt werden kann.
Es ist jetzt nötig, dem ssh-agent mitzuteilen welche Schlüssel er verwaltet.
Dies geschieht mit dem Kommando:

$ssh-add ~/.ssh/id_rsa
Enter passphrase for /home/User/.ssh/id_rsa:
Identity added: /home/User/.ssh/id_rsa (/home/User/.ssh/id_rsa)

ssh-add -l listet alle verwalteten Schlüssel
ssh-add -d löscht einen verwalteten Schlüssel
ssh-add -D löscht alle verwalteten Schlüssel

Nun wird beim scp o.ä. kein Passwort mehr verlangt bzw. nur einmalig;)
Das alles ist natürlich hinfällig, wenn die Session oder der agent selbst geschlossen wird.

B) Eintrag des ssh-agents in ~/.xinitrc für X und ssh-add in (Shellabhängig) ~/.cshrc.
Als Beispiel der KDE und die csh als Shell.

~/.xinitrc sieht bei mir so aus:
------------------------------------------
#!/bin/sh
SSH_AGENT=/usr/bin/ssh-agent
WINDOWMANAGER=/usr/local/bin/startkde
exec $SSH_AGENT /bin/sh -c "$WINDOWMANAGER"
------------------------------------------

~/.cshrc habe ich um folgendes ergänzt:
------------------------------------------
sh-add ()
{
/usr/bin/ssh-add -l;
/usr/bin/ssh-add ~/.ssh/id_rsa
}
-----------------------------------------
Das Ganze funzt dann in der Art, das zuerst der ssh-agent, dann der KDE als Kindprozess gestartet wird.
Der Eintrag in der ~/.cshrc bewirkt, dass ich einmal nach meiner Passphrase gefragt werde und dann nicht.
Ich habe mich für diesen Weg entschieden, da mir zum einen kein anderer bisher eingefallen ist und dieser
sich meiner Arbeitsweise (X starten->ssh-Verbindung per Konsole starten) anpasst.
Vorraussetzung für Alles ist natürlich, dass sich die authorized_keys auf den entfernten Maschinen befindet
und der Rechner, auf dem ssh-agent läuft dort drin steht.
Das war erstmal der erste Streich. Ein weiterer Teil kommt in ein paar Tagen mit X-Forwarding und sftp.
Ich bitte um Kritik, wenn ich etwas vergessen oder falsch dargestellt habe.
Genauso bitte andere Ideen dazu bitte posten, was man mit ssh alls machen kann(Tunneling etc.).
Alles obige wurde bei mir getestet mit FreeBSD 5, KDE3.1.1 und der csh als Shell.
 
Ich wollte nur darauf hinweisen, dass zB bei NetBSD
der Eintrag in der rc.con sshd=YES lauten muss.
Sonst finde ich das Tutorial gut. :)
 
Sehr gutes Tutorial Moonlook, bin schon gespannt auf den zweiten Teil :)

Drei kleine Anmerkungen hätte ich:
1. `killall -9 sshd` ist ganz schön hart, reicht kein `killall -HUP sshd` ?

2. der eine Pfad stimmt nicht, da fehlt der "."
~/.ssh/id_rsa.pub

3. Es ist ziemlich nützlich zu wissen, dass z.B.
scp User@MaschineB:/dortiger/Pfad/* /wohin/damit/
so nicht funktioniert, sondern das der "*" escaped werden muss.
scp User@MaschineB:/dortiger/Pfad/\* /wohin/damit/
Dies gilt natürlich auch für alle anderen Zeichen die von der Shell interpretiert werden.

Ansonsten gute Sache das ;)

gruss
Male
 
Die ganze ssh-agent/ssh-add Fummelei ist nicht noetig. Man kann sich von XDM mittels PAM gleich gegen seinen Priv. Key authentifizieren. Man logged sich also mit seiner Passphrase ein und die Session wird gleich innerhalb eines ssh-agent gestartet. Finde ich sehr praktisch, wie's funktioniert steht in pam_ssh(8)

Nachtrag:
Das ganze sollte natuerlich auch mit login(1) gehen.
 
Original geschrieben von Maledictus

3. Es ist ziemlich nützlich zu wissen, dass z.B.
scp User@MaschineB:/dortiger/Pfad/* /wohin/damit/
so nicht funktioniert, sondern das der "*" escaped werden muss.
scp User@MaschineB:/dortiger/Pfad/\* /wohin/damit/
Dies gilt natürlich auch für alle anderen Zeichen die von der Shell interpretiert werden.

in der

Zum Vergrößern anklicken....

das *-zeichen muss nicht escaped werden, wenn man es escaped wird es eben als stern interpretiert und nicht als wildcard das dann alle files im directory kopiert (dann würde scp eine datei namens * suchen und kopieren wollen); durch ein slash vor einem sonderzeichen wird dessen bedeutung aufgehoben und als zeichen interpretiert, ist bei perl ja das gleiche...
ansonsten wirklich gutes how-to moonlook
 
Hmm, mich wundert nur, dass einige hier erst nach nem 3/4 Jahr drauf kommen.
Da damals so wenige, also nur Tek reagiert haben, dachte ich, dass ein weiteres Howto dazu nicht gebraucht wird.
Na gut, ich ueberleg's mir nochmal.
Danke an MrFixit, das ist natuerlich auch ne praktikable Loesung.
 
morpheus: Du irrst. scp foo:* . geht so nicht, da die Shell versuchen wird '*' zu expandieren. Da aber der '*' auf dem entfernten Host gemeint ist, kann nichts brauchbares bei rauskommen. Ergo muss das
Code: 
scp foo:\* .
heissen. scp forkt ja auf der Gegenueberliegenden Seite eine Shell, und _diese_ bekommt dann den Stern, welcher expandiert wird.

Wenn man in die andere Richtung kopiert ist das korrekt:
scp * foo:

Will man gar die Datei '*' selbst kopieren, dann braucht man sowas:
scp foo:\\\* .
oder
scp \* foo:
je nach dem, welche Shell was expandieren soll und was nicht.
 
Original geschrieben von MrFixit
morpheus: Du irrst. scp foo:* . geht so nicht, da die Shell versuchen wird '*' zu expandieren. Da aber der '*' auf dem entfernten Host gemeint ist, kann nichts brauchbares bei rauskommen. Ergo muss das
Code: 
scp foo:\* .
heissen. scp forkt ja auf der Gegenueberliegenden Seite eine Shell, und _diese_ bekommt dann den Stern, welcher expandiert wird.

Wenn man in die andere Richtung kopiert ist das korrekt:
scp * foo:

Will man gar die Datei '*' selbst kopieren, dann braucht man sowas:
scp foo:\\\* .
oder
scp \* foo:
je nach dem, welche Shell was expandieren soll und was nicht.
Zum Vergrößern anklicken....

ihr habt natürlich recht... habe mir die syntax von maledictus nicht richtig angeschaut das der kopiervorgang "in die andere richtung" gemeint war... :gpaul:
 
Hi,

also mit dem pam_ssh ist schon praktisch, wenn es klappt.
@Mr. Fixit
vieleicht kannst Du mal deine Einstellungen posten.

habe in meiner /etc/pam.d/gdm eine Zeile reingebastelt:

auth required pam_ssh.so try_first_pass want_agent


Das klappt auch. Er fragt bei der Anmeldung nach dem ssh passphrase.
Nur muss ich fuer jedes neue Gnome Terminal den ssh passphrase neueintippen.

Muss man das pam modul noch nachinstallieren oder ist das standard?

CAT
 
Gute Howto.

Hab nur ein kleines Problem, möchte einen Login ohne PublicKey verhindern. Allerdings wenn ich "PasswordAuthentication no" setzte, passiert folgendes.
Wenn ich mich jetzt ohne pub-key oder mit nicht gültigem verbinde, dann gibt mir der ssh folgendes aus:
Code: 
Using keyboard-interactive authentication.
Und dann werde ich nach meinem Passwort gefragt. Nicht nach dem Passphrase.

Nun meine Frage, wo liegt mein Fehler?

Gruß ShitHappens
 
@cat1510

In FBSD 5.x ist das pam_ssh Modul standardmäßig drinne.

@ShitHappens

Ist denn RSA-Authentifizierung in der sshd_config aktiv?

Gruß,

Ice
 
cat1510 schrieb:
habe in meiner /etc/pam.d/gdm eine Zeile reingebastelt:

auth required pam_ssh.so try_first_pass want_agent
Zum Vergrößern anklicken....
Es muessen zwei Zeilen sein, einfach die beiden auskommentierten in /etc/pam.d/xdm ansehen.

Funktioniert auch fuer z.B. login(1)
 
Ich paste jetzt einfach mal meine sshd_config

Code: 
Port 22
ListenAdd ress 192.168.1.3

HostKey /etc/ssh/ssh_host_key
HostKey /etc/ssh/ssh_host_dsa_key

KeyRegenerationInterval 3600
ServerKeyBits 768

SyslogFacility AUTH
LogLevel INFO

LoginGraceTime 20
PermitRootLogin no
StrictModes yes

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizdeKeysFile .ssh/authorized_keys

PasswordAuthentication no
PermitEmptyPasswords no

Asugabe von ssh -V:

Code: 
OpenSSH_3.8.1p1 FreeBSD-20040419, OpenSSL 0.9.7d 17 Mar 2004

Gruß ShitHappens

PS: Die Authentifizierung mit Key funktioniert Problemlos, nur möchte ich nicht das sich jemand ohne Key anmelden kann.
 
Hi,

habe noch eine Frage fuer SSH Konfiguration Level 2.

Mein Computer ist ein Internet Gateway mit 2 Interfaces.
DSL & LAN

Auf meinem externen Interface moechte ich, dass da ein sshd laeuft, der nur gegen Schluessel die User auf den Rechner laesst. Am internen Interface lauscht ein anderer sshd, der die "lokalen" User annimmt.

Die Schwierigkeit ist dabei, wie bekomme ich den sshd dazu am externen port zu lauschen?
Denn die IP aendert sich ja immer wieder... In der sshd_config kann man kein Interface angeben, sondern nur IP's. Per NAT das auf das Loopback forwarden finde ich ist keine saubere Loesung...

Hat jemand eine Idee?


CAT
 
cat1510 schrieb:
[...]Auf meinem externen Interface moechte ich, dass da ein sshd laeuft, der nur gegen Schluessel die User auf den Rechner laesst. Am internen Interface lauscht ein anderer sshd, der die "lokalen" User annimmt.

Die Schwierigkeit ist dabei, wie bekomme ich den sshd dazu am externen port zu lauschen?[...]
Zum Vergrößern anklicken....
Zwei Möglichkeiten:
  • NAT hast Du schon erwähnt
  • Im ppp-up-script jeweils den sshd stoppen und neu konfiguriert starten
 
quick 'n' dirty

Bei mir hat ein kurzer Test ergeben, dass:

Code: 
#sshd_config
ListenAddress tek
und
Code: 
#/etc/hosts
192.168.2.2 tek

den gewünschten Effekt bewirken, da danach ein ssh localhost fehlschlägt. So könnte man sicher einen DynDNS einrichten und in die sshd_config (5) eintragen. Da ich nach kurzer Suche keine Möglichkeit gefunden habe, den sshd echt an ein Interface via Konfigurationsdatei zu binden, sehe ich auch sonst keine anderen Möglichkeiten als die von chaesy bereits Erwähnten.
 
Wie wäre es, wenn Du für den sshd, der die externen Anfragen annehmen soll auf einen anderen port legst und an KEIN interface bindest?
Dann sollte der auf allen interfaces lauschen und folglich unabhängig von Deiner DYN-IP sein. Dass er dann auch auf dem internen Interface lauscht sollte ja eigentlich kein Problem sein, oder?
Wenn doch, dann kannst Du das ja per PF einschränken.

Gruß,

Ice
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben