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 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.