Introdução

Acesso remoto é algo que faz parte da rotina de administradores de rede, e em ambientes Unix e Linux, o SSH é o protocolo mais utlizado para esta tarefa. Neste tutorial, irei mostrar como configurar host alias no SSH.

Pré-requisitos

OpenSSH → É uma coleção de programas de computador quem provem a criptografia em sessões de comunicações em uma rede de computadores usando o protocolo SSH.

Mão à obra

Há duas maneiras de criar os aliases:

1. Alias para todos usuários do sistema

Efetuar estas configurações logado como root.
# vim /etc/ssh/ssh_config

Adicionar as linhas abaixo no final do arquivo
Host tico
HostName 192.168.0.1
User root
Port 8082

Host → É o alias (apelido) para a máquina remota
HostName → Pode ser utilizado o hostname ou IP da máquina remota
User → Usuário que será utlizado para efetuar o acesso remoto
Port → É especificado quando o ssh não está sendo executado na porta padrão (22), caso contrário, esta linha torna-se desnecessária.

Obs.: Para usuários Mac, o arquivo de configuração está localizado em /etc/ssh_config.

2. Alias válido apenas para usuário

Efetuar estas configurações com usuário diferente do usuário root, neste exemplo utilizarei o usuário smith.
Caso o diretório .ssh não exista, basta cria-lo com comando abaixo
$ mkdir ~/.ssh

Conceder a permissão necessária
$ chmod 700 ~/.ssh

Criar aliases
$ vim ~/.ssh/config

Conteúdo do arquivo config:
Host teco
HostName 192.168.0.2
User smith

O arquivo config deve ter permissão 600, ou seja, deve estar acessível apenas para o usuário dono do arquivo.

Prova dos nove

Neste ponto do tutorial existem dois aliases criados, um para todos usuários do sistema e outro apenas para o usuário smith.

Testar acesso remoto

As duas tentivas de acesso a máquina remota tico, devem funcionar, pois o alias foi criado para todos usuários do sistema.
Executar o comando abaixo logado com usuário root.
# ssh tico
Executar o comando abaixo logado com usuário utilizado para criar alias de usuário (smith)
$ ssh tico

Apenas a segunda tentiva de acesso a máquina remota teco, deve funcionar, pois o alias foi criado apenas para o usuário smith.
Executar o comando abaixo logado com usuário root
# ssh teco
Executar o comando abaixo logado com usuário utilizado para criar alias de usuário (smith)
$ ssh teco

Testar cópia de arquivos remoto

# scp /etc/ssh/ssh_config tico:/home
$ scp ~/.ssh/config teco:/home

Conclusão

Alisases no ssh ajudam a manter de forma organizada, uma lista dos computadores remotos que são mais acessados diariamente.

:wq
Andrey Smith

There has been news today of yet another iPhone worm that affects users who have unsecured SSH installed on their device.

Security Company, F-Secure, has unearthed this latest worm for the iPhone which targets people in the Netherlands, as it did before with the first exploit of unsecured SSH. It targets users who use their iPhone to online bank with ING. Much like a phishing attack, it redirects the bank’s users to a look-a-like website with a log-in screen.

The worm only affects jailbroken devices as before, and only devices with SSH that has the default password are affected. This latest worm is more serious than the ones prior, as they were created to warn people, that things such as this could happen. The security company, F-Secure, have also said that it can behave like a botnet and send itself to other un-secure devices on a local WiFi network.

The phone can be controlled by the hacker remotely without the knowledge or permission of the user. Hackers can ring people, text people, copy your contacts or what ever they wish with your device if it’s left open. At the moment it’s only spreading around the Netherlands, but soon enough malicious hackers will most likely take advantage of the users who don’t change the default password.

A spokesperson for ING Bank said that a warning was going to be put on the bank’s official website.

“We are also briefing call centre personnel,” she added. “It’s important to remember that the worm only affects jail-broken phones and it is only aimed at customers in the Netherlands.”

If your device is jailbroken and you believe SSH maybe, or is installed then please read this guide to secure your device. Many other guides will not fully protect you as they only change the mobile user password and not the root.

If you wish to read more from F-Secure on this issue click here.

Related:

How To: Change Your iPhone’s SSH Password
Dutch Hacker Hack’s Into Jailbroken iPhone’s
iPhone Worm Rickrolls Jailbroken Devices

Bir bilgisayara uzaktan ulasmak aslinda cok kolay. Yani evdeki bilgisayariniza isten, istekine tatilden, vs. Benim de bu sistemi kullanmaktaki amacim yazilarimin farkli bilgisayarlarda olusan gereksiz kopyalarini yok etmek ve mesela hangi yazinin nerdeki hali daha güncel probleminden kurtulmak. Bir nevi GoogleDocs’un bircok kisi arasinda gidip gelen dökümanlara getirdigi kolayligi ben kendime getiriyorum.

Öncelikle kisa tanimlarla baslayalim. Kullanacagimiz programin adi OpenSSH.

I. Peki, OpenSSH nedir?

SSH ya da Secure Shell ag (yerel veya internet) üzerinden birbirine bagli iki bilgisayar arasindaki veri alisverisi icin gerekli baglantiyi saglar.  Telnet veya Rlogin gibi ayni islevi gören programlardan daha güvenli sayilmasinin da nedeni, makineler arasinda degis tokus edilmis bilgileri sifrelenmis olarak saklamasidir.

OpenSSH‘de SSH’nin acik kaynak implementasyonudur ve OpenBSD’nin gelistiricileri tarafindan olusturulmustur. Her ne kadar daha sonra depodan yüklerden terminale “ssh” de yazacak olsak yüklenecek program aslinda OpenSSH.

II. OpenSSH Kurulumu ve Kullanimi

$ sudo aptitude install ssh

bu kadar. “ssh” üst paketi (meta package) client ve server icin gerekli her seyi bilgisayara yükledi. Bundan sonrasi onun nasil kullanilacagini bilinmesine kaliyor. Unutulmamasi gereken sey diger bilgisayarda da bu paketin yüklü olmasi gerekliligi.

$ ssh uzak_pc’deki_kullanici_adi@sunucu_ismi (örn. $ ssh debiantr@debian-sid)

Teoride bu böyle ama ben kullanici ismi yerine ip numarasi kullaniyorum, yani

$ ssh kullanici_adi@192.168.2.101 gibi.

Yalniz burdaki sorun 192.168.2.101 gibi ip’lerin yerel aglarda bulunmasi ve yerel aglarda genellikle ip’lerin degismemesi. Eger yerel agda degilseniz ve uzaktaki bilgisayara internet üzerinden erismek istiyorsaniz o zaman bilgisayarin statik bir ip’ye ihtiyaci var. Bu da genelde görülen bir sey degil. Bilgisayarlarin ip adresleri bir sekilde hep degisiyor. Modem yeniden baslatiliyor, sorunlar cikiyor, vs. Bu yüzden DNS kullanmak mantikli yani basitce bir web adresi almak mantikli olan. DynDns.com ip’lere bedava isim atayabileceginiz bir hizmet. DynDNS.com’da bir hesap olusturduktan sonra “Free Dynamic DNS” bölümünden kendinize istediginiz ismi alin: debiantr.homelinux.com, besiktas1903.dyndns.biz gibi. Ismi aldiktan sonra da simdiki ip adresinizi atayin, zaten otomatik olarak gösterecek adresinizi size. Sonra terminale dönüp:

$ sudo aptitude install ddclient

Bu uygulama degisen ip’nizi “web adresi”nizle güncel tutacak. Kurulum sirasinda karsiniza bir sihirbaz cikacak burda ilk soruda
www.dyndns.com deyin, sonra hesabinizin kullanici adi ve sifresini girin,
ip adresinizi bulmasi icin kullanilacak servise “yes”,
web sitenizin ismini listeden bulmasina “yes”,
PPP connect?’e “yes”,
“ddclient as deamon”a “yes” deyin, bu sayede her bilgisayar acildiginda bu uygulama da baslayacak
programin ne kadar zaman adresi kontrol etmesini istediginizi girin, ve son olarak listedeki adresi “space” (bosluk) tusu ile secin.

Arkasindan /etc/ddclient.conf dosyasini acin

$ sudo gedit /etc/ddclient.conf

use=if, if=debiantr.homelinux.com

satirini silip o satira sadece

use=web

(burdaki amac ddclient’in network kartinin yerel adresini kullanmasi yerine internet üzerinde yayimlanan adresinizi kullanmasini saglamak.)

yazin, kayedip cikin. Sonra $sudo ddclient dediginizde sorunsuz olarak adresiniz güncellenmis olmasi lazim.
Son yapilmasi gereken seyde ulasilmak istenen bilgisayarin router’inin 22 numarali TCP ve UDP portlarini acmak. Cünkü ssh’nin varsayilan kullandigi port 22. “Port forwarding” yapmayi bilmiyorsaniz Portforward.com‘a bir bakin.

“ddclient” disinda baska alternatifler de var. Bunlardan bir tanesi yine bir ip güncelleme programi ve debian depolarinda olan “inadyn”. Ancak bunun kullanimina burada deginmeyecegim. Baska bir alternatif ise, benim kullandigim, direkt router’in dns adresi kullanmasini saglamak. Her router bu servisi desteklemiyor, ancak destekleyen routerlarda sadece DynDns hesabinizin ismini, sifresini ve kullanmak istediginiz web adresini girip router’in ip’nizi güncellemesini saglayabilirsiniz.

Artik uzaktaki bir bilgisayara ya da sunucuya ulasmak icin yapmaniz gereken tek sey

$ ssh kullanici_adi@aldiginiz_adres.dyndns.com

ssh ayni zamanda opsiyonlar da aliyor bunlardan bir tanesi -X, eger uzaktaki alete

$ ssh -X kullanici_adi@aldiginiz_adres.dyndns.com

diye baglanirsaniz ve baglandiktan sonra terminalde $ iceweasel www.google.com yazarsaniz iceweasel uzaktaki bilgisayarda calisip Google’a baglanmis olacak ama siz onu kendi ekraninizda göreceksiniz. Ofis programlarini böyle calistirarak, islemi uzaktaki bilgisayarda yapmis olacak ama programin resmini ve yaptiklarinizi o an kullandiginiz bilgisayarda görmüs olacaksiniz.

III. SSH’de Dosya Kopyalama

$ scp kullanici@pc.dyndns.com:/dosyanin/yeri/dosya uzaktaki@pc.dyndns.com:/kopyalanan/yer/dosya

eger kopyalanacak sey klasörse “scp -r” yazin sonra ayni sekilde devam edin. “-r” takisi recursive anlamina gelmekte ve klasörün icindeki her dosya kopyalanana kadar islemin devam etmesini saglamaktadir.

IV. SSH’de Sifreyi Kaldirmak

Uzaktaki bilgisayariniza veya sunucuya baglandiginiz bilgisayar gercekten güvenliyse (örn. sizden baskasi kullanmiyorsa) iki de bir sifre yazimini ortadan kaldirabilirsiniz.  Yani iki bilgisayari birbilerine güvenebilir hale getirebilirisiniz. “ssh-keygen” burda kullanacagimiz program. Öncelikle

$ ssh-keygen -t rsa (veya dsa) -t sifreleme (encryption) tipini belirten bir etiket ve rsa ile dsa sifreleme tiplerinden bazilari. Cikan ilk soru dosya ismi ona direkt bir sey yazmadan (ya da yazin siz bilirsiniz) enter’a basin sonra da gercekten güvenli oldugunu düsündügünüz bir sifre verin. Sonra yapilmasi gereken sey yaratilmis dosyanin uzaktaki bilgisayara/sunucuya kopyalanmasi. Varsayilan ayarlara göre:

$ cd /home/kullanici_adi/.ssh

$ su

# scp id_rsa/dsa.pub uzaktaki_bilgisayar:~/.ssh/authorized_keys, yalniz dikkat edilmesi gereken nokta önceden olusturulmus bir “authorized_keys” dosyasinin olmamasi, eger varsa bu sekilde önceden verilmis bilgiler silinir. Öyle bir durumda sifrelenmis dosya önce kendi uzantisiyla kopyalanir:
# scp id_rsa/dsa.pub uzaktaki_bilgisayar:~/.ssh/bilgisayarin_ismi.pub
# cat bilgisayarin_ismi.pub >> authorized_key bu gerekli bilgileri authrized_keys’in icine kopyalar.

V. SSH Portunu Degistirmek

Daha önce de söyledigim gibi 22 ssh’nin varsayilan portu. Bu yüzden bircok hacker(!) burdan bu portu acik olan bilgisayarlara girmeye calisiyor. Bir sunucuyu ya da pc’yi korumanin bircok yolu var ancak portu degistirmek de bence cok etkili bir yöntem, cünkü karsi tarafin kullandiginiz portu arayacagina 22′yi kullananlara yönelmesini saglayabilirsiniz.

$ sudo nano /etc/ssh/sshd_config yaptiginizda karsiniza cikan sayfada asagidaki satirlari bulun

# What ports, IPs and protocols we listen for
Port 22

ve buraya istediginiz bir port numarasini (tabi baska bir programla cakismayacak) ekleyin. Örn. 1903.

# What ports, IPs and protocols we listen for
Port 22
Port 1903

Burda Port 22′yi silmedim. Böylece ssh’yi iki portu dinleyecek sekilde ayarlamis oldum, eger 22′den direkt kurtulmak isterseniz dogrudan 22 yerinde 1903 yazin, kaydedin ve cikin.

Önceden belirttigim gibi 22 varsayilan port numarasi oldugu icin $ssh uzaktaki@pc seklinde yapilan denemelerde Port 22 kullanilmaya calisilacak, 1903′ten girmek icin -p takisinin kullanilmasi gerek. Bu taki hangi portun kullanilacagini gösteriyor.

$ssh uzaktaki@pc -p 1903 gibi.

Si tenemos un servidor remoto al que accedemos a través de SSH una forma mas fácil y segura de acceder es utilizando claves RSA en vez de contraseñas.
Las claves RSA son en realidad claves asimétricas por lo que se usan claves distintas para encriptar y desencriptar. Por esto cuando hablamos de claves RSA en realidad nos referimos a parejas de claves: una publica y otra privada.
En nuestro caso empezaremos generando nuestras claves RSA, para esto ejecutaremos el comando:

$ ssh-keygen

Por defecto este comando nos genera claves de tipo RSA de 2048 bits. Respondiendo a todo con las opciones por defecto nos habrá generado 2 ficheros dentro de la carpeta ~/.shh:

• id_rsa: clave privada
• id_rsa.pub: clave publica

El siguiente paso consiste en copiar la clave publica a la maquina remota a la que queremos poder conectar sin contraseña. La forma mas sencilla seria con el comando scp desde la maquina local:

$ scp ~/.ssh/id_rsa.pub usuarioremoto@maquinaremota:~

Ahora tenemos que acceder a la maquina remota y desde allí añadir nuestra clave publica al fichero ~/.ssh/authorized_keys, para esto ejecutamos el siguiente comando en la maquina remota:

$ cat ~/id_rsa.pub >> ~/.ssh/authorized_keys

Con esto ya deberíamos ser capaces de acceder a la maquina remota desde nuestra maquina local sin introducir la contraseña, para comprobarlo ejecutamos:

$ ssh usuarioremoto@maquinaremota

Y ya deberíamos estar conectados en la maquina remota sin que nos pregunte la contraseña.

Over the past week there has been a lot of news over unsecured SSH on iPhone. First about the Dutch hacker who wasscanning the network for jailbroken users who had not changed their default SSH password. Now a hacker who goes by the name of “ikee” from Australia, created a worm that changes the home screen background to Rick Astley.

As I’m sure your aware by now this only affects users who have jailbroken their phone and installed OpenSSH, not just general users or who have jailbroken their device. If you have jailbroken your device and have got OpenSSH installed please read this guide on how to change your default password to ensure none of these worms or hacks will affect you.

ikee says this is how the worm spread: “The code itself is set to firstly scan the 3G IP range the phone is on, then Optus/Vodafone/Telstra’s IP Ranges (I think the reason Optus got hit so hard is because the other 2 are NAT’d) then a random 20 IP ranges. I’m guessing a few phones hit a range that another vulnerable phone was on.”

Once one phone is infected it searches for phones with the default password and then begins the process again.

Dutch Hacker Hack’s Into Jailbroken iPhone’s

How To: Change Your iPhone’s SSH Password

I got ifconfig running by installing the correct package with pkgtool and then being all awesome and installing some other stuff and doing dhclient eth0.

Next, I used curl to grab the openssh tarball and was told my c compiler cannot create executables.

Awesome.

Pro OpenSSH

by Michael Stahnke

Difficulty: Easy

What will this do?: It will allow you to access and modify hidden files on your iPod and add themes. In other tutorials I will teach you to use OpenSSH to customize your iPod. Just like a computer, there are many system files that should not be messed with so do not delete files unless you know what you are doing.

What you’ll need:

Jailbroken iPod with Cydia or Icy

A 3G, EDGE, or WiFi connection on your iPod/iPhone

On your iPod or iPhone, open up Cydia/Icy and search for “OpenSSH” Download the app that says OpenSSH. Once the download is finished, go to Settings>Wi-Fi and then tap the blue arrow next to the network you are using. Look for “IP Address”. The number will look like 192.xxx.x.x .Write the number down for later.

On your computer, download WinSCP, a FTP client which we will use to access your iPod. You can download it here .

Once installed, open up WinSCP. The host name will be the IP Address you wrote down earlier. the username will always be “root” and the password “alpine”. Press Login at the bottom. If you connect successfully you will see a screen open up with a folder named “Library”. If you could not connect, go back to your iPod and get your IP Address again and retry.

Once again, this is not very useful until you know how to use it. In later tutorials you will learn to edit system files and customize your iPod.

-Psychotic Waffles

I’ve discussed this before, but this time I’m focusing on another angle. When interacting with commercial SSH implementations (such as exists on OpenVMS and Tru64 implementations) it becomes useful to know how to convert your OpenSSH public keys to SSH2 format and vice versa.

These examples will assume that you are using OpenSSH and are on a UNIX system. Note that these are public keys, not private keys. All key types (DSA, RSA) should convert fine, but DSA is the stronger cryptographic algorithm.

One you have a public key in the appropriate format, you can add it to the authorized keys file (whatever that may be called). This is normally found in ~/.ssh or ~/.ssh2 depending on the SSH version.

The OpenSSH utility ssh-keygen is what makes this happen. This utility can do a lot more than just generate keys. It can be used to change passphrases of encrypted keys; convert keys; generate public keys from private OpenSSH keys; and read and write keys to smartcards.

Converting an SSH2 key to OpenSSH

To use an SSH2 public key in OpenSSH, it needs to be converted. Use the ssh-keygen utility in this manner:

ssh-keygen -e -f ~/.ssh/id_dsa_ssh2.pub > ~.ssh/id_dsa.pub

Converting an OpenSSH key to SSH2

Using an OpenSSH public key in SSH2 requires a conversion; ssh-keygen can do this:

ssh-keygen -i -f ~/.ssh/id_dsa.pub > ~/.ssh/id_dsa_ssh2.pub

So let’s say you have an App on your phone that you really need, but other people would keep going on it and you don’t really want them using it or seeing what it is. Well there is a simple way to disguise an app on your iPhone as anything you want.

Let’s say the app we want to hide is Cycorder.

Getting Started

First of all you have to SSH into your device and go to your Applications folder and open the relevant folder, in this case being Cycorder.app.

Once this is opened you will see the following files:
Cycorder
icon.png
info.plist
loading.png

Note: these will vary on application, but the files needed will remain the same.

Now copy the files icon.png and info.plist to your computer.

Before editing either it’s a good idea to backup the files just in case you go wrong.

Editing The Icon

People using the iPhone will most likely use icons to refer to an app, so changing the icon of the app you wish to hide is the first thing to do.

First you need to get the icon from another app or you could make one yourself. Simply pressing the Home button and Sleep/Wake button will capture a screen shot of your home screen and you edit the icon to the correct size etc.

Note: Always save the icon as a png image and make sure it’s transparent.

Downloading a free app off the App Store would maybe be a better idea for this as it gives you a quick and disposable way to disguise an app. However think about if people are likely to click on it, so find something boring.

Once you’ve edited and saved your new icon, save it as a png and copy it back to the app folder on the iPhone, replacing the original.

Changing The Name

The second way people will know which app is which, is via the name underneath the icon (which by now you will have changed).

To change the name simply open the plist either using a text editor or a dedicated plist editor such as iPodRobot’s plist editor.

Look at the plist and find the tag called
<key>CFBundleDisplayName</key>

and change the value below it what you wish the app to appear as on the home screen.

Once this is done, save the plist and copy it back to your device, overwriting the old one.

Now re-spring or re-boot your device and the application will now be disguised.

Windows XP ကေန PuTTY အသံုးျပုျပီး Ubuntu စက္ထဲကို login ဝင္ရတာ လြယ္ကူပါတယ္။ ဒီေနရာမွာ က်ေနာှ ဗမာလိုေလး အျကမ္းေလးေရးေပးမယ္၊ ျပည့္ျပည့္စံုစံုကိုေတာ့ အကိုးအကားလင့္မွာျကည့္ပါ။ ပထမဦးစြာ PuTTY Download Page ကေန putty.exe နွင့္ puttygen.exe နွစ္ခုကို Windows XP ေပါှမွာ အရင္ဆံုး download လုပ္ထားနွင့္ပါ။ ျပီးရင္ Ubuntu စက္မွာ openssh-server နွင့္ openssh-client နွစ္ခုကို install လုပ္ေပးပါ။

$ sudo apt-get install openssh-server openssh-client

ျပီးရင္ Terminal မွာပဲ ssh-keygen လို့ရိုက္ေပးျပီး ssh-keys ေတြကို ထုတ္ေပးပါ။ passphase ကိုေမးတဲ့အခါ ကိုယ့္ရဲ့ လွို့ဝွက္ကုတ္တစ္ခုခုကိုရိုက္ထည့္ေပးျပီး အဲဒီ password ကိုမွတ္သားထားပါ။ အဲလိုထုတ္ေပးလိုက္တဲ့ id_rsa နဲ့ id_rsa.pub keys ေတြဟာ ~/.ssh ေအာက္မွာရွိေနမွာပါ။ အဲဒီ ကီးေတြကို copy ကူးယူျပီး Windows XP စက္ဆီသို့ယူလာပါ။

$ ssh-keygen
$ cd ~/.ssh
$ ls

ေအာက္က ေဖာှျပပါပံုေတြကေတာ့ Ubuntu ေပါှမွာ လုပ္ေဆာင္ေပးရသမ်ွပါ။

Installing openssh-server & openssh-client

generating id_rsa keys and list

က်ေနာှတို့ အခု Windows ေပါှမွာလုပ္စရာရွိတာေတြလုပ္ေတာ့မွာပါ။ PuTTy က OpenSSH ကထုတ္ေပးလိုက္တဲ့ ကီးေတြကို တိုက္ရိုက္အသံုးျပုလို့ မရပါဘူး။ အဲဒါေျကာင့္ id_rsa ကီးကို id_rsa.ppk ကီးျဖစ္လာေအာင္ puttygen.exe အသံုးျပုျပီးေတာ့ convert လုပ္ေပးရမွာျဖစ္ပါတယ္။ ပထမတုန္းက က်ေနာှတို့ download လုပ္ထားျပီးသားျဖစ္တဲ့ puttygen.exe ကို double-click နွိပ္ေပးျပီး ဖြင့္ပါ။

open puttygen.exe and load private key

ပံုထဲမွာျမင္ရတဲ့အတိုင္း File >> Load private key ကိုနွိပ္ေပးပါက ဖိုင္ေတာင္းခံတဲ့ Dialog Window ေလးေပါှလာပါမယ္။ အဲဒီအခါမွာ Ubuntu စက္ဘက္ကေန ကူးယူလာတဲ့ id_rsa ကိးကို ဖြင့္ေပးပါ။ အဲလိုဖြင့္တာနဲ့ ကိုယ့္ရဲ့ passphase ကိုေတာင္းခံပါလိမ့္မယ္။ ကီးထုတ္စဉ္က သြင္းေပးခဲ့တဲ့ password ေလးကို ရိုက္သြင္းေပးတဲ့အခါ ကိုယ့္ရဲ့ id_rsa ကီးကပြင့္ပါမွာပါ။ တဆက္တည္း Save private key ဆိုတဲ့ button ကိုနွိပ္ေပးျပီး တစ္ေနရာမွာ သိမ္းလိုက္ပါ။ အဲဒါဆိုရင္ id_rsa.ppk ကီးအေနနဲ့ saved လိုက္တာေတြ့ရမယ္။

converting private key and save it

putty.exe ကိုဖြင့္ပါ။ PuTTY Configuration Window ေပါှလာပါမယ္။

Connection >> SHH >> Auth

ဘယ္ဘက္မွာျမင္ရတဲ့ Connection >> SSH >> Auth ကိုနွိပ္ရင္ အေပါှကပံုအတိုင္းျမင္ရမွာပါ။ အဲဒီမွာ Browse ဆိုတဲ့ button နွိပ္ပါ။ ကိုယ့္ရဲ့ id_rsa.ppk ကီးရွိရာကိုသြားျပီး ဖြင့္ေပးလိုက္တဲ့အခါ အဲဒီကီးမွာ သိမ္းထားတဲ့ ကိုယ့္ Ubuntu စက္ရဲ့အခ်က္အလက္ေတြကိုအသံုးျပုျပီး Ubuntu ကို login စလုပ္ပါမယ္။ ကိုယ့္ရဲ့ login name နွင့္ password ကိုရိုက္ထည့္ေပးလိုက္ရင္ ေအာက္ကပံုအတိုင္း login ဝင္သြားပါမယ္။

logging into Ubuntu

ျပီးရင္ ပံုမွန္ Linux ေပါှမွာအလုပ္လုပ္တဲ့အတိုင္း လုပ္နိုင္ပါျပီ။

like working in Terminal on Ubuntu

ပိုျပီးအေသးစိတ္သိခ်င္ရင္ေတာ့ အကိုးအကား ကိုဖြင့္ဖတ္နိုင္ပါတယ္။

Enjoy it!

If you’re using OpenSSH to connect to remote Linux machine, then this may come as bliss. This is based on public key authentication — (1) create a key-pair — a private and a public one, and then (2) save the public key in the authorized_keys file in the remote machine. Next time when you login using SSH to the remote server from the local machine where you have saved the private key, you won’t have to enter the password! Isn’t it cool? OK, now let’s get down to business, shall we?

Step 0: Make sure the RSA and public key authentication methods are enabled (which are in general enabled by default) in /etc/ssh/sshd_config on the remote machine — it should look like the following:

RSAAuthentication yes
PubkeyAuthentication yes

and then reload the configuration if you had to modify it

You need the administrative rights for the above.

.

Step 1: Use the command ssh-keygen to create the key pair:

Save the key to the default location, viz. ~/.ssh/id_rsa. When you hit enter, it’ll ask you for a passphrase — leave it empty (see warning below). You need to hit enter once more to confirm it.

Now if you go to ~/.ssh directory, you’ll see that two new files are created: id_rsa (your private key — don’t lose it or give it to somebody else!) and the public key, id_rsa.pub.

.

Step 2: We need to append the public key to the authorized_keys file or save the key as a new file with the name authorized_keysX (where X is a number to avoid conflict) in ~/.ssh directory on the remote machine. We’ll use the fancy vi trick that we saw earlier:

Enter your password when you’re asked. Once the vi window opens up, go to the end of the file (hit Shift+G) and then append the public key file

assuming you’re still in the ~/.ssh directory on the local machine. Next, save the file and exit.

Note: you may also use

to automatically put the ID in the desired place.

Now you are all set to login to the remote machine using ssh without a password!

.

WARNING: The big security concern and a work-around (still being lazy!)

The ease of this method has a very strong downside: if the local machine is compromised the attacker will waltz onto the remote machine. A way out of this is to protect your private key with a non-empty passphrase. That also means every time the machine requires access to the private key (i.e., every time you login to the remote machine where you saved your public key), you have to enter the passphrase. What’s the use of this hoopla then — you may ask. Well, when there is a wish there is a way too — by committing the key to the  local system’s `memory’ so that you type the passphrase once and only once for the whole session.

OK. Let’s first change password to a non-empty string, shall we?

It’ll ask for the location of the key. Then you’ll have to enter a passphrase and verify it (don’t leave this empty this time).

Next make the system remember your key:

It’ll ask for the passphrase (in order to ‘unlock’ your private key) and then for the whole session you won’t need any password/passphrase to login to the remote machine.

.

READ MORE: here and here.

Recently I decided to get out the old GTA2 Laptop again. Why GTA2? Because that was its killer application, as it only features a 600 Mhz Intel Celeron, some on-board graphics card and 64 MB of RAM. This game runs pretty well while being very much fun, especially the LAN mode is just awesome. If you never played GTA2 yet, here’s a multiplayer gameplay video I just googled up. Also the game became freeware, so if you like it download it!

But let’s get to the point of the article. I have always played with the thought of installing (any) Linux on this notebook, until yesterday it was running a very nlited Windows XP.  So I finally decided to throw that off the about 5 GB harddrive and give arch a shot. Why did I choose Arch and not lets say Debian? The later one compiles x86 packages for i386, but archlinux compiles to i686, which is less backward compatible, but a bit faster. Plus the other reasons why I just love archlinux – simple configuration, pacman and yaourt, aur and so on.

While downloading the lastest snapshot for i686, I browsed a bit around and came across this thread from which I used their suggestions to add lowmem to the kernel line as well as setting ramdisk to 20% (also kernel line in grub). Then /arch/setup worked out pretty good, just like any installation. It was a bit slower of course, but I didn’t expect it to behave different.

Suprisingly WLAN actually worked with ndiswrapper, I was not sure about that at all. This laptop has a T-Com Sinus 154 Card, I took the windows driver from the installation CD. The next not-so-clear-thing was setting up xorg without nvidia (I’m used to do it with that), but after I found hwd, it worked out fine.

lxpanel displays the CPU usage at the bottom right corner

To get decent performance, only lightweight and fast software would work. As WM I chose openbox with the lxpanel. The browser with the best performance after text browsers is propably dillo. But dillo can’t even display common websites like wikipedia and google right, because its CSS implementation has just started. Even worse, javascript does not work at all, so sadly half the web does not work. If you just want to do some quick research, it is enough though, so I kept it installed. Firefox was slow as hell, just the experience I had using it with windows XP. Because of that I tried some alternative browsers. Chromium (the opensource project behind Google Chrome without the spyware) just segfaulted, so I tried the closed source Opera (10). Yaourt -Ss opera lead me to opera-snapshot from the archlinuxfr repository, which was actually pretty fast. In every other case, it would have been Firefox. But as this was just a matter of speed, Opera took the cake.

QMPDClient open

Other software I installed is mpd, mpc and for the first time QMPDClient as GUI. Mpd is very lightweight and can be used without a X server, just like unix tools should behave. I chose the said graphical user interface, because it is not written in script-languages like python or perl, but in c++ which not only has less dependencies, but also brings more speed. In fact, I have nothing python or perl related installed on this machine.

desktop pc: copying music from within amarok to my laptop

Another pick was OpenSSH and SSHFS over nfs and samba. Why? Because nfs did not work at all and samba plus its dependencies was about 100 megabytes. When I mounted my laptop’s music folder on my desktop computer, I was able to fill it from within amarok via drag and drop, just like any mp3 player, which is quite useful

Other applications I installed and tested were pidgin, codeblocks and lbreakout2. For pidgin, I think BitlBee plus something like xchat would be the better choice, but I have not tried that yet. It was usable though, as well as codeblocks and lbreakout2 were. What I did not try yet is GTA2 (with wine), but I will likely do that.

No desktop icons, no wallpaper

Software I did not install on purpose: A program that displays a wallpaper and/or desktop icons and a file manager. These are just too wasteful for that little system.

Update: As expected, GTA2 is not playable at all. The wine-layer is just slowing it down too much, and while epsxe offers more tweaking, it is not faster. On the other hand, I’ve got bitlbee with the otr patch running. Bitlbee is a fake IRC server which displays contacts from other IM networks that all IRC programs can connect to. Since I found out that Opera has an integrated IRC client, I don’t even need another program and so I removed pidgin.

Furthermore I did not mention the usage of the Vorbis audio codec yet, which is better known by its file extension ogg. Because they are so small, you can easily fit much music on such a tiny harddrive. Oh and I compile most aur packages from my arch32 environment on my desktop pc. That saves much time.

So in conclusion there’s pretty much you can do with a low-end machine like this. The most exciting feature for me is ssh and ssh-fs. GTA2 does not work anymore, but I have played the single player mode almost through anyway. LBreakout2 works fine and without making the cooler get very loud, like GTA2 used to. Plus now I just have a fully running linux with all its nice CL tools

Hace unos días explicábamos como instalar en nuestro equipo OpenSSH. Hoy vamos a ver cómo utilizar scp.

¿Qué es scp?

Wikipedia

Secure Copy o scp es un medio de transferencia segura de archivos entre un host local y otro remoto, o entre dos hosts remotos.

A diferencia de rcp, scp permite encriptar los datos durante su transferencia, evitando así que cualquier usuario pueda extraer información de nuestro paquete de datos.

¿Cómo empezar a usarlo?

Un vistazo rápido a la página de ayuda sobre scp nos muestra su sintáxis:

scp [-1246BCpqrv] [-c cipher] [-F ssh_config] [-i identity_file] [-l limit] [-o ssh_option] [-P port] [-S program] [
[user@]host1:]file1 [...] [ [user@]host2:]file2

Para comprender la funcionalidad de cada opción, puedes visitar la entrada del manual para scp.

Expongamos unos ejemplos que nos permitan familiarizarnos:

• Copiar un archivo de una máquina remota a una local
  • scp username@remotehost:file.txt /local/directory
• Copiar un archivo de una máquina local a una remota
  • scp file.txt username@remotehost:/remote/directory

• Copiar un archivo de una máquina remota a otra remota
  • scp username@remotehost1:/remote/directory/file.txt \
username@remotehost2:/remote/directory
• Copiar varios archivos de tu máquina local al directorio home de tu máquina remota
  • scp file1.txt file2.txt username@remotehost:~
• Copiar múltiples archivos de una máquina remota a tu directorio actual en la máquina local
  • scp username@remotehost:/remote/directory/\{a,b,c\} .
  • scp username@remotehost:/remote/directory/\{file1.txt,file2.txt\} .

También puedes copiar directorios completos utilizando la opción -r para ello:

• Copiar el directorio ‘etc’ de una máquina local a una remota
  • scp -r /etc username@remotehost:/remote/directory

Los casos que hemos explicado para los ficheros también son aplicables en directorios.

Mejorando el rendimiento de scp

Si has echado un vistazo a las opciones que incluye scp habrás advertido -c y -C. En caso de no ser así, damos una breve explicación:

• -c cypher_spec

Nos permite elegir la técnica de cifrado a usar para encriptar la transferencia de datos. Si estamos usando la versión 1 del protocolo, podemos usar: ‘3des‘, ‘blowfish‘ y ‘des‘. 3Des (triple-des) es una triple encriptación-desencriptación que usa 3 llaves diferentes. Blowfish es un codificador de bloques simétricos, muy seguro y bastante más rápido que 3des. Des únicamente está soportado en aquellos clientes ssh que implemente la versión 1 del protocolo y no disponen de soporte para el cifrado 3des.-

Para la versión 2 del protocolo, tenemos: ‘3des-cbc‘, ‘aes128-cbc‘, ‘aes192-cbc‘, ‘aes256-cbc‘, ‘aes128-ctr‘, ‘aes192-ctr‘, ‘aes256-ctr‘, ‘arcfour128‘, ‘arcfour256‘, ‘arcfour‘, ‘blowfish-cbc‘ y ‘cast128-cbc‘.

• -C

Habilita la compresión de los datos.

Por defecto scp usa 3des para encriptar los datos, si quieres puedes aumentar la velocidad de transferencia utilizando blowfish en su lugar. Esto puedes hacerlo especificando la opción -c blowfish

scp -c blowfish local_file username@remote_host:remote_dir

También puedes comprimir los datos que vayas a enviar, en caso de disponer de una conexión lenta.

scp -c blowfish -C local_file username@remote_host:remote_dir

Pues si, por fin me hice con una máquina de estas y como es normal viniendo de mi desde el minuto 0 en el que el iPhone cayo en mis manos empecé a trastear con él y a investigar.

Hay muchísima documentación online sobre el iPhone, pero me he dado cuenta que no hay tanta de como lograr acceder a una shell del iPhone, ojo! no estoy hablando de una emulación de una shell, estoy hablando de una consola en condiciones, el sistema operativo del iPhone no deja de ser un UNIX por lo que lo único que haremos será añadirle una consola de comandos.

Lo primero de todo tenemos que habilitar al iPhone alguna manera de poder acceder a él por modo comando. Algunos ya sabrán lo que es SSH, a los que no, tienen una muy buena explicación en Wikipedia. Al igual que tampoco me voy a poner a explicar como instalar OpenSSH en el iPhone (este es el programa que tendrá que tener instalado el iPhone para lograr que este sea un servidor de SSH para posteriormente conectarnos a él), como dije antes hay muchísima documentación por Google de como hacerlo. OpenSSH en el iPhone no vale solo para esto, la utilidad más conocida que tiene es el acceso por completo al sistema de archivos del iPhone gráficamente a través de Windows.

Una vez instalado y funcionando hay que instalar iSSH, que una de las maneras de conseguirlo es pagando 3,99€ en la App Store de Apple. iSSH es una consola capaz de poder conectarse a través de SSH y Telnet incluso si queremos conectarnos a un X server con iSSH podremos. Más información en el link de antes.

Con iSSH instalado tendremos que ejecutarlo y acceder a ‘Add Configuration…’

Aquí tendremos que rellenar los datos tal y como se muestra en la imagen (los campos que no se muestran es que no hay que tocarlos).

Una vez hecho esto pulsamos en ‘Save’ y el programa volverá a la anterior pantalla con una nueva configuración llamada iPhone como aparece en la imagen.

Pulsamos sobre ella y al cabo de unos segundos nos aparecerá una ventana pidiendo que debemos añadir una clave RSA2 a iSSH esto es necesario porque de esta manera estamos realizando una conexión cifrada entre iSSH y el iPhone, aquí no es que sea excesivamente necesario, pero poneros entre un servidor y un PC conectado por SSH al servidor, si hay una tercera máquina capturando paquetes teóricamente no se “enteraría” de lo que captura al estar cifrado y no tener la llave para poder descifrarlo, esa llame es esa clave RSA2 que nos pide el iSSH para añadir. Sin más pulsamos en ‘Accept’.

La siguiente ventana nos pedirá una contraseña para el usuario root. Como cualquier sistema operativo UNIX el super-usuario root debe tener una contraseña, en este caso es “alpine” sin comillas.

Hecho esto iSSH se conectará el SSH del iPhone y podremos manejarlo sin problemas.

Una vez que terminemos con la sesión tendremos que escibir ‘exit’ para cerrar la conexión. El iPhone nos contestará con un ‘logout’ (sesión terminada) y o bien pulsando la X si queremos realizar otra conexión o el botón Home para salir del programa abandonaremos esa terminal.

Pues esto es todo, lógicamente en el apartado de configuración podremos modificar los valores para conectarlo a otro PC a través de SSH como hemos visto aquí, o a través de Telnet, una conexión VNC, etc.

EDIT 24/08/09: Me he enterado (error mio el hacer esta entrada antes de buscarlo) que existe una terminal directa del iPhone sin necesidad de conectarse por medio del SSH, era lógico que ya existiese un programa que sin necesidad de terceros pudiera habilitar la consola de comandos del sistema operativo. La aplicación en concreto es MobileTerminal. Personalmente no me gusta demasiado ya que a mi me hace cosas raras, se cierra solo y tiene problemas con la posición de la pantalla. Seguiré con el método descrito en el blog por dos motivos: el primero es que el SSH lo uso para poder acceder al sistema de archivos del iPhone a través de cualquier PC y que iSSH me permite conectarme a servidores que administro y para una emergenci a(o no)es realmente bueno.

¿Qué son las claves públicas?

Wikipedia

En criptografía, se denomina una infraestructura de clave pública a una combinación de hardware, software y procedimientos de seguridad que permiten la ejecución con garantías de operaciones criptográficas como el cifrado, la firma digital o el no rechazo de transacciones electrónicas. Para un correcto funcionamiento es necesario que intervengan las siguientes partes:

• Un usuario iniciador de la operación.
• Sistemas servidores que dan ocurrencia de la operación y garantizan la validez de los certificados implicados en la operación.
• Un destinatario de los datos cifrados/firmados/enviados garantizados por parte del usuario iniciador de la operación.

¿Qué objetivo nos marcamos?

El propósito de usar la autentificación mediante claves públicas es sacar el mayor partido posible a SSH mediante el uso de clave privada y pública. De forma que al compartir esta última con el servidor, podamos identificarnos automáticamente, sin necesidad de utilizar el esquema clásico de usuario y contraseña, al que estamos acostumbrados.

¿Qué algoritmos de cifrado usar?

SSH permite usar los algoritmos RSA y DSA, pero… ¿cuál de ellos nos conviene más?

• RSA – Es un algoritmo asimétrico cifrador de bloques, que utiliza una clave pública, la cual se distribuye y otra privada, guardada en secreto por su propietario.Su funcionamiento reside en el uso de expresiones exponenciales dentro de la aritmética modular. Obteniendo una completa seguridad, debido a que aún no se conocen formas óptimas de factorizar  un número grande en sus factores primos utilizando ordenadores personales.El RSA se basa en dos problemas matemáticos: el problema de factorizar números grandes y el problema RSA. El descifrado completo de un texto cifrado con RSA es computacionalmente intratable.
  Por otro lado la factorización de números grandes proponen métodos para longitudes de 600-700 bits de longitud. Y generalmente, las claves RSA usan entre 1024-2048 bits.
• DSA – (Digital Signature Algorithm o Algoritmo Estándar de Firmado) es el algoritmo de firmado digital incluido en el DSS (Digital Signature Standard o Estándar de Firmas Digitales) del NIST Norteamericano. Está basado en el problema de los logaritmos discretos y únicamente puede emplearse para las firmas digitales. A diferencia del RSA, que puede emplearse también para encriptar.La elección de este algoritmo como estándar de firmado generó multitud de críticas puesto que perdía bastante flexibilidad respecto al RSA.

La diferencia entre ambos reside en los tiempos obtenidos para la generación, firmado y comprobación de las claves públicas. Usando este benchmark (podéis usar cualquier IDE con la última versión del JDK) se obtuvieron los siguientes tiempos:

El algoritmo DSA es más rápido para generar la firma que para verificarla, al contrario de lo que sucede con RSA. Por lo que para realizar la autentificación en nuestro servidor SSH usaremos este último.

Además, si comparamos el tamaño de las llaves generadas por ambos algoritmos, comprobaremos cómo las utilizadas por RSA son superiores a las de DSA.

Dicho esto, usaremos RSA.

Configuración del servidor

Comprobamos si el equipo donde tenemos instalado sshd tiene activada la versión 2 del protocolo SSH y que esté habilitada la opción para utilizar claves RSA. Para ello buscamos las siguientes directivas en el fichero /etc/ssh/sshd_config:

Protocol 2
RSAAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys

Para cada usuario que vaya a conectarse, debe existir el directorio /home/usuario/.ssh y en él el archivo authorized_keys. En caso de no ser así deberemos crearlo de forma manual y posteriormente iniciar el servidor.

cd ~
mkdir .ssh
touch .ssh/authorized_keys
sudo /etc/init.d/sshd start


Generación de los pares de claves RSA

Como antes comentamos, SSH nos permite generar indistintamente claves RSA o DSA (en nuestro caso usaremos la mencionada en primer lugar), creándose para ambas una clave pública y una clave privada.

Dichas claves, pueden generarse en el propio servidor, en el ordenador cliente, o en cualquier otra máquina.

Al final sólo la clave pública debe aparecer en el fichero .ssh/authorized_keys del servidor al que queremos conectarnos.

El usuario interesado en generar el par de claves usará ssh-keygen. En el proceso, se nos pedirá introducir un passphrase, lo que viene a ser una contraseña para poder generar unas claves más fuertes y seguras.

En nuestro caso, vamos a usarla y a explicar posteriormente como indicarle al sistema que sólo nos la pida una vez por sesión, y no cada vez que nos autentifiquemos en el sistema.

$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/sebas/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/sebas/.ssh/id_rsa.
Your public key has been saved in /home/sebas/.ssh/id_rsa.pub.
The key fingerprint is:
63:de:92:6d:00:fa:d9:17:55:45:ce:bc:25:42:8b:4c sebas@TheWorkstation
The key's randomart image is:
+--[ RSA 2048]----+
| E . .oo|
| o o o + |
| . o + . =|
| . . . . .o|
| . S . . |
| . = * . |
| o = = |
| + |
| |
+-----------------+


El anagrama que produce esta versión de ssh-keygen, se denomina randomart y se trata de una representación visual de la huella

digital de nuestra clave, para que sea más legible para el ojo humano y para dispositivos ópticos.

Si lo deseas, puedes usar la herramienta visprint que a través de técnicas de fractales, te permitirá obtener otro tipo de randomart.

Instalación de clave pública y protección de la clave privada

Para validar todo este proceso es necesario colocar nuestra clave pública en el servidor donde tenemos pensado autentificarnos.

Existen varias posibilidades de hacerlo, una de ellas es por ejemplo hacer uso del siguiente comando (Cliente):

[usuario1@localhost usuario1]$ ssh usuario @host_remoto \'cat >> .ssh/authorized_keys' < .ssh/id_dsa.pub

Con este comando añadimos directamente la clave al fichero authorized_keys del servidor remoto de forma automática, ahorrándonos así un poco de trabajo.

También podemos usar (Cliente):

$ ssh-copy-id usuario_remoto@host_remoto

Pero ya que estamos haciendo todo con paso firme y decidido, continuemos haciendo las cosas con buen pie. Así que vamos a usar el comando scp, que trae incluido OpenSSH para hacer una transacción de ficheros entre el cliente y el servidor remoto de la forma más segura posible. Así que usaremos la siguiente orden (Cliente)

$ cd ~/.ssh
$ scp id_rsa.pub usuario@host_remoto/

Recuerda que la clave pública debe ser incluída en el fichero ~/.ssh/authorized_keys de cada máquina donde queramos usar dicha autentificación.

Ahora que ya tenemos la clave pública en el servidor, falta añadirla al fichero authorized_keys de éste (algo que comentamos anteriormente que se podría conseguir de forma directa utilizando el primer comando) (Servidor).

$ cd ~/.ssh
$ cat id_rsa.pub >> authorized_keys
$ shred -v  --remove id_rsa.pub

Conclusión

Si has realizado correctamente todos los pasos que se han ido indicando, ahora podrás conectarte a tu servidor SSH (Si no tienes uno, visita ésta entrada donde te explicamos cómo montar uno) sin necesidad de identificarte, tan sólo haciendo uso de las claves RSA que has generado.

También puedes incrementar un poco la seguridad modificando las siguientes directivas de tu fichero de configuración sshd_config:

PasswordAuthentication no
PermitRootLogin no

Con las que impedirás la conexión como administrador y la autentificación mediante password para los usuarios.

¿Qué es SSH?

Conocido como Secure Shell (Intérprete Seguro de Órdenes) es el protocolo usado por excelencia para establecer conexión con máquinas remotas a través de una red.
Ampliamente extendido entre los usuarios, se caracteriza por permitir un control completo del ordenador servidor a través de un intérprete de órdenes o a través de X para ejecutar aplicaciones gráficas en caso de disponer de un servidor corriendo.

¿Por qué SSH?

SSH es un protocolo caracterizado por encriptar todas las conexiones que realiza, imposibilitando a terceros descifrar lo que se escribe durante la sesión, incluido el usuario y la contraseña.

Algo imposible con el protocolo FTP, donde la información viaja en texto plano.

Además, combinando los protocolos scp (Secure Copy) y ssfhs (Secure Shell FileSystem) con SSH conseguiremos una forma robusta e impenetrable de compartir ficheros e información entre equipos remotos.

Conociendo a OpenSSH

OpenSSH es un conjunto de aplicaciones que tiene como objetivo permitir comunicaciones cifradas a través de una red, usando para ello el protocolo SSH comentado anteriormente.

El proyecto está liderado por Theo de Raadt y es una alternativa libre a SSH.

Las aplicaciones que vienen incluidas son:

• ssh – Reemplaza a rlogin y telnet.
• scp – Reemplaza a rcp.
• sftp – Reemplaza a ftp para copiar ficheros entre dos computadoras.
• sshd – Servidor demonio SSH.
• ssh-keygen – Herramienta usada para generar claves RSA y DSA usadas para mejorar la seguridad y autentificar al usuario que establece la conexión.
• ssh-agent | ssh-add -  Herramienta para autentificar de forma más sencilla, sin necesidad de estar continuamente el passhrase usado como clave.
• ssh-keyscan – Escanea una lista de clientes y recoge sus claves públicas.

Clientes SSH

Si decides no usar OpenSSH desde Linux, siempre puedes usar alguna de estas aplicaciones libres:

• OSSH – A diferencia de OpenSSH que añade el protocolo SSH2 y extiende el soporte de SSH1. OSSH únicamente implementa SSH1.
• LSH/psst – Implementación libre del protocolo SSH2, estandarizado actualmente por el grupo de trabajo IETF SECSH.
• Dropbear -  Pequeño servidor SSH2 y cliente. Que funciona bajo varias plataformas basadas en POSIX.

Para Windows, puedes encontrar:

• PuTTY – Implementación del protocolo SSH1+SSH2, posiblemente sea el cliente más extendido y usado entre los usuarios.
• WinSCP – GUI basada en sftp y scp. El núcleo que sustenta su protocolo SSH está basado en PuTTY.
• FileZilla – Potente cliente FTP. Diseñado pensando en la usabilidad y facilidad.

No obstante para este tutorial y los venideros, se usará OpenSSH (Linux)/PuTTY (Windows).

Instalación de OpenSSH

Algunas distribuciones traen instalado por defecto un cliente SSH, no obstante explicaremos como realizarla para un sistema Ubuntu.

Instalando a través de terminal

• Para instalar el cliente:         sudo apt-get install openssh-client
• Para instalar el servidor:       sudo apt-get install openssh-server

Primeros pasos con SSH

• Para iniciar el servidor SSH:              service ssh start
• Para parar el servidor SSH:               service ssh stop
• Para reiniciar el servidor SSH:          service ssh restart

Conectándonos a un servidor remoto (Linux) desde un cliente (Linux)

Primero descubramos qué dirección IP tenemos en el servidor. Para ello desde una ventana de terminal escribimos:

/sbin/ifconfig

Nos aseguramos de que el servicio esté ejecutándose:

service ssh start

Y ahora podemos dirigirnos a nuestro cliente y establecer una conexión remota al equipo que ejerce de servidor. Basta con escribir la siguiente orden en la terminal:

ssh usuario_remoto@host_remoto

Dónde:

• usuario_remoto – Será el nombre de usuario con el que queremos iniciar sesión. Debes tener en cuenta que si no está registrado en el equipo, no podrás iniciar sesión con él.
• host_remoto – Es la dirección del equipo que ejerce como servidor. Ahí es donde pondremos la dirección IP que hemos obtenido antes.

La primera vez que establezcas conexión el sistema nos pedirá confirmación, bastará con decir “yes” y una vez introducida la contraseña correcta para el usuario solicitado, nos encontraremos identificados en el equipo remoto.

Los comandos, programas y scripts que lancemos tras conectarnos se ejecutarán en la máquina remota, utilizando los recursos de esta (CPU, memoria, disco, etc…).

Recuerda que podrás hacer todo aquello que se contemple bajo los permisos que posea el usuario con el que hayas iniciado sesión.

Establezcamos una conexión que nos permita ejecutar aplicaciones gráficas.

Ahora que hemos visto cómo conectarnos y trabajar desde nuestra ventana de terminal, vamos a ir un poco más allá, y vamos a ejecutar aplicaciones gráficas.

Un método bastante efectivo consiste en utilizar un túnel SSH para encapsular el protocolo X11, permitiendo transmitir la información de manera segura y sin crear conflictos con los cortafuegos.

Pero para ello debemos configurar un par de parámetros en el fichero sshd_config:

X11Forwarding    yes
AllowTcpForwarding    yes

Con X11Forwarding especificamos si se permite el reenvío por X11. El valor por defecto es ‘yes’. Desactivarlo en ningún momento ayudará a mejorar la seguridad del servidor.

Y lo que intentamos conseguir activando dicha directiva es permitir ejecutar aplicaciones gráficas en el servidor remoto. Recordad que X es un sistema de ventanas creado para dotar de interfaz gráfica a los sistemas Unix.

Por otro lado con AllowTcpForwarding especificamos si se permite el reenvío a través del protocolo TCP. Al igual que pasaba con X11, desactivarlo, en ningún momento proveerá mayor seguridad a nuestro servidor. Su valor por defecto es ‘yes’.

Una vez hecho esto, ya podemos iniciar una sesión SSH y ejecutar aplicaciones gráficas. Para ello bastará con escribir en nuestra terminal:

ssh -X -Y usuario_remoto@host_remota

• -X (X11 forwarding)
• -Y (X11 trusted forwarding)

Ahora podremos ejecutar cualquier aplicación que se encuentre instalada en el servidor. Reproduzcamos una película con mplayer por ejemplo:

mplayer nombre_película

Recuerda que los recursos se tomarán del equipo donde te encuentres conectado.

Host Ubuntu 9.04,rodando uma Vitual Machine Windows XP, acessando um servidor FreeNX Ubuntu 9.04, via Hamachi…

Goal:

allow users to log into a CentOS 5.3 server via ssh, but then constrain their mobility by using the chroot support introduced in OpenSSH 4.8p1.

Resources:

1) http://v2.robbyt.com/2008/howto/chrooted-sftp-with-openssh-5/

2) http://www.dotnux.com/?p=3

3) http://forums.fedoraforum.org/archive/index.php/t-30684.html

Procedure:

I followed the tutorial in resource 2 for the most part, but the rpm build will fail with an error if the “/usr/src/redhat/RPMS/i386″ and “/usr/src/redhat/BUILD” directories are not made in advance, a step in resource 1.  

With these two tutorials, I was able to build and install OpenSSH 5.1, but then I ran into a couple hiccups.  When I tried to log in using a dummy account (“random1″) assigned to the “sshusers” group described in resource 1, ssh rejected my log in with an error: “Permission denied (publickey,gssapi-with-mic).”.  Looking in the ssh logs (“/var/log/secure”), I saw: “Authentication refused: bad ownership or modes for file “/home/random1/.ssh/authorized_keys”.  Referring to the details provided in resource 3, I changed the permissions on “random1/.ssh” and “random1/.ssh/authorized_users” to 700.  Then I was able to ssh in, but immediately I received the error “/bin/bash: No such file or directory”, and was bounced out.  I moved the ls and bash executables placed in “/usr/bin” in resource 2, to “/bin” and then all was good

Special thanks to robbyt, author of resource 1, for his assistance.