Settimana un po' faticosa, quindi mi faccio vivo solo ora. :P

Il problema

Ma veniamo al sodo: una delle cose più noiose dell'amministrare svariate macchine è spostare file, smandrupparli, ...

In particolare, in ambiente Unix (ma non solo...) la comodità e praticità di usare strumenti come OpenSSH (server e client) per accedere e gestire più nodi si scontra spesso con la noia di doversi loggare su tutte le macchine.

La soluzione "canonica"

Una soluzione è certamente rappresentata dal ricorso al programma Ssh-agent di OpenSSH, che permette di stabilire connessioni SSH senza dover digitare la password (opportunamente configurato, ci penserà lui al vostro posto).

Expect!

Un'altra alternativa, certamente grezza ma altrettanto efficace è usare expect, un eccellente programma che vi permette di rendere non-interattive ("batch") delle sessioni altrimenti interattive.

Sostanzialmente vi permette di pianificare, sotto forma di script, una serie di "a-domanda-X-rispondi-Y-e-proseguiamo-con-la-prossima".

Per capirci: quando effettuate una connessione SSH ad una macchina vi troverete la fatidica richiesta di inserimento password.

Voi potete fare in modo che expect attenda (da cui il nome) esattamente quella domanda e quando la riceve invii la password al posto vostro.

Un esempio concreto

Attenzione: quanto riportato di seguito ha solo una valore "didattico" e non mi assumo alcuna responsabilità dell'uso che ne farete. Per rendere le cose più semplici ho volutamente optato per tralasciare dettagli importanti "di sicurezza". In particolare vedrete la password quando la digiterete (una e una sola volta) ed essa verrà comunicata in chiaro agli script. Non è una soluzione "sicura" ma lo scopo di questo post è solo quello di mostrarvi expect in azione.

Supponiamo di avere la necessità di trasferire un file (prova.txt) su diverse macchine, tutte con la stessa combinazione utente/password (come detto, solo per finalità didattiche) e di non voler digitare la password per ogni connessione/trasferimento via SSH.

In altre parole vogliamo usare expect per automatizzare i trasferimenti di file via SSH.

Iniziamo salvando gli IP, uno per riga, in un file (nel nostro caso lo chiameremo ip.txt).

Poi potremmo pensare di creare degli scrippettini come questi:

1. uno script di shell "involucro", chiamato ad esempio copia_multipla.sh, che legge il file riga per riga (cioè un IP per volta) e richiama opportunamente i due seguenti scrippettini expect. La password di connessione SSH viene richiesta da questo script e passata ai successivi (non scrivetela mai dentro uno script!);
2. il primo scrippettino expect, testa, tenta di collegarsi all'IP-riga e risponderà "yes" all'eventuale domanda posta da SSH quando ci si connette per la prima volta ad un IP/macchina. Lo script ha un timeout di pochi secondi visto che SSH pone la domanda solo la prima volta che ci si connette a quello specifico nodo (quindi risulta essere inutile se l'IP è già "conosciuto" da SSH);
3. il secondo e ultimo scrippettino expect, testa, copierà il file su quel nodo, inserendo quando richiesto la password fornita da copia_multipla.sh.

Gli script

Il file copia_multipla.sh (script di shell Bash):

#! /bin/bash
echo -n "Utente? "
read USER
echo -n "Password? "
read PASSWORD
echo -n "File da copiare? "
read FPATH
echo -n "Destinazione? "
read DPATH

# legge il file con gli IP, una riga-IP alla volta...
while read IP
do
    echo "NODO: $IP";
    ./testa $USER $PASSWORD $IP
    ./copia $USER $PASSWORD $IP $FPATH $DPATH
    echo " ";
    echo " ";
done < ip.txt

Il file testa (script expect):

#!/usr/bin/expect -f
set user [lrange $argv 0 0]
set password [lrange $argv 1 1]
set ipaddr [lrange $argv 2 2]
# timeout di 5 secondi: se il nodo risponde
# ma la sua richiesta non è quella di digitare "yes/no"
# possiamo uscire perchè l'IP è già noto a SSH...
set timeout 5
# connessione SSH all'host di destinazione...
spawn ssh $user@$ipaddr ls
# attendiamo la richiesta di primo accesso al nodo via SSH...
expect "(yes/no)?*"
# inviamo "yes"...
send -- "yes\r"
# mandiamo un altro ritorno a capo per essere sicuri
# di aver concluso e chiudiamo la connessione
send -- "\r"
expect eof

Il file copia (script expect):

#!/usr/bin/expect -f
set user [lrange $argv 0 0]
set password [lrange $argv 1 1]
set ipaddr [lrange $argv 2 2]
set fpath [lrange $argv 3 3]
set dpath [lrange $argv 4 4]
# timeout infinito (-1): potete regolarvi sulla base
# della dimensionedei file da trasferire...
set timeout -1
# connessione SSH all'host di destinazione per trasferire il file...
spawn scp $fpath $user@$ipaddr:$dpath
# attendiamo la richiesta di password...
expect "*?assword:*"
# inviamo la password...
send -- "$password\r"
# mandiamo un altro ritorno a capo per essere sicuri
# di aver concluso e chiudiamo la connessione
send -- "\r

Eseguiamo!

Dopo aver impostato i permessi di esecuzione agli script (chmod +x copia_multipla.sh testa copia) vi basterà eseguire ./copia_multipla.sh.

Lo script vi chiederà username, password, file da trasferire e directory di destinazione dopodichè pensarà lui a copiare quel file sui nodi contenuti nel file ip.txt.

Conclusioni

Expect è davvero potente. In passato lo avevo usato per testare server di posta simulando sessioni SMTP via telnet (sì, expect è davvero sublime).

Spero che possa esservi d'aiuto!

Per maggiori info, vi consiglio di dare un'occhiata al sito, sezione apposita (Bash Shell Scripting Directory For Linux / UNIX) nonchè al post specifico da cui ho scopiazz... ehm "tratto ispirazione" inizialmente. ^^'

Ciau. ^^

Attenzione: se copiate il codice, controllate che gli apicetti/apostrofi (') e le virgolette (") siano "diritti" e non "obliqui": non sono la stessa cosa e hanno significati diversi! (Wordpress tende a cambiarli, presumo per ragioni di sicurezza)

Tra le novità di questo major release vale la pena citare la presenza del filesystem HAMMER, numerosi cambiamenti al kernel (implementazione nativa del fair-queue e connection state recovery nativa), rinnovato supporto hardware, blacklist per le chiavi SSH generate da alcuni sistemi Debian, documentazione migliorata e una gran quantità di software aggiornato (BIND, OpenSSH, tnftpd, GCC ed altri).

L’annuncio ufficiale è particolarmente sintetico quindi consiglio di passare direttamente alle note di rilascio, che includono anche i link per il download (HTTP ed FTP).

[via: distrowatch.com || ossblog.it]

They drop jardiknas line to 1Mbps, and they stop my routing injection from inherent... so our campus's internet become LEMOT (slow).

so I have to move to another line...

wait there are no proxy in other line .... because proxy server that use VIP-net line broken

so another solution is using kebo.vlsm.org.

Try to make ssh-tunnel to kebo,...

# ssh -ND 9999 kebo.vlsm.org

Then change the browser proxy preference to use SOCKS5 with host : localhost and port 9999

so now you can surf to internet using another line

Good luck

SSH banyak di gunakan di device yang memiliki flavor UNIX seperti Linux, Mac OSX dan iPhone, akan tetapi Windows pun juga memiliki implementasi dari SSH (melalui aplikasi 3rd party). SSH yang banyak di kenal sekarang merupakan pengembangan dari SSH-2. SSH menggunakan Public-Key Cryptography. (versi enkripsi menggunakan public dan private key).

Implementasi yang banyak di gunakan sekarang ini adalah yang versi free yaitu OpenSSH, dan kalau kita perhatikan versi yang di jalankan di environment OpenBSD di iPhone dengan firmware 1.1.x adalah OpenSSH 4.6p1-2. OpenSSH di buat oleh the OpenBSD project dan di buat free dibawah lisensi BSD.

OpenSSH suites sendiri terdiri 4 komponen utama:

• ssh - ini adalah command line utility pengganti telnet
• scp - implementasi cp (copy) secara secure across network
• sftp - secure ftp (file transfer protocol)
• sshd - ssh daemon, ini harus dijalankan di device yag akan kita konek dengan ssh

Agar tidak bingung antara protocol dan aplikasi, maka konvensinya adalah SSH (dengan huruf besar semua) berarti kita membicarakan SSH protocol, sedangkan ssh (huruf kecil semua), berarti kita membicarakan aplikasi ssh.

bersambung ...

[que mission impossible theme]

I'm on a Windows-machine and while I can log onto OpenSSH I can't forward X here.

I install VMWare and Ubuntu in a virutal machine.

I start Ubuntu, and run ssh -X my.machine.outside.the.firewall.com

On the command prompt I'm now at an external Linux machine, from here I run: rdesktop the.remote.desktop.machine.com

Voilá!

Vantaggi

• Elevato grado di sicurezza nel processo di autenticazione.
• Solo gli utenti con la chiave corretta possono autenticarsi nel sistema.
• Ogni chiave può essere protetta da password (ulteriore protezione).

Svantaggi

• Senza la giusta chiave non c'è modo di autenticarsi e quindi di accedere al sistema.
• La gestione delle chiavi può risultare laboriosa.

PROCEDURA

- generare la coppia di chiavi pubblica e privata.
ssh-keygen -t rsa

La chiave privata viene salvata nel file id_rsa.
La chiave pubblica viene salvata nel file id_rsa.pub.

- creare la directory nascosta .ssh nella home user.
mkdir ~/.ssh

- copiare la chiave pubblica nel file authorized_keys.
cat id.rsa.pub > ~/.ssh/authorized_keys

- impostare i permessi sul file per evitare che altri utenti possano leggere i dati della chiave.
chmod go-w ~/
chmod 700 ~/.ssh
chmod go-rwx ~/.ssh

- editare il file sshd_conf (deve essere effettuato come root).
su -
vi /ets/ssh/sshd_conf

- identificare e modificare i parametri come indicato.

PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
PasswordAuthentication no

- riavviare il servizio ssh per attivare la nuova configurazione
service sshd restart

Una volta effettuato il restart del servizio ssh, l'unico modo per effettuare un login remoto è tramite l'utilizzo delle chiavi generate.

Per generare la chiave pubblica e privata è possibile utilizzare anche altri tools come ad esempio puttygen, membro della famiglia puTTY e soggetto a licenza MIT compatibile con la GNU GPL.

- p@olo

Q1. Isn't OpenSSH just an encrypted telnet program?
A1. Short answer, no. The more complete answer is that it's a suite of programs that provide:
-remote shell access (ie. like telnet)
-remote execution of programs (both text and gui)
-remote data pipes for programs that use standard in/out
-data compression
-TCP tunneling
-ftp-like file transfers
-rcp-like file copying
-public key encryption (of all data passed between client and server)/authentication (no need for passwords)
-GUI login prompt for remote execution of X applications with 'gnome-ssh-askpass'
-More recently, VPN functionality by way of the Linux tun/tap virtual network device driver

And I'm sure there's more... I'm kind of an intermediate user of OpenSSH.

Q2. Setting up tunnels is a pain. What's up with this Local/Remote Forward stuff?
A2. Actually, 'man ssh_config' is your friend. If you become familiar with the ~/.ssh/config file, you will find yourself not needing to type much to make connections with OpenSSH. Nearly every command line option for the ssh client can be controlled in this file. For example, I've set up some parameters in my ~/.ssh/config file and called the profile "home". Now I just type: 'ssh home' and I'm in with all the client options in place. The following is an example of some useful things to put in your ~/.ssh/config file:

-Assume that I am connecting from internally at my home (192.168.1.0)
-192.168.1.5 is my web server at home
-192.168.1.2 is my workstation at home
-We'll pretend my workstation at work has TCP port 5022 accessible on the internet for it's OpenSSH server and that it's internet routeable address is 192.168.50.1 (which we know is in private address space. Just pretend...)

Example '~/.ssh/config':

# My 'webserver' connection profile. All I
# need to do to ssh into the web server now
# is type 'ssh webserver'. I am automatically
# prompted for the password for 'george'.
host webserver
hostname 192.168.1.5
User george

# My 'work' connection profile with non
# standard port for ssh (5022).
#
# I've also included one LocalForward line to
# forward port 80 from a web server at work to
# port 4080 on my workstation in front of me.
# So... if I connect with 'ssh work' and log in,
# and point my browser here at home to
# 127.0.0.1:4080, I see the internal web site
# at work here at home.
#
# The RemoteForward line works in reverse. It
# sends specified TCP ports from my workstation
# in front of me at home to my workstation at work. In
# this case, OpenSSH is pushing port 5900 (vnc)
# from 192.168.1.2 (here at home) to my
# workstation at work. If I leave this connection
# up and go to work. I can run 'vncviewer
# 127.0.0.1:0' in my office at work and log into my workstation at home
# with vnc if needed.
host work
hostname 192.168.50.1
port 5022
User george
LocalForward 4080:privateintranet.employersnet.com:80
RemoteForward 5900:192.168.1.2:5900

Q3. Yeah... but I use Windows and I don't have time to mess with Linux. So how does this help me?

A3. The best way to get OpenSSH (client and server) going under Windows and enjoy all the benefits is to install and use Cygwin (click here to download the installer). It's pretty straightforward if you aren't the sort who is afraid to get into a little *nix command line on your Windows box. You have the option of either installing a full Cygwin environment or just installing the needed base components, OpenSSL, OpenSSH, and some admin utilities to run OpenSSH as a Windows service. There are a few sets of instructions on the Internet to get you started, this being one of the better ones. At one point there was a Windows installer for OpenSSH, but it is no longer maintained and so is too out of date to consider at this point. The recommended path is Cygwin. Finally, if you're the kind of person who uses Windows and Linux and you compile stuff from source, that is also an option with Cygwin. Just make sure you have the GNU tool chain installed in Cygwin.

Q4. Why are the docs about OpenSSH on the net so hard to understand?
A4. It took me a good deal of digging to try and find some useful info for tunneling and Public Key info for OpenSSH when I was first starting out. So, yes, the documentation could use some major improvements for people who are a little less technically inclined. To be honest, I think a nice GUI framework around OpenSSH would go a long way to getting more people to use it. There is PuTTY for Windows and it can be made to work in the context of what we're talking about here, but it has the problem of just presenting itself as a telnet-like client and immediately turning people off who don't need "telnet". For example, "I never use shells or command line, why would I need an ssh telnet client"? Trying to convey the fact that telnet and OpenSSH are not the same thing, is difficult. If there was just an OpenSSH standalone "Tunneling" GUI app, I think more interest in OpenSSH would grow on the Windows side. Still, when it comes to the basics of OpenSSH on Unix, the man pages are currently the best resource. The best places to look are:

'man sshd_config' - Tweak your ssh server to do exactly what you need
'man ssh_config' - Find out what else you can do with ~/.ssh/config to minimize your command strings
'man scp' - Learn how to copy files AND directories using 'scp'
'man sftp' - A command line FTP-like interface for putting and getting files viw OpenSSH (I used to use this all the time, but have since moved to 'scp'.)
'man ssh' - Check out the less frequently used options.

Q5. Someone mentioned that I can use 'ssh' in combination with 'tar' or 'rsync' for remote backup. Is that true?
A5. More or less, depending on what you consider a useful backup. I've used ssh and tar for "imaging" Linux boxes. It works well, but has expected limitations. A quick example of using ssh, tar, and gzip to "image" BoxA to BoxB. Assume that we have set up ~/.ssh/config to include all needed info for username and hostname:

Backing up '/' on BoxA to BoxB, intitiated from BoxB:
ssh BoxA "tar -cf - / --exclude=/proc/* --exclude=/var/tmp/*" | gzip -c > /home/admin/images/BoxA.tar.gz

Restoring '/' to BoxC from the archive on BoxB, intiated from BoxC:
ssh BoxB "gunzip -c /home/admin/images/BoxA.tar.gz" | (cd / ; tar -xvf -)

You can also use the excellent 'rsync' command to synchronize two directories on two different machines and with the '-e ssh' option tunnel it all through OpenSSH for encryption. I use this method to backup the family photos from the file server at home to a file server at my parent's house on a nightly basis.

Using 'rsync':
rsync -auvlxHS -e "ssh george@remoteserver:/remotedirectory /localdirectory
Remember 'man rsync' is your friend...

Q6. Did you say something about VPN?

A6. Yes. With a big note saying that I've not tried this yet: As of version 4.3 of OpenSSH, when used in combination with the Linux kernel (or the Windows TAP/TUN Win-32 driver) tap/tun module allows for real IP tunnels between both endpoints. These tunnels are capable of relaying TCP, UDP, ICMP traffic. This is not port forwarding as discussed above, but instead true VPN. I will likely post some more info once I do try it out. I've been using the OpenSSL based OpenVPN for my VPN needs and have been fairly happy with it. However, it might be nice to standardize on OpenSSH for VPN.

Well... that's it for now. There's more to come. I know that there are people more equipped to discuss this than I am, but I am hoping to attract the curious who haven't had the time or energy to try. I encourage anyone who is curious to give it a try no matter what platform you're on. In the long run it's quite a valuable tool.

sshfs atchieu@192.168.0.2:/remote/dir/ /local/dir/

For more information view the manual file of sshfs. If all goes well, your mount should pop up on the desktop if you are using Ubuntu 8.04 or newer.

The Scenario:
You're on a system with a much older version of NIX on it than you should be using. In the middle of doing your work, you find the certain utilities are missing, or are old enough that they have some key features missing. What do you do? Tell your boss the system sucks, and go buy a new one? Wipe the box and all the important data you're supposed to be working on with a new installation of some free *nix? Throw up your hands and do everything manually? Give up?

The Solution:
In most cases, if you're working on a box like this, it's likely that your dealing with text output. That was what I was dealing with and the version of egrep was too old to parse the following:

egrep '(cn:|inetUserStatus:|mailUserStatus:)'

So what did I do? I took advantage of the newer egrep on my Linux workstation using ssh:

/opt/iplanet/server5/shared/bin/ldapsearch -D "cn=MailAdmin" -w t1ck3tsplz -b "o=child.org, o=parent.org" "uid=*" | ssh george@10.0.1.25 "egrep '(cn:|inetUserStatus:|mailUserStatus:)' -" | less

The end result is that the text stream from the old *nix box is sent via ssh to my workstation where I run the egrep using STDIO. Works like a charm! And it will work with any command that outputs text that you need to process somehow. Hope this helps someone else in a similar bind.

The third speaker was equally as interesting and entertaining as Mr. Chun's presentation.  The third speaker was Rick Mellendick who is the Senior Architect of the Cyber Operations Lead at Bearing Point.  His topic was detailing a proactive approach to develop a road map of cyber security.  The title of the presentation was "Offensive Capabilities for Defensive Posturing."

Mr. Mellendick touched on the fact that security professionals must think outside the box when it comes to strategy.  Now, in my opinion, that phrase is pretty overused, especially when it comes to the IT industry.  He does, however, make a good point as our current security strategies are not sufficient enough to get the job done.

He makes the following assumptions about network security:

1. Our networks are attacked regularly.
2. There are vulnerabilities that we don't mitigate because it is either too expensive or not worth it to fix them.
3. The enemy is within and is taking data and bandwidth.
4. The enemy isn't the "traditional" adversary.
5. Concerning mobile communication devices:
   • People use Blackberries for normal work operations
   • Normal work operations involve some "sensitive" data.
   • Blackberries have code running on them that is secure.
   • 10 % of you have handhelds that are broadcasting, and 2 are insecure. (Presumably, he scanned the conference room for Blackberry/Smartphone connections)

As for the current methods of defense, most fall short.  Firewalls can only stop what they are set up to stop, and they allow authenticated traffic, which can be exploited by hackers.  An additional problem is that administrators need a high level of training which, as it turns out it very expensive.  The fact that networks are changing all the time, but the network's configuration are not is a huge problem.  The current solution to handle an issue with a firewall is to open a port, which basically defeats the whole purpose of a firewall in the first place.  Two additional attack vectors are what are known as IPS and IDS.  These are used to create an abnormal amount of administrative trusted connections on the network.  Often times, these attacks are brought upon by improperly configured appliances and the utilization of old and outdated signatures.

The current issues with cyber operations are numerous.  Mr. Mellendick chose to focus on a few.  First, cyberspace is finally being realized as a legitimate battlefield.  Cognizant of this fact, people are finally realizing that protecting this new battlefield is critical to global operations and that current implementations of info assurance are too passive.  The proposals are as numerous as the problems.  He suggests that security professionals must work together to create a unified framework for the consolidation of Cyber Operations.  Sidenote: almost every speaker at the conference talked about how requirements and strategies need to be consolidated and fleshed out. We must test both infrastructure and tools, and reverse engineer malware and attacks.  He urges that we encourage agile development for CND RA tools, and altering our present practices to enable proactive defenses.  As it turns out, the benefits are numerous as well.  The migrations from passive to active postures lead to both offensive and defensive security positioning.  Under these new practices, networks have become more stable and serve as effective baselines, while at the same time defensive modules are becoming more unified.  A powerful tool (which has worked wonders for the military) is providing a proactive defensive strategy using the adversary's tactics against them.  Coupled with active malware detection, mitigation and response, this change in posture will result in a lot less headaches.

In the future, the exemplary speaker noted that we must protect more than just IT networks.  Using active defenses and holistic approaches, we can triumph over present day security issues.  Additionally, security professionals will take Black Team concepts and use them to make agressive network assessments.  Using the right tool for the right job, and the right people for the position can make all the difference in the world.  Modern day attacks on non-IT networks systems like transportation, water and electricity have clearly shown the world that there is a need for the expansion of security procedures and methods.

Mr. Mellendick made a few particularly awesome statements in the second half of his presentation.  He discussed the topic of active defense.  In this scenario, the nature of the beast is much like the Cold War between the U.S. and U.S.S.R.  A show of force, mixed with a preemptive (rather than reactive) response goes a long way to deter enemies.  In this way, we are able to use offensive capabilities for defensive actions.  He went on to explain that in the future of network security, professionals will use three tactics to defend networks.  First, is Network Fast Flux DNS.  This technique alters the internal DNS records of the server environment and allows for the avoidance of DNS based DDoS attacks.  Since malware can change its DNS information on the fly, servers are particularly susceptible to concurrent attacks.  If the server in question is in a fast flux, that is to say always changing, it means we are fighting fire with fire.  The next tool we can use is Network Tool Recording or NTR.  This practice essentially employs basic tools like SSH and NMAP.  These tools record information on the network and is logged by a central database.  Even though this means that there is a boatload of new data, people can use simple analytics and basic heuristics to manage the flood.  An important feature of this concept is that the tools reside in a tool repository that is accessible to users.  And lastly, reverse proxies can be used to great effect.  Essentially, the reverse proxy is a proxy server that is placed within a network DMZ which dispatches in-bound network traffic to a set of predetermined servers.  This strategy has many benefits.  First, it can optimize and compress content to deliver it to users faster.  It pinpoints separated connections to add an additional layer of non-traditional defense.  Even though, the end-user sees a single interface, the traffic is randomized.

The net view of cyber operations was displayed in a cyclical manner during the presentation.  This is a transcription from the original:

Full Spectrum of Cyber Ops:

• Protect
  • High Assurance
  • FR Protect
  • Security Mobile Code
  • Boundary Controllers
  • Embedded Systems
  • IA Wrappers
• Prepare
  • Early Warning
  • Data Hiding/Marking
  • Network Tool Recording
  • Stronger Policy Enforcement
• Predict
  • Data Mining
  • Intelligent Agents
  • Effective Enterprise Defense
  • Rouge Wireless Detection
• Assess
  • Situational Awareness
  • Forensics
  • Decision Support
  • IO Planning
• Response Actions
  • Active Exfiltration Prevention
  • Active Response
  • Fault Tolerant Networks
  • Effects-Based IO

I will quote Mr. Mellendick's presentation as I cannot say it better myself:

The New Paradigm:

Open source tools and tool boxes tend to be a mixed collection ranging from very professionally developed and supported tools, to scripts developed on the fly to perform a specific task.

Through a deeper knowledge of defensive and offensive techniques, along with a shift from current penetration testing techniques, many new vulnerabilities can be and are found and mitigated in advance.

The need for determining new zero day and unpatched vulnerabilities is the best defense against the adversary.

Use of offensive techniques gives the network defenders the best chance to protect their soon to be deployed appliances, processes and currently administered networks.

It was really great to hear his perspective on all these topics.  He covered a lot of ground (as you can probably tell) but made everything really enjoyable to listen to.  Leave your comments below.

Aos menos habilitados, isso pode se tornar um problema.  Principalmente se este for seu promeiro servidor dedicado cpanel linux.

Digite o comando abaixo, dentro do terminal e pronto:

export EDITOR=nano

> ssh_exchange_identification: Connection closed by remote host

i found on internet this solution that worked for me; the trick is regenerating the RSA key of the pix with these commands:

ca zeroize rsa
ca generate rsa key 1024
ca save all

On new ASA appliance, like ASA 5505, the new commands are:

crypto key zeroize rsa
crypto key generate rsa general-keys
ca save all

Fuse is a part of the latest kernel, so you don't need to install fuse-utils (if you're not sure if you have fuse, run lsmod | grep fuse.) So - install sshfs:

sudo aptitude install sshfs

You need permission to use the fuse function - so add yourself to the groups:

sudo usermod -a -G fuse username

Now - create a directory where you want the remote filesystem (make sure you are the owner of the directory). I choose /media/directory

cd /media
sudo mkdir ext_sys
sudo chmod myusername:myusergroup ext_sys

Now - you mount the system (I use /media/ext_sys as mount point)

sshfs remote_username@remote_ip: /media/ext_sys

To unmount, run

fusermount -u /media/ext_sys

Got to love Linux! I had a problem with my usb-stick - but ssh popped into my head - and voila! You learn something everyday :)

.

Click HERE

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

]]> http://omniumpotentior.wordpress.com/?p=317 Sat, 19 Jul 2008 23:14:12 +0000 Death Master http://omniumpotentior.wordpress.com/?p=317 La utilización de sistemas de escritorio remoto para administración a distancia de equipos es algo muy habitual hoy en día. Supongo que la mayoría de vosotros habrá utilizado en alguna ocasión un cliente SSH para contectarse a una máquina remota, y algunos incluso tendréis un servidor SSH en vuestra propia máquina para poder acceder desde cualquier parte.

Dejando a un lado el escritorio remoto del propio Windows, la solución más conocida es seguramente VNC; aunque existe una solución no tan conocida y que aporta algunas mejoras bastante interesantes: la tecnología NX. Destacan principalmente dos características:

• Información tunelada por SSH. En lugar de implementar sus propios mecanismos de seguridad y criptográficos, NX delega dichas tareas en el servidor SSH del sistema. La primera ventaja es que la seguridad queda en manos de un servicio específicamente orientado a ella. La segunda y más interesante, es que no necesita ningún puerto abierto adicional, pues se utiliza el propio servidor SSH para establecer la conexión.
• Gran eficiencia en red. Debido al sistema de compresión del tráfico X, así como al sistema de cachés implementado, un ADSL doméstico con 320 kbps de subida proporciona una fluidez bastante aceptable para manejar un escritorio estándar.

Además, la instalación es muy sencilla, poco más que instalar los tres paquetes que se pueden encontrar en la sección de descargas de la página de NoMachine. Eso sí, es conveniente que el servicio SSH esté en su puerto por defecto (22) y luego realicéis la traducción desde el puerto externo que queráis en el router, pues con algún puerto diferente puede dar algún problema para la configuración de NX.

Hay disponibles clientes para sistemas Windows, Linux, Mac OS X y Solaris. Eso sí, la parte "mala" (para algunos) es que el servidor sólo funciona bajo Linux o Solaris. Por cierto, existe también FreeNX, una implementación GPL que utiliza las librerías de NX, aunque debido a la liberación del código de NX por parte de NoMachine, ésta última es la opción más interesante.

Server-Side:
Generate a public/private key on the server machine in /home/backuppc/.ssh/laptop & Generate a public/private key on the client machine in /home/$USER/.ssh/laptop. Replace [LAPTOPUSER]

sudo su backuppc
cd ~
ssh-keygen -t dsa -f ~/.ssh/laptop2
scp ~/.ssh/laptop2.pub [LAPTOPUSER]@192.168.0.11:~/

Create the folder ‘.ssh’ if it doesn’t exist and configure the public key to OpenSSH’s liking. Replace [LAPTOPUSER]

ssh [LAPTOPUSER]@192.168.0.11
if [ ! -d .ssh ]; then mkdir .ssh ; chmod 700 .ssh ; fi ; mv laptop2.pub .ssh/ ; cd .ssh/ ; if [ ! -f authorized_keys ]; then touch authorized_keys ; chmod 600 authorized_keys ; fi ; cat laptop2.pub >> authorized_keys ; rm laptop2.pub;
exit

Test if you can connect without being prompted for a password, but you should have to enter the passphrase

ssh -i ~/.ssh/laptop2 [LAPTOPUSER]@192.168.0.11

Manually Rsync via SSH

rsync -avrz   $USER@laptop:/home/$USER/ -i ~/.ssh/laptop2

Edit backuppc settings:

type: rsync
rsyncclientcmd: replace root with [LAPTOPUSERNAME] and add -i ~/.ssh/laptop2

that should work and backup with your clients username

sudo aptitude install ssh

Una vez instalado, lo ponemos en marcha:

sudo /etc/init.d/ssh start

Para comprobar de que funciona podremos hacer una conexion desde el cliente:

ssh nombre_usuario@192.168.1.1

nombre de usuario debe ser un nombre de usuario válido en el servidor. La IP suponemos que es la del servidor. Una vez ejecutado dicho comando, si es la primera vez que nos conectamos nos preguntará si queremos aceptar la clave del servidor, le decimos que sí y luego introduciremos la contraseña.
Si todo fue bien, deberíamos estar en una shell en el servidor.
Lo siguiente es poder conectarnos al servidor sin tener que usar ninguna contraseña, de esta forma, podemos lanzar el proceso de backup o cualquier otro proceso que necesitemos conexión al servidor a través de ssh desde cron o desde donde sea sin tener que preocuparnos de tener que introducir ninguna contraseña o leerla desde algún fichero, base de datos, etc.
La idea se basa en el uso de clave pública y privada. Desde ssh-keygen tendremos que generar este par de claves. Una será la clave pública y la otra, evidentemente, será la clave privada. La clave privada debemos protegerla de modo que nosotros seamos los únicos que tengamos acceso a ella, ya que si alguien consiguiera dicha clave se podría conectar a nuestro servidor con nuestras mismas credenciales.

Nota: a la clave privada, cuando la generamos, lo podemos hacer dándole una frase de paso. De esta forma cada vez que usemos dicha clave privada, se nos preguntará por la frase de paso, pero en este pequeño tutorial lo haremos sin introducir ninguna frase de paso. Otro apunte más es que ssh maneja dos tipos de autentificación por este sistema, RSA y DSA. DSA es un versión más nueva que el RSA, pero ahora mismo para simplificar las cosas y ya RSA es la clave que se genera por defecto, usaremos RSA.

El siguiente paso es generar ambas claves:

ssh-keygen

Cuando ejecutamos este comando, lo primero que nos pregunta por el nombre de la clave privada. Si dejamos el valor por defecto, es decir, si pulsamos enter sin introducir ningún nombre, nos crea en nuestro home, dentro del sirectorio .ssh un fichero llamado id_rsa. Luego nos pregunta por una frase de paso, que como dijimos antes dejaremos en blanco. También nos crea otro fichero, en la misma carpeta que el anterior, llamado id_rsa.pub, el cual es la clave pública.
El siguiente paso sería copiar la clave pública al servidor. Ejecutamos el siguiente comando desde nuestro home:

ssh-copy-id -i .ssh/id_rsa.pub nombre_usuario@192.168.1.1

Con esto en un principio ya deberiamos tener acceso a nuestro servidor usando nuestra clave privada. Si ejecutamos el siguiente comando:

ssh numbre_usuario@192.168.1.1

Deberiamos de poder conectarnos sin que nos pregunte por nuestra contraseña.
Si cuando intentamos conectarnos, el servidor nos sigue preguntando por la contraseña, entonces algo no va bien. Asegúrate de que en el fichero de configuración de ssh (/etc/ssh/sshd_config tienes estas dos líneas y no están comentadas:

PubkeyAuthentication yes
RSAAuthentication yes

Si haces algun cambio en este fichero de configuración debes reinciar el servidor ssh:

sudo /etc/init.d/ssh restart

Si el problema que tienes es un "Permission denied (publickey)" entonces ejecuta estos comandos en el servidor, desde la cuenta de usuarion con la que queremos conectarnos:

chmod go-w ~/
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Bueno esto es todo por ahora, espero que os funcione y os sea de utilidad.

Here is assumed that client and server username is the same.

Generate a public/private key on the server machine in ~/.ssh/laptop & Generate a public/private key on the client machine in ~/.ssh/laptop

ssh-keygen -t dsa -f ~/.ssh/laptop
scp ~/.ssh/laptop.pub $USER@192.168.0.2:~

Create the folder ‘.ssh’ if it doesn’t exist and configure the public key to OpenSSH’s liking

ssh $USER@192.168.0.2
if [ ! -d .ssh ]; then mkdir .ssh ; chmod 700 .ssh ; fi ; mv laptop.pub .ssh/ ; cd .ssh/ ; if [ ! -f authorized_keys ]; then touch authorized_keys ; chmod 600 authorized_keys ; fi ; cat laptop.pub >> authorized_keys ; rm laptop.pub;
exit

Test if you can connect without being prompted for a password, but you should have to enter the passphrase

ssh -i ~/.ssh/laptop $USER@192.168.0.2

Add passphrase to ssh-agent:

ssh-add .ssh/latop

Manually Rsync via SSH

rsync -avrz   $USER@laptop:~/ .

Menyangkut pertanyaan saya di milis id-ubuntu tentang Virtual Server di HostOS yang tidak punya GUI, ternyata "VirtualBox Headless Server" bisa menjadi solusi buat saya... terima kasih buat teman-teman milis id-ubuntu yang sudah membantu... :)

Sekedar sharing, untuk langkah-langkah instalasi dan konfigurasinya bisa dilihat di HOWTO: Setup Headless Sun xVM VirtualBox 1.6 on Ubuntu Server 8.04.

Dan jika kita ingin GuestOS itu nantinya juga bisa diremote melalui ssh, maka ada sedikit trik tambahan, yaitu :

Jalankan 3 baris command berikut di HostOS (Ubuntu)

# VBoxManage setextradata [GuestOS-name] "VBoxInternal/Devices/pcnet/0/LUN#0/Config/ssh/Protocol" TCP
# VBoxManage setextradata [GuestOS-name] "VBoxInternal/Devices/pcnet/0/LUN#0/Config/ssh/GuestPort" 22
# VBoxManage setextradata [GuestOS-name] "VBoxInternal/Devices/pcnet/0/LUN#0/Config/ssh/HostPort" 2222

Silahkan ganti [GuestOS-name] dengan nama GuestOS yang terinstall di VirtualBox.

Di VirtualBox ini, untuk network saya set menggunakan NAT, dan ketika instalasi GuestOS selesai, maka otomatis kita bisa menggunakan koneksi internet yang ada pada HostOS (Ubuntu).

Oh ya, untuk ssh ke GuestOS silahkan gunakan command :

# ssh IP_HostOS -l username -p 2222

Untuk mengaktifkan service apache sehingga bisa diakses dari luar, maka perlu menjalankan 3 baris command berikut di HostOS (Ubuntu)

# VBoxManage setextradata [GuestOS-name] "VBoxInternal/Devices/pcnet/0/LUN#0/Config/apache/HostPort" 8900
# VBoxManage setextradata [GuestOS-name] "VBoxInternal/Devices/pcnet/0/LUN#0/Config/apache/GuestPort" 80
# VBoxManage setextradata [GuestOS-name] "VBoxInternal/Devices/pcnet/0/LUN#0/Config/apache/Protocol" TCP

Untuk mengakses webservernya, silahkan pointing ke http://IP_HostOS:8900

Sekian mudah-mudahan bermanfaat... :)

.

Click HERE

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

]]> http://levuhung.wordpress.com/?p=71 Sat, 12 Jul 2008 05:48:18 +0000 levuhung http://levuhung.wordpress.com/?p=71 1. Cài đặt SSH
2. Khởi động
#service sshd start
#chkconfig sshd on

3. Giới hạn access
#vi /etc/hosts.allow
thêm vào
sshd: ALL

4. Đăng ký User
$ssh -l username host
Nhập password cho SSH (không nhất thiết phải giống với pass của user)

$ssh-keygen -t rsa
Nhập pass vừa đăng ký ở trên

Xác nhận key được tạo ra:
$ls -l .ssh/
$ssh-keygen -l -f .ssh/id_rsa.pub

5. Thêm username@host vào trong file id_rsa.pub
$scp ~/.ssh/id_rsa.pub username@host:

6. Tạo file key của client
$cat id_rsa.pub >> ~/.ssh/authorized_keys
$chmod 700 ~/.ssh
$chmod 600 ~/.ssh/authorized_keys

7. Test
Từ máy client thử truy cập server
$ssh -l username host