ForwardX11 Yes :)[/quote]
jes kad bi server imo X :D[/quote]
man sshfs
[quote=nidla]ps:
jah gui editorima ništa ne fali ako radiš development, ali ako radiš sistem administraciju fali im dosta toga[/quote]
Za sistem administraciju: editovanje conf fajlova - nano, pregled logova - less, sve ostalo (nekih 1% slučajeva) - sshfs.
To je tvoja opcija, mislim da je vi/vim dosta napredniji, a o gui editorima da ne pricam nebitno dali ima X ili ne. Osim sto te alatne trake zauzimaju dodatni prostor na titling wm-u i mom ionako relativno malom monitoru, zatim treba nekoliko sekundi da se otvori ( ne puno) ipak najdraze ni je kada se app otvori instantno i kolikogod keybinidinga imao taj editor on je i dalje napravljen za rad sa misom a mrzim kada moram stalno ruku sa tastature prebacivati na mis.
PS:
I mislim da kod vecine distra cak i kod freebsd nano je optional software dok vi dolazi po defaultu. 
jes kad bi server imo X :D[/quote]
man sshfs[/quote]
nevezano za temu, hvala puno! super, vjerovao ili ne, danas mi je baš nešto ovako baš trebalo ali nisam našao, ko da si znao koji hint mi treba! btw imao sam nekih iso image na jednom serveru a mrsko mi bilo da ih kopiram da bi ih virtualbox vidio 
inače, ja i kad bi to montiro opet bi editovao sa vi(m)-om 
[quote][quote=nidla]ps:
jah gui editorima ništa ne fali ako radiš development, ali ako radiš sistem administraciju fali im dosta toga[/quote]
Za sistem administraciju: editovanje conf fajlova - nano, pregled logova - less, sve ostalo (nekih 1% slučajeva) - sshfs.[/quote]
baš bi se proslavio sa sshfs-om da administriraš malo više servera, i kada je brzina editovanja bitan faktor.
For a quick fix i use nano.
Pa slažem se, i ja bih editovao s vim-om da mi nije mrsko da ga učim, a sigurno bih ga naučio da mi je ikada zatrebao to i jeste poenta.
jes kad bi server imo X :D[/quote]
man sshfs[/quote]
na stranu sshfs, to je priča za sebe i ima svoju primjenu, nego šta radiš u ovakvoj sitauciji?
vi /etc/ssh/sshd_config[quote]PermitRootLogin no
AllowUsers someuser[/quote]
Jedva skontah da misliš na neke fajlove koji nisu dostupni someuser-u Kao što rekoh, za editovanje konfiguracije mi je sasvim dovoljan nano, za čitanje logova koristim less, a za ostale stvari (npr. editovanje neke stranice, razvoj nekog koda koji mora biti na serveru, hackovanje kernela 
) treba source code držati u svom home direktoriju i/ili dati privilegije someuser-u na neki drugi direktorij slično kao kad koristiš ftp. Ne zato što vim sucks nego zato što je to elementarna sigurnosna politika, isto kao što se ne treba logirati kao root i raditi išta osim ono što moraš. Dodatno pogledaj pod Match User za razne fazone kako ograničiti korisnika.
BTW mislim da je to /etc/ssh/sshd_config a ne /etc/sshd/ssh_config
U onom Adisovom postu “9 traits of UNIX veteran blabla” je bila stavka “Uses su. Sudo is for pussies”
ssh_config je od klijenta konfig a sshd_config je od servera. Znam jer mi je nedavno to malo slovo povadilo 5kg zivaca.
use ls when you enter directory 
Ili ima i ova: ako na sistemu imaš usera koji može sudo štagodhoće, onda možeš komotno i PermitRootLogin yes jer koja je razlika
sudo ne da pristup nekim segmentima
$ sudo su root ? Mislim da nebi trebalo biti razlike.
ako je u fajlu /etc/ssh/sshd_config ovo:
PermitRootLogin no
AllowUsers someluser
ne znam jesmo li se dobro skontali, recimo ne možeš uraditi sshfs root@remotehostname:/var/log/apache2 remotedir jer se root ne može direktno logirati, a kao običan user nemaš permisije nad /var/log/apache2 da bi uradio sshfs someluser@remotehostname:/var/log/apache2 remotedir
ama u pitanju su uglavnom dns serveri, mail serveri web serveri, dosta njih… stalno se mora ažurirati konfiguracija, ne pada na pamet ni jednom adminu da radi mount na svoju mašinu
do mene, typo editovo sam prethodni post
Ili ima i ova: ako na sistemu imaš usera koji može sudo štagodhoće, onda možeš komotno i PermitRootLogin yes jer koja je razlika :)[/quote]
vizavi sshd_config
evo jedna razlika, razlika je što ti svako izvana može hackati root account (jer postoji na svakom linuxu i onda se neko natakari i lupa šifre)
bolje fino zatvoriti root na sshd, to ima i druge prednosti, možeš saznati koji user se “su -” na root acc pa nešta rasturio na sistemu
but just using “su -” doesnt mean you’re not
krivi navod
[quote]Nine traits of the veteran Unix admin
By Paul Venezia
Created 2011-02-14 03:00AM
Last week I briefly departed from reality, thanks to the inexplicable actions of the CRTC, but this week, I’m off the drugs and back on terra firma – sort of. Anyway, to celebrate my return to the land of the sane, I thought I’d tick off a few hallmarks of veteran Unix admins, so you have a better chance of spotting these rare, beautiful creatures in the wild. Here is our song.
Veteran Unix admin trait No. 1: We don’t use sudo
Much like caps lock is cruise control for cool, sudo is a crutch for the timid. If we need to do something as root, we su to root, none of this sudo nonsense. In fact, for Unix-like operating systems that force sudo upon all users, the first thing we do is sudo su - and change the root password so that we can comfortably su - forever more. Using sudo exclusively is like bowling with only the inflatable bumpers in the gutters – it’s safer, but also causes you to not think through your actions fully.
[ Also on InfoWorld: Read Paul Venezia’s tips on how to become an IT ninja. | Check out Paul Venezia’s five-year plan to tackle the 8 problems IT must solve. ]
Veteran Unix admin trait No. 2: We use vi, not emacs, and definitely not pico or nano
While we know that emacs is near and dear to the hearts of many Unix admins, it really is the Unix equivalent of Microsoft Word. Vi – and explicitly vim – is the true tool for veteran Unix geeks who need to get things done and not muck about with the extraneous nonsense that comes with emacs. Emacs has a built-in game of Tetris, for crying out loud.
I’ll grudgingly admit that the bells and whistles in vim such as code folding and syntax highlighting might be considered fluff, but at the end of the day, real Unix work blends extremely well with vi’s modal editing concepts. In addition, its svelte size and universal portability make it the One True Editor. Thanks Bill, thanks Bram.
Veteran Unix admin trait No. 3: We wield regular expressions like weapons
To the uninitiated, even the most innocuous regex looks like the result of nauseous keyboard. To us, however, it’s pure poetry. The power represented in the complexity of pcre (Perl Compatible Regular Expressions) cannot be matched by any other known tool. If you need to replace every third character in a 100,000-line file, except when it’s followed by the numeral 4, regular expressions aren’t just a tool for the job – they’re the only tool for the job. Those that shrink from learning regex do themselves and their colleagues a disservice on a daily basis. In just about every Unix shop of reasonable size, you’ll find one or two guys regex savants. These poor folks constantly get string snippets in their email accompanied by plaintive requests for a regex to parse them, usually followed by a promise of a round of drinks that never materializes.
Veteran Unix admin trait No. 4: We’re inherently lazy
When given a problem that appears to involve lots of manual, repetitive work, we old-school Unix types will always opt to write code to take care of it. This usually takes less time than the manual option, but not always. Regardless, we’d rather spend those minutes and hours constructing an effort that can be referenced or used later, rather than simply fixing the immediate problem. Usually, this comes back to us in spades when a few years later we encounter a similar problem and can yank a few hundred lines of Perl from a file in our home directory, solve the problem in a matter of minutes, and go back to analyzing other code for possible streamlining. Or playing Angry Birds.
Veteran Unix admin trait No. 5: We prefer elegant solutions
If there are several ways to fix a problem or achieve a goal, we’ll opt to spend more time developing a solution that encompasses the actual problem and preventing future issues than simply whipping out a Band-Aid. This is related to the fact that we loathe revisiting a problem we’ve already marked “solved” in our minds. We figure that if we can eliminate future problems now by thinking a few steps ahead, we’ll have less to do down the road. We’re usually right.
Veteran Unix admin trait No. 6: We generally assume the problem is with whomever is asking the question
To reach a certain level of Unix enlightenment is to be extremely confident in your foundational knowledge. It also means we never think that a problem exists until we can see it for ourselves. Telling a veteran Unix admin that a file “vanished” will get you a snort of derision. Prove to him that it really happened and he’ll dive into the problem tirelessly until a suitable, sensible cause and solution are found. Many think that this is a sign of hubris or arrogance. It definitely is – but we’ve earned it.
Veteran Unix admin trait No. 7: We have more in common with medical examiners than doctors
When dealing with a massive problem, we’ll spend far more time in the postmortem than the actual problem resolution. Unless the workload allows us absolutely no time to investigate, we need to know the absolute cause of the problem. There is no magic in the work of a hard-core Unix admin; every situation must stem from a logical point and be traceable along the proper lines. In short, there’s a reason for everything, and we’ll leave no stone unturned until we find it.
To us, it’s easy to stop the bleeding by HUPping a process or changing permissions on a file or directory to 777, but that’s not the half of it. Why did the process need to be restarted? That shouldn’t have been necessary, and we need to know why.
Veteran Unix admin trait No. 8: We know more about Windows than we’ll ever let on
Though we may not run Windows on our personal machines or appear to care a whit about Windows servers, we’re generally quite capable at diagnosing and fixing Windows problems. This is because we’ve had to deal with these problems when they bleed over into our territory. However, we do not like to acknowledge this fact, because most times Windows doesn’t subscribe to the same deeply logical foundations as Unix, and that bothers us. See traits No. 5 and 6 above.
Veteran Unix admin trait No. 9: Rebooting is almost never an option
Unix boxes don’t need reboots. Unless there’s absolutely no other option, we’ll spend hours fixing a problem with a running system than give it a reboot. Our thinking here is there’s no reason why a reboot should ever be necessary other than kernel or hardware changes, and a reboot is simply another temporary approach to fixing the problem. If the problem occurred once and was “fixed” by a reboot, it’ll happen again. We’d rather fix the problem than simply pull the plug and wait for the next time.
If some of these traits seem antisocial or difficult to understand from a lay perspective, that’s because they are. Where others may see intractable, overly difficult methods, we see enlightenment, born of years of learning, experience, and most of all, logic.
This story, “Nine traits of the veteran Unix admin,” was originally published at InfoWorld.com. Read more of Paul Venezia’s The Deep End blog at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.[/quote]
Ma razumjeli smo se, 99% opcija vim-a je apsolutno suvišno za editovanje httpd.conf ne znam zašto ljudi imaju toliko problema sa argumentom malo komplikovanijim od “X je dobro, Y je loše, nananana”.
Što se tiče brute force napada, šta ja znam, šta god se tebi čini sigurnijim botovi uglavnom pokušavaju dictionary napad na root šifru a onda na kombinacije user=password ili neki trivijalni passwordi za raze usere. Ako koristiš dobre šifre (ili još bolje neke ključeve) teoretski si siguran od oboje… root login treba zabraniti da ne bi dolazio u iskušenje da sve radiš kao root, a sudo koji dozvoljava sve (kao kad na Ubuntu napraviš korisnika tipa administrator) je nešto između. Idealno za desktop čija je ideologija copypasting magičnih inkantacija u shell, za servere baš i nije, najbolja solucija je ručno prilagođen /etc/sudoers ali kome to nije mrsko
dobro ti misliš da je “vi” suvišan, a ja mislim da je nano/pico je inferioran kraj priče, ali uvijek postoji način da se dokaže šta je bolje/efikasnije, ako hoćeš možemo napraviti test